Hacker News Reader

Comment by logn | Hacker News Reader

They're not blocking all access, just sub-resources from Internet pages (you can still develop/use local servers). And they're adding a command line switch and enterprise policy to allow localhost.

Also this is preferred way to communicate with localhost:

https://developer.chrome.com/extensions/messaging https://developer.chrome.com/extensions/nativeMessaging

View on HN

Sub-resources includes websocket connections. The link you point to is not a standard and will not work cross-browser. You will also need to package your app using Chrome's format AFAIK. Basically, it's not really an option at this point in time.

I agree with you and someone has mentioned this on the issue, as well as a proposed exception to this policy: https://code.google.com/p/chromium/issues/detail?id=378566#c...

Yep, this is a good thing. Apart from dev work, I like the pattern of local Web UIs for installed apps, I wish they were more commonplace - without risking the user's security.

Yes, but it should not be blocking access to wss with DNS resolving to 127.0.0.1 and valid SSL certificate, which is what they are planning to do, breaking web apps such as Dropbox which rely on this.

Can't using CORS Allow-Origin headers solve this issue, if there's a domain for localhost and a valid certificate for it?

Not likely, as I think it will be blocked in the same way that mixed content is blocked (whether CORS is allowed or not). I think the plan is just to cut off access to localhost entirely whether intentioned or not, because WSS already has an Origin header which functions similarly to CORS when the client is a browser.

what I meant was that I think allowing CORS or a similar mechanism is probably enough, and breaking apps like Dropbox is not a great idea, even if there is a non standard mechanism to override it.

Yes I agree, and WSS already has that mechanism in place. A similar point was also raised in the issues thread but has not been responded to.

As I explained elsewhere, the origin header in WS(S) allows a server to overtly protect itself from a client. Unlike CORS, it doesn't allow the browser to make security decisions regarding requests, and so would not address any of the attacks we're trying to prevent.

Potentially, yes, and it's one of the ways we're looking at addressing per-page opt-in.

How does this work? Do I have an SSL certificate on my computer for www.dropboxlocalhost.com? Where does the SSL termination happen?

in the dropbox app. Feel free to extract the certificate and MITM connections to your local machine.

Then I'm not entirely sure I understand the point of having an SSL certificate in place to begin with?

You cannot talk to non SSL connections from an SSL page.

It's there to enable a connection from an https web app. Otherwise it would be blocked as mixed content (e.g. if you just used ws). Because everyone has access to the localhost key in the Dropbox app, Dropbox uses additional mutual authentication after establishing the wss (this is actually also because other websites may try to access the local daemon). The wss is only there to indicate to the browser that Dropbox really wants to establish a connection between their web app and the local daemon. It's a lot of hoops to jump through to make it work, but it's the best way of doing it.

> It's there to enable a connection from an https web app

Oh! Thanks. Forgot about that.

We'll be changing the mixed-content detection soon to treat localhost as a secure transport (because it is from the network perspective), which will address the mixed content issue.

Sorry, but I didn't find "sub-resources" in my Webster's. Could we please have a definition or a link to a definition?

In general in documentation for computing, or other technical documentation, or any serious writing on any subject, we should avoid undefined terminology.

Sorry to be critical, but computer security is a serious subject; since all it takes is one little gap to have a terrible computer virus infection, we need to be quite clear right down to the level of each little issue, quite clear and explicit.

So far this year, I've spent over half my time fighting viruses. Bummer.

A subresource is basically additional content that a page includes via a URL (e.g. script, iframe, images). The problem underlying this is that any page on the web can currently probe and then attack devices and servers on your internal network or local host. So, the proposal is to block that by preventing remote websites from navigating to or including sub-resources from anything on your internal network or local host (unless some explicit opt-in or exception is configured).

We'd be blocking sub-resources and navigation from web to private. Of course, direct navigation via a bookmark or the omnibox would still work. And navigation or resource inclusion from private to the web would still work.

As I explained in another comment, we're also working on exception mechanisms (including per-page opt-in, possibly via CORS) to cover the valid use cases.

Some of us still use tiddlywiki. Make sure that still works.

Reply on news.ycombinator.com