Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: