Aymeric Vitte <[email protected]> wrote: > I think Mozilla should revert its policy for > https://bugzilla.mozilla.org/show_bug.cgi?id=917829 > > Or provide an explaination stronger than "a https connection can not > fallback to http", which is not the case at all here, "insecure" ws is not > the same at all than allowing http inside a https page. > > This forces us to do insecure things, like not being able to use https to > load Peersm app (http://peersm.com/peersm instead of > https://peersm.com/peersm) putting people at risk when they use for example > the Tor network to load the app thinking they are more protected and not > envisioning at all that the exit node is the perfect MITM.
Websockets isn't really designed for peer-to-peer communication. WebRTC is designed for peer-to-peer communication. It is likely that basing your peer-to-peer application on WebRTC will work better, especially with respect to these security concerns, than basing it on Websockets. I understand that you already wrote your application based on Websockets and so the suggestion of redoing it to be based on WebRTC is probably extremely annoying at best. However, at this point arguing against the decision to block mixed-content Websockets is basically completely futile because now Firefox, MSIE, and Chrome all implemented such blocking. (Chrome made that change recently, and I'm not sure if it has reached the release version of Chrome.) > I have asked the same question to many lists (Mozilla, W3C, TC39, etc) and > never got a clear answer why ws with https is forbidden. There were many reasons. The most compelling reason (IMO) is that nobody could figure out a user interface design that can clearly and correctly convey the security properties of an HTTPS page that has mixed content WebSockets. Cheers, Brian _______________________________________________ dev-privacy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-privacy
