It seems fine to me to block ws:// in https pages as long as there are available workarounds for people who have a legitimate reason to access ws:// from an https page. I think you can do that with an iframe to an HTTP page, using postMessage to pass the web socket data back and forth between the https and http contexts. This will cause the browser to display a mixed content warning, which is what you want.
On Wed, Jun 8, 2011 at 10:10 AM, Adam Barth <[email protected]>wrote: > On Wed, Jun 8, 2011 at 8:40 AM, Christopher Blizzard > <[email protected]> wrote: > > On 6/7/2011 5:52 PM, Adam Barth wrote: > >> On Tue, Jun 7, 2011 at 5:43 PM, Brian Smith<[email protected]> wrote: > >>> Adam Barth wrote: > >>>>> On 5/31/2011 8:24 AM, Brian Smith wrote: > >>>>>> > >>>>>> We have also discussed blocking https+ws:// content completely in > >>>>>> our > >>>>>> WebSockets implementation, so that all WebSockets on a HTTPS page > >>>>>> must be > >>>>>> wss://. That way, we could avoid making mixed content problems any > >>>>>> worse. > >>>>> > >>>>> Do you have a bug on file for that yet? > >>>> > >>>> If you'd be willing to file a bug at bugs.webkit.org too (and CC me), > >>>> I can help make sure WebKit and Firefox end up with the same behavior > >>>> here. > >>> > >>> Bugzilla Bug 662692 > >>> Chromium Issue 85271 > >>> WebKit Issue 62253 > >>> > >>> I wasn't sure which email address to use to CC you to the Chromium and > >>> WebKit bugs. > > > > Do we have consensus that this is something we want, both internally and > > externally? > > It sounds like a good idea to me, but I'll need to talk with the folks > who work on WebSockets directly to make sure they're on board. > > Adam > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security > _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
