- From: Bob Lund <B.Lund@CableLabs.com>
- Date: Thu, 19 Mar 2015 15:13:53 +0000
- To: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
We have an application where a LAN ws server address is passed to page 1 from internet site A. Page 2 from site A is loaded by a second device on the same LAN. The two pages rendezvous at an internet ws server. Page 2 is passed the LAN ws server address where page 1 and 2 rendezvous for future communication. Sounds like this wouldn't work anymore, which is too bad as it's a useful design pattern for in-home multi-screen apps. Bob On 3/19/15, 2:46 AM, "Devdatta Akhawe" <dev.akhawe@gmail.com> wrote: >Hi > >In https://code.google.com/p/chromium/issues/detail?id=378566, 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 15:14:20 UTC