Re: Websockets and connections to private IPs and localhost

> There's also the abuse case seen in the wild of Android apps deliberately
> listening on localhost, and web pages using that to get permissions the app
> has, but which the web page does not. (e.g. geolocation)

Sure. The app can also just send it to the server and the server can
send it to the webapp. I really doubt we will be able to ever stop the
abuse that launders this sort of data. Worse, by blocking this, we are
ensuring the data has to go to a server, leaving the client.

> How is WebSocket different from CORS in that regard?

I support both, if others do too. I haven't thought through this more
fully: it is different but maybe the security argument applies to
both.  I am definitely convinced (right now) that allowing websockets
should be good.


> On Thu, Mar 19, 2015 at 1:49 AM Devdatta Akhawe <>
> wrote:
>> Hi
>> In, the
>> blink team is planning on blocking all connections to private networks
>> and localhost. This is unfortunate, because (as discussed in the bug)
>> this breaks a bunch of applications. I was wondering: instead of
>> cutting down all accesses outright, can we make a compromise in
>> allowing websockets to connect?
>> The websocket handshake is designed to not mistakenly allow access:
>> instead, there are specific steps the servers have to take to agree to
>> connect over websockets and so I don't see much security hardening
>> achieved by blocking websockets. What do others think? (I am not sure
>> this is even under the purview of w3c since I don't believe "block
>> private networks" is a standard).
>> Additionally, I think browsers should also allow websocket connections
>> to localhost in a secure context because the browser can ensure that
>> this never left the computer to get on the (untrusted) network. This
>> part 2 definitely seems like part of MIX.
>> cheers
>> Dev
>> full disclosure for those who didn't read the bug: Dropbox (my current
>> employer) is also affected by this issue. That said, these opinions
>> are mine and do not represent my employer's.

Received on Thursday, 19 March 2015 22:17:49 UTC