Hacker News Reader

Comment by Techbrunch | Hacker News Reader

Reasons from not enabling it by default by @alexstamos (CSO @ Facebook):

- FBM is multi-device, and we'd like to see E2E usability improve to support this. For now, pick one device and keys never leave it

- Secret conversations don't currently support popular features like searching message history, switching devices, voice/video, etc

- Hundreds of millions use Messenger from a web browser. No secure way to verify code or store keys without routing through mobile.

"We don't want to disrupt people's current experience."

Source: https://twitter.com/alexstamos

View on HN

Signal Protocol already supports multi-device. We've encouraged them to enable that for Secret Conversations, and hopefully they'll continue to iterate towards support for e2e by default.

That's nice! :)

What did the OP mean by "No secure way to verify code or store keys (in web browser) without routing through mobile" ?

There's no way for a site to securely store keys in the browser. The server can't put them there because then the server would have them too. A client-side script could generate them, but it can't store them without extensions (or the server via some JS it sends) also having access to them.

This is why Signal and WhatsApp require the client to run on the phone - the phones are doing the decryption for the web apps.

This is flaky, consumes a lot of battery and generally is somewhat error-prone - probably not something FB wants to deal with.

Server would have the keys _because_ the client-side code can send it to the server. That's also possible in the native app, isn't it?

Yes. But let's assume FB doesn't want the keys (because if they have them, then it's no longer E2E encryption), then client-side generated keys in a browser are still exposed to XSS attacks and extensions.

Installing a malicious extension, tricking users into typing commands in the developer tools, XSSing FB, all of these are much easier to do than attacking a native app on a phone.

How is the possibility of XSS worse than the status quo (plaintext)? Thats like saying SSL is useless on desktop because root kits and keyloggers exist on desktop.

A false sense of security can be more damaging than no sense of security.

Certainly it can be important to know when you have a "no compromises" security option versus "mostly better than plaintext but maybe not secure".

It could be a UX judgment to not confuse users they have a "secure connection" when in fact they might not. Look at all the various attempts over the years browsers have made to keep the UX semi-reliable and easy for users to understand whether or not their SSL connection is secure.

The apps are updated relatively infrequently, and you can put off updating to see if problems are found with each release. In the browser, you'd have to analyze every script Facebook ever sends you to see if it's exfiltrating your key.

Valid point. But apps too can have non-obvious backdoors that don't require updating the new version. If you don't have source code and reproducible builds, you are already fully trusting the server.

Actually, Signal works without routing the messages trough your phone. Instead they use a browser extension to store the keys client side, which acts as a full client with its own, separate keypair.

You could even register only the browser, without having a smartphone at all.

Signal protocol supports multi-device when the device is capable of storing the keys (like the Signal desktop app). His point about web browsers still stands I believe.

Although you could use local storage, you would have to do that with every browser you logged into and also somehow make it user-account-specific. I definitely see the challenges there for them.

What would you think about using a user's password to encrypt the browser keys and store them on Facebook's servers? Is that too large a compromise for usability?

Some notes:

- Signal does have some multi-device support (the Android and Desktop clients, iOS not yet). I still sometimes have minor issues but overall it works very well.

- Signal does include end-to-end encrypted voice calls (what used to be called RedPhone) that also work quite well. It's my go-to "call from Wifi abroad" solution to avoid roaming charges, and also works very well with a good 4G/3G signal

- The browser issue seems unsolved as of now, WhatsApp's web thingy (routing through the phone) seems to work quite well but obviously only if the phone is on, and WhatsApp requires a phone while FB messenger doesn't so this isn't an option for them.

Given that I don't have a smartphone, and use messenger.com; yeah, I wouldn't want it to require a mobile.

Downvotes for not owning a smartphone? I think we can agree that not requiring a mobile phone to use a messenger is a nice feature.

Reply on news.ycombinator.com