[HN Gopher] What happens if Twitter gets encrypted DMs?
___________________________________________________________________
What happens if Twitter gets encrypted DMs?
Author : DerekBickerton
Score : 56 points
Date : 2022-05-08 16:44 UTC (6 hours ago)
(HTM) web link (getsession.org)
(TXT) w3m dump (getsession.org)
| DerekBickerton wrote:
| @dang can you amend the URL to:
|
| https://getsession.org/blog/twitter-encrypted-dms
| charcircuit wrote:
| I feel like it would be pointless. As an end user I don't really
| get any benefit from this change and encryption typically makes
| the user experience worse for the end user.
| [deleted]
| Vladimof wrote:
| Here is the direct URL: https://getsession.org/blog/twitter-
| encrypted-dms
| DerekBickerton wrote:
| Oops. If I could delete it I would, but HN won't let me.
| brian-armstrong wrote:
| When the party storing the DM controls key storage/exchange, does
| this matter? If you can't verify the other party's keys are in
| use, and ensure no other keys are being silently added, this type
| of encryption is just checking a box.
| kodah wrote:
| There's implementations where it would work, be effective, or
| be both.
|
| It all depends on what the key material is protected with at
| that point. If it's something provided client side and is
| transmitted securely, and used blindly, then it would work.
| Anything short of that would probably trigger my curiosity.
|
| Edit: This kind of statement also needs to b prepended with who
| you're trying to protect yourself from, because that entirely
| changes the game.
|
| Edit: There's also key exchange (and derivation) that could
| happen and impact the effectiveness of this process.
| brian-armstrong wrote:
| If the client is entirely in the browser, it doesn't
| particularly matter if they give you some keys to scan. You
| don't know what it's actually doing, or how the keys are
| generated.
| kingcharles wrote:
| It would need to encrypt the messages in the browser before
| they are sent, for a start.
| ajconway wrote:
| Almost every encrypted app allows users to check their keys via
| QR code scanning or string comparison. If twitter adopts
| encryption, I hope they will let users do that.
|
| At this point the same entity controls both key distribution
| and the messaging channel, so information-theoretically it may
| seem that encryption becomes pointless because it's very easy
| to perform a mitm attack. However, since any user can check
| their keys (at least in theory), the service cannot mitm
| _every_ conversation. This prohibits mass surveillance which is
| good enough.
| brian-armstrong wrote:
| Aren't you also trusting that their client actually renders
| all the keys in use though?
| madeofpalk wrote:
| I would imagine that for people that actually care (whose
| threat model involves governments targeting them
| specifically), then they're aware of all the tradeoffs
| involved and can make informed decisions (and know how to
| use more secure, harder to use platforms). For everyone
| else, I think "e2e encrypted by maybe twitter is lying to
| you" is no worse than the current state of play.
| ajconway wrote:
| We do, but that would require the company to lie about what
| they are doing with the app. At Twitter's scale it's very
| possible that someone would notice and leak that.
|
| The goal as I imagine it is to go from "Hundreds of Twitter
| employees can definitely access my messages today and
| anything I've sent and received up until now" to "Twitter
| will likely need to perform a MITM attack to read my
| messages starting from the moment when the attack was
| performed. Maybe they have a secret backdoor, but it's
| probably too valuable to use on my cat photos".
| brian-armstrong wrote:
| If it's just about internal access, how is it any
| different from implementing access controls? Put another
| way, at Twitter's scale, any employee access to
| production data is intentional.
| ajconway wrote:
| Correct, but with everything in plaintext one just needs
| to read a file stored somewhere in a database. With
| encryption, one needs to perform an active attack.
| dontcare007 wrote:
| You mean like leaking the collusion between certain
| parties to down-rate certain other parties using a secret
| algorithm?
|
| It would only take a couple of people I'm key positions
| to accomplish it.
| kevingadd wrote:
| 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 wrote:
| Besides, 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 wrote:
| > 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
| fao_ wrote:
| You 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.
| kevingadd wrote:
| There'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...
| vmception wrote:
| I got added to some twitter DM groups recently where people talk
| about fast moving trends. what a shitty interface. can't @
| mention people in the group without it trying to search all of
| twitter, you don't know their usernames because its different
| from their profile names, and the @ mention search doesn't even
| try to link them. can't quote reply or link to a prior message.
|
| Encryption is the least of the things, all that means is that two
| of my devices probably won't see the same conversations.
| holmesworcester wrote:
| WhatsApp, Signal, and Element all handle multiple devices
| fairly well. Twitter should be able to solve that too.
| eptcyka wrote:
| Signal doesn't handle mutliple devices nearly well enough.
| tadfisher wrote:
| Great example of Twitter's product issues. You can tell the DM
| groups feature was someone's side project in the early years
| that has been left in maintenance mode. No team wants to
| prioritize it because a) no one has ownership over the product
| and b) the shitty experience leads to shitty metrics that make
| it hard to justify fixing it.
| unstatusthequo wrote:
| If they do, you'll see government requests for backdoors into
| them, and maybe Musk fights, maybe he doesn't. But given that all
| cellular providers, Meta, Apple, and Google are all playing nice
| with law enforcement on wiretaps, I see no reason that Twitter
| would be any different, ultimately. The only safe encryption is
| one you control, and is not centralized to some giant corp.
| Ekaros wrote:
| Yeah, I really don't get point. If you want to have secure
| encrypted communication channel don't rely on any platform. Do
| it yourself with some standard tool or protocol. And then use
| third channel to verify the material.
| amelius wrote:
| Good luck convincing the people you want to communicate with
| to follow your scheme.
| luis8 wrote:
| What about opensourcing the app and compiling it yourself?
| aspenmayer wrote:
| I think it's worth trying, even if it's hard to implement. If
| Signal and WhatsApp can do it, Twitter can too.
| amelius wrote:
| But it looks like EU is about to force platforms to open up
| their protocols to each other:
|
| https://www.pocket-lint.com/apps/news/apple/160548-eu-s-digi...
|
| > (...) chat apps, such as WhatsApp, Facebook Messenger and
| iMessage, will have to be interoperable with each other and
| competitors.
| flancian wrote:
| I try to move all Twitter conversations to Matrix, IMHO it's good
| enough, federated and supports E2EE encryption already. Not all
| people are ready to make the jump but an increasing ratio seems
| interested.
|
| Also it's a bridge/bot friendly platform and Maubot is great.
|
| https://anagora.org/matrix https://anagora.org/maubot
| lawl wrote:
| > IMHO it's good enough
|
| Im a huge fan of matrix and use it daily. Just to make that
| clear upfront. If you read HN you should use it.
|
| I don't think it's ready for non-technical people. The
| federation part still causes issues. Occassionally messages get
| stuck etc. I would not feel comfortable telling my mom to
| download element to text me.
| geranim0 wrote:
| FWIW my I made my grandma download element to text me and
| she's using it without problem
| CJefferson wrote:
| I can believe that, my problems have always arisen when
| people want to transfer to another device, or access from
| two devices at the same time.
|
| I know such things are possible (it works for me) but many
| people get themselves in a horrible mess.
| GekkePrutser wrote:
| Using it from 12 devices now.
|
| But yes the client validation and key exchange is
| something non technical users don't grok :( Even though
| they've clearly spent a lot of time making it as easy as
| possible.
| raybb wrote:
| For someone who is technical but not interested in self
| hosting so you still recommend it? Do you recommend starting
| with trying to get bridges setup or what's the best first
| step?
| lawl wrote:
| Download element.io, make an account somewhere. Matrix.org
| has a bridge for e.g. libera IRC, so you can use it like an
| IRC client with a free bouncer too for example.
|
| Also since the protocol is http, a friend of mine lets his
| servers send him notifications about cronjobs by just
| curling an endpoint. Lots of things you can do with it.
| hadlock wrote:
| Twitter has a fraction of the user base of something like
| Whatsapp. Do we really care how DMs work for a platform like
| Twitter?
|
| At best, for secure messaging I would expect someone to use
| twitter DMs to arrange a switch-over to a platform like Whatsapp
| or Signal
| interestica wrote:
| I mean Facebook has a standalone DM app and Instagram has done
| it too (and I guess the messaging systems have now just been
| combined sort of?). It's not out of the question that something
| like 'Twitter DM' comes out where it will be used to slowly
| push users to the platform in a more general sense.
| holmesworcester wrote:
| Even if Twitter is small compared to WhatsApp, having another
| major household-name service add "e2ee by default for DMs" is
| good for the world because it brings "e2ee by default for DMs"
| closer to being a standard practice, the way SSL has become a
| standard practice.
|
| At first, only a handful of sites implemented SSL for all their
| pages, but eventually a critical mass of sites did it, and at
| that point every major site had to do it.
|
| To make e2ee as ubiquitous for messaging as SSL is for
| browsing, we'll need a similar dynamic where it becomes
| standard practice, and each major site that adds it is a big
| victory.
|
| Also, Twitter might have a smaller userbase, but journalists
| and political figures are among its most active users, so the
| social impact (e.g. to the health of democratic governments) of
| protecting the privacy of Twitter users might be on the same
| order as that of protecting the privacy of WhatsApp users.
| hadlock wrote:
| Not only is twitter small compared to WhatsApp, it's tiny,
| and has had static (no) user growth for seven years
| (previously reported 300 million active monthly users,
| recently announced it had been over reporting...). The tech
| and journalism communities exist in a bit of an echo chamber.
| Twitter might be a "household name" but it's importance for
| mass communication is a bit overblown.
| SahAssar wrote:
| Having to give out your phone number (and even requiring a
| phone number in the first place) to have a private conversation
| is terrible for privacy.
| anonymousiam wrote:
| It will never be "secure" because no government would allow that.
|
| https://www.reddit.com/r/privacy/comments/nl8sdb/im_suspect_...
| zaik wrote:
| That's why I run an XMPP server for my family/friends and
| refuse to install any centralized messaging app.
|
| (Also can we please have a standard for messaging, every app
| cooking up their own protocol and not working with anything
| else is getting embarrassing.)
| holmesworcester wrote:
| This degree of skepticism can be counter productive.
|
| If everyone in a democracy agrees that "governments would never
| allow" large companies to implement end-to-end encryption,
| then, as a result, governments never will.
|
| Also, some large companies _do_ offer it, notably Meta and
| Apple. Apple offers a backdoor in the form of unencrypted
| iCloud backups. And Meta may also offer a backdoor to the US
| government, but they also might not. And there are at least a
| few large governments they _don 't_ appear to offer a backdoor
| to, as evidenced by Meta executives getting arrested for
| contempt of court in e.g. Brazil.
|
| Twitter encrypting DMs is definitely an improvement, just as
| Twitter adding SSL was an improvement.
|
| Security and privacy ultimately depends on threat modeling. Any
| given improvement can make the difference between the
| suitability or unsuitability of a tool _for a given threat
| model_.
|
| And since peoples' threat models are extremely diverse and
| always changing, adding e2ee to a service of this scale can
| have a big impact on the security, privacy, and safety of many
| Internet users.
| lmc wrote:
| I've flagged this - it's some combination of ad and FUD.
| holmesworcester wrote:
| I agree. It's FUD on a hot-button topic as an attention-getting
| tactic.
|
| (As I wrote the above phrase, I realized that I could have
| abbreviated it to "tech journalism." Sigh/ugh.)
| betwixthewires wrote:
| Just reminding people that Session is nothing more than an
| implementation of signal with a blockchain behind it for some
| reason.
|
| I tried it, I was interested in it, I always like to try new
| encrypted messaging methods. I like blockchains, but I don't like
| when one is shoehorned in when it is unnecessary, and I'm
| especially wary when a project with very little original
| development includes blockchain stuff, scams abound.
| mnd999 wrote:
| It's gonna take more than that to stop Twitter's decline.
___________________________________________________________________
(page generated 2022-05-08 23:01 UTC)