Mozilla vs Google on user privacy: WebSockets
There’s a disagreement going on at the moment about user privacy. Fundamentally, Mozilla and Google have a different vision of what a browser does. Chrome is “thin”, and Google has explained that the minimal UI around the web content is part of their vision of simply wrapping other content and running it (securely). Firefox is “fat”, an all-singing, all-dancing application that’s meant to do everything users need, so it’s there for web authors to use but not extend. For Chrome, every web page is an app, something you can pin in an app tab and make a start menu shortcut too. They want each page to be like a desktop app. Mozilla absolutely stands against that. A page is a page, and can’t upstage the browser, and can’t act like a desktop app.
Here’s the sticking point for Mozilla: navigate to https://www.websocket.org/echo.html and try and connect. No luck in Firefox unless you select TLS, but in Chrome it works fine.
The general principle is that Mozilla does not trust any web page to guard a user’s privacy, but Chrome believes in a different world of webapps where it’s absolutely OK to run a web page as you would a ‘proper’ application.
Suppose you could make a non-TLS WebSocket connection from a TLS page. The users might be entering sensitive information on this secure page, and as far as the browser’s concerned, the information is flying off the page in the clear. Worse, the page is compromised because unverified, insecure data is flowing into the page from outside. From the vendor’s point of view though, it might be different: suppose you implement a nice secure protocol using ECDH+RSA auth+AES-GCM (calling into OpenSSL/NSS crypto routines via the WebCrypto JavaScript wrappers). The connection could be totally secure, but the browser can’t verify it.
Why not just make a TLS connection? Because browsers only implement the CA model for checking identity. That’s a big namespace of peers, covering all domain names, but you might want to connect to a different sort of entity (a Facebook peer, an entity inside a different namespace). That’s a big problem for Mozilla, because they can’t verify identities in other namespaces, and won’t give webapps the power to implement these things themselves.
Mozilla after all may have a point: until a few years ago, Facebook sent login cookies out in the clear. How can a web user know who to trust to implement the right security?
So, we’re stuck. We have a product that works in Chrome, but not Firefox, so we can’t offer it as a webapp. Instead web authors are forced to fall back to asking users to download a small standalone native binary to run. That’s a shame, and we want a way around that.
I should close by pointing out there may be a way ahead, using WebRTC. It’s still unclear whether it meets our use-case, but it could potentially work for us too. Unfortunately the only bit I’m interested in, data connections, hasn’t yet been fully implemented by anyone yet, so it’s too early to say.