Hacker News Reader

Comment by _urga | Hacker News Reader

This includes blocking access by web apps such as Dropbox to their local daemon, which currently rely on a public DNS record resolving to 127.0.0.1 and a secure localhost websocket server (using a certificate for the public DNS record's FQDN) to make the connection (with additional mutual authentication after the websocket handshake).

After this change, there will be no way for a web app to communicate directly with a locally installed daemon.

View on HN

I mentioned this above, but we plan to let the localhost/private page support an explicit opt-in, maybe via CORS headers. Those details may not be captured in the bugs yet because currently no one is actively working on this.

Websockets already have the Origin header as mentioned in the bug by Tyoshino: https://code.google.com/p/chromium/issues/detail?id=378566#c...

Edit:

From my other comments, there is the additional implicit opt-in shown by WSS itself on localhost requiring (1) a public DNS record and (2) a valid SSL certificate for that FQDN.

I doubt that there are WSS servers on localhost out there setup with a public DNS record and validating SSL certificate which are not also expecting public traffic.

As I explained in my other comment, the origin header in websockets doesn't help in addressing the attacks we see, because it is a server-side measure.

As a normal user, i.e. someone who does't really keep up to speed with whatever is the latest news in cross-platform-XRGS-injection-attack, is this good or bad?

On the one hand, blocking access to plain http servers on localhost is a good idea as it prevents people from trying to probe router servers etc. which don't expect to be accessed from the web.

But on the other hand, blocking secure websocket servers on 127.0.0.1 using a public DNS record and valid SSL certificate, is going too far.

Secure websocket servers on localhost are often implemented precisely for the purpose of being accessed by the public web, and are secured for that purpose. It's very rare to find wss servers on localhost using a public dns record resolving to 127.0.0.1 and a valid ssl certificate (most people seem to think a wss server on localhost is not possible).

So this is bad for users. For example, it will break Dropbox's feature which allows you to open files from within the web app in a native application such as Excel (if you have the file synced on your computer).

If Chrome continue with this, then apps such as Dropbox will have to implement these kinds of features using server proxies. These will be slower and less secure since they will need to be able to guarantee that a TCP connection from a web browser and a TCP connection from a local daemon are from the same machine (this is not easy to do when NAT is involved).

> For example, it will break Dropbox's feature which allows you to open files from within the web app in a native application such as Excel (if you have the file synced on your computer).

Couldn't that just do that with a custom URL scheme like dropbox:// that's handled by the local app? Or is there more to the feature?

The issue with custom URL schemes is that they're a cure worse than the disease here. The "internal webserver for local apps" was supposed to be a workaround for this very problem.

Yes, the custom protocol scheme is also only really useful for doing something "once". That is, you can only issue one custom protocol request or so each time you load a web page, the browser blocks the rest to prevent spamming the user.

I'm sorry, I know this is an earlier comment but I wanted to correct this framing of the threat and proposed mitigations. My response to you here explains why these measures don't solve the attacks that we're trying to address: https://news.ycombinator.com/item?id=9211034

To complete with an example of that, easel, the hipster Computer Aided Manufacturing software is hosted in the web, and it assumes that your CNC router is on the local network to receive the instructions in a HTTP post request.

> After this change, there will be no way for a web app to communicate directly with a locally installed daemon.

Well, you could just not use Chrome.

That's the same argument as "You could just not use IE4," and the same situation: "let's just break the web, we know best what's best for you." Ironic that it's Chrome this time, the browser that started out as the champion of NOT breaking the web.

Yeah, that's my point. We're beyond the place in time where a single browser gets to dictate behavior like this.

I'm noticing a large uptick in "good engineering but terrible design and implementation choices in the name of security", and I wonder what's driving that.

> Ironic that it's Chrome this time, the browser that started out as the champion of NOT breaking the web.

I don't think that was ever the message. Chrome has always been "the fastest browser" rather than anything else, and it has lead to (much-needed IMO) substantial performance improvements from the other camps.

I think you're retroactively spinning it, to fit what Chrome has become today. Let me just find the comics v1 rolled out with.

Ahem: "There are a lot of limitations to the kinds of applications that you can build today with web browsers. And the subset of things you can do is different for each browser. If one browser has a cool feature, that doesn't help -- it has to exist across all browsers in order for developers to use it." (Emphasis original)

But yeah, Google says they're not evil, so that makes anything they do non-evil...riiiiight. I have a feeling we're not in Kansas anymore.

I'm not trying to be retroactive - I genuinely don't remember any comics - just the videos with the lasers and whatnot to show how fast it was.

Well, it's still out there. The main selling points were:

- it's safe

- it's fast

- it's stable

- doesn't break the web

All of that in contrast with IE of that time, which failed all four of the above. Currently it's trying to stay somewhat safe, and ditched the other three in the process.

https://www.google.com/googlebooks/chrome/

Yes, but if you're developing a cross-browser web app you can't expect your users to just not use Chrome.

If Google keeps breaking web apps, users will move from Chrome anyway.

This argument has been shown to be wrong on many, many occasions.

Many users do not have a choice which browser they use, do not know they even have a choice or do not know how to exercise that choice i.e. download and install a competing browser. Finally you're then left with the massive problem of sites only working on certain browsers.

The situation where the user doesn't know about and/or is incapable of installing another browser is pretty common with default browsers like IE and Safari, but not nearly as common with Chrome.

Google have been bundling Chrome with widely-used software like Adobe Flash for years now, there's probably many people who've installed it and set it as their default browser without intending to.

Might. It only took ... what - five years? Ten years? for people to start ditching IE after it turned Evil (IE5+). The years between "Browser X is the best thing since sliced bread" and "Browser X Considered Harmful" became known as the Browser Dark Ages. Not looking forward to a repetition thereof.

From 0 to 1 is a lot different than from 1 to 2, or from 1 to n.

Wow how things have changed

Reply on news.ycombinator.com