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