3 ms·
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?
by nileshtrivedi 10y ago
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?
- pilif 10y agoYes. 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.
- aianus 10y agoHow 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.
- WorldMaker 10y agoA 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.
- sp332 10y agoThe 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.
- nileshtrivedi 10y agoValid 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.