4 ms·
It feels like the mentions of Signal and its protocol in this blog post overlook the reality that you can't really do true secure encrypted Twitter DMs, at best
by kevingadd 5y ago
It feels like the mentions of Signal and its protocol in this blog post overlook the reality that you can't really do true secure encrypted Twitter DMs, at best you could do a loose approximation of it that may not provide much security value in exchange for the inconvenience. Why?
A significant % of Twitter usage is through the website (either twitter.com or tweetdeck), which means the decryption would all have to happen in javascript in an effectively untrusted context - it doesn't even have the moderate protections offered by a chrome app/extension, and there's no clean way to securely store encryption keys for a webpage (afaik) without the aid of something like a Yubikey or Windows Hello. Secure cryptography in the browser is still (generally speaking) adjacent to a joke, and the idea of doing it in Twitter.com - a very complex website with a huge attack surface that gets loaded into iframes/popups and targeted by various extensions - is probably exciting to people looking for easy ways to claim Twitter's bug bounties. There are lots of other factors that will make this difficult but as long as the core of your product is a webpage with a history of severe quality issues you're basically using encryption for branding, you're not going to protect messages from anyone except perhaps disgruntled customer service staff.
That's ignoring the UX issues as well - when Line rolled out E2E encryption for messaging, they had to coax every user into enabling encryption and authenticating all of their devices to have access to their personal keys, so you had a patchwork of encrypted and non-encrypted conversations. And now if I lose my primary device (the keyholder) there's a convoluted process to attach new encryption keys to my account and the only way to recover my DM history is from a backup.
Am I supposed to believe they'll convince every Twitter user to jump through all the hoops to enable e2e encryption for DMs and manage encryption keys securely? Absolutely not. They'll have to do a ton of work to provide a comfortable user experience, at which point it'll be trivial for an attacker to get their hands on the encryption keys if they already had access to DM content.
- AshamedCaptain 5y agoBesides, what exactly would E2E protect from? Your Twitter DMs (assuming you already use HTTPS to access Twitter) only travel through one party: Twitter itself. So basically E2E would be to protect your message contents from Twitter itself? First, they already have all the metadata they could potentially want, the message contents itself is virtually nothing. I'm quite sure they're even logging keystrokes in their website for autocomplete/analytics/advertisement/whatever purposes. Second, they control the entire platform, including the code you would be running to encrypt/decrypt the messages! What would prevent Twitter from sending a specific party a special version of their JS that sends an obfuscated unencrypted copy of your messages to the mothership? All this conversation is just security theater..
- dane-pgp 5y ago> What would prevent Twitter from sending a specific party a special version of their JS that sends an obfuscated unencrypted copy of your messages to the mothership? I'm glad you asked. This is exactly the same problem that WhatsApp have been trying to solve for their web app, and they came up a browser extension called meta-code-verify[0] which checks the hash of the code received against an external append-only log. The extension only supports the WhatsApp site so far, but should be flexible enough to support others that opt into it. Of course ideally this approach would become popular enough that the technology would be integrated into the browser itself, so that users wouldn't need to install the extension at all. I also hope that ProtonMail push for this too, since they are subject to the same threat model and care about open source security. [0] https://github.com/facebookincubator/meta-code-verify https://github.com/facebookincubator/meta-code-verify
- kevingadd 5y agoThere's also a HTML mechanism that lets you put expected hashes in for script resources etc and the browser is supposed to reject them, but of course because this isn't code signing, all the attacker needs to do is compromise the HTML and put in their own sabotaged hashes. Sigh...
- remexre 5y agoYeah, I thought the threat model there was "people sure do love random not-particularly-trustworthy public CDNs"
- fao_ 5y agoYou cannot solve social problems ("how do i know I can trust X") with technology. meta-code-verify is itself vulnerable to the trust chain. You trust Mozilla/Chrome not to alter the version you install from their store. You trust that GitHub isn't going to pull a swifty on you, or Facebook. You trust that the server hosting the append only log hasn't been unknowingly compromised, or the interpreter, or your machine, etc. ad nauseum. Indeed, you trust in your computer to display the right hash, and to compare them correctly. What's more is that this browser extension is useless in the context of this thread, because, as the grandparent post points out: > A significant % of Twitter usage is through the website (either twitter.com or tweetdeck), which means the decryption would all have to happen in javascript in an effectively untrusted context - it doesn't even have the moderate protections offered by a chrome app/extension, and there's no clean way to securely store encryption keys for a webpage (afaik) without the aid of something like a Yubikey or Windows Hello. Secure cryptography in the browser is still (generally speaking) adjacent to a joke, and the idea of doing it in Twitter.com - a very complex website with a huge attack surface that gets loaded into iframes/popups and targeted by various extensions - is probably exciting to people looking for easy ways to claim Twitter's bug bounties.