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.
The only way you would know there is a blockchain involved is by reading the white paper or looking at the code. There are is no currency or token involved when using the app. I don't understand your last sentence at all.
I think session has some advantages over signal. Such as onion routing, not needing to interact with centralised servers, and not requiring a phone number.
Not who you're asking, on a technical aspect, briar is p2p so the recipient must be online in order to send them a message, there's no server to queue and send the message when the recipient comes online. This affects UX quite a bit as well.
While Signal is good for encrypting messages, you can't be sure Signal.org isn't hiding messages from you or otherwise blocking communication, and for Whatsapp, you can't view message history without keeping a backup file. This seems to solve both problems.
If the encryption is ever cracked now everyone can read everyone's messages though can they not? I know it feels unlikely to happen today, but tomorrow's technological breakthrough could make anything happen in a matter of months. The future is uncertain.
The encryption of the messages themselves is largely shared with every other part of cryptography - ed25519 keys are used almost exclusively over rsa for anything new and AES 256+ protects every single TLS connection. A lot of the internet hinges on the encryption used being resistant against known attacks.
There has been heavy development from the initial signal fork. In fact signals code has been completely gutted because using it for a decentralised messenger came with a lot of issues.
In this case the blockchain is used to incentivise the people running the routers. If you force them to stake funds then you ensure you have enough good actors to prevent bad actors from spying on your messages
My understanding is Matrix uses the same crypto algorithm as Signal but a completely different architecture to support federation and not require phone numbers.
How does Session compare to Matrix? Why another encrypted chat app that doesn't federate?
To be honest I don't have that great of an understanding of Matrixs implementation but they are also doing great work in the decentralised messenger space and its all helping!
My understanding for matrix is that a volunteer hosts a server which clients can connect to, and that server acts as router to other servers which will forward it onto the destination.
In sessions case the servers (Service nodes) are incentivised so they are not volunteers, and clients can connect to any of the service nodes. Messages get onion routed to a group of service nodes known as the users "swarm" and when a user wants to receive their messages they similarly request them from the swarm.
There are likely pros and cons of both implementations. Matrix you call federated where as session is decentralised, which is a fairly significant difference. Sessions infrastructure mitigates things like the federated servers knowing the IP address of the client, clients having to trust the first hop, and metadata leakage to the federated servers.
> Just reminding people that Session is nothing more than an implementation of signal with a blockchain behind it for some reason.
You do realise that Signal also has a blockchain / cryptocurrency project associated with it as well? [0] Which makes it no different to Session.
> 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.
Exactly. Just like how Signal is doing the same by also shoehorning another cryptocurrency called MobileCoin? [0] Which basically enables scammers, criminals and hitmen to encrypt and hide their payments and also use Signal for their illegal activities?
This is the road to hell with encrypted blockchains and private cryptocurrencies and what Signal is no different to Session.
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.
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.
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.
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".
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.
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.
Nobody wants to MITM every conversation, they want to MITM the conversations of valuable targets. This can be done at scale without breaking any cryptosystem, and with low probability of detection, by a well-resourced actor in possession of private keys that are ostensibly controlled by Apple and/or Google.
No prizes for guessing entities that fit this description.
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.
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.
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.
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.
Yeah, I had to do a double take when I saw Signal included in that sentence.
I value privacy & security personally, and want Signal to succeed, but any compromise to UX in the name of privacy & security is going to make it impossible for Signal to compete as a mainstream messaging platform where network effects are paramount.
True, but if you're just using phone and desktop, Signal works well.
My point here isn't that Signal is perfect, just that the implementations by Signal and others shows that support for e2ee DMs on multiple devices is solvable. Teams can decide what their users need and how much flexibility is worth supporting. A public company of Twitter's size is clearly capable of solving this for some broad set of use cases.
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.
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?
> 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.
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.
> You cannot solve social problems ("how do i know I can trust X") with technology. ... Indeed, you trust in your computer to display the right hash, and to compare them correctly.
Are you saying "No one should ever use a computer or phone because it might be spying you"? Every time someone uses Twitter they are using technology to solve a social problem (e.g. "I want to know what people I care about are talking about").
You're right that ultimately some unavoidable trust decisions have to be made, but with open source software (and multiple reviewers with hard-earned long-standing reputations) those trust decisions become even easier to make than "Do I trust my government not to illegally wiretap my phone call?".
> Secure cryptography in the browser is still (generally speaking) adjacent to a joke ... probably exciting to people looking for easy ways to claim Twitter's bug bounties.
If you think that secure cryptography in the browser is a joke then feel free to earn $10,000 by hacking ProtonMail.[0] You'll be laughing all the way to the bank, and actually helping to improve the security of millions of people.
> If you think that secure cryptography in the browser is a joke then feel free to earn $10,000 by hacking ProtonMail.[0] You'll be laughing all the way to the bank, and actually helping to improve the security of millions of people.
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...
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.
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.
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.
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.
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.
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?
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.
Additional to what has already been said, they could choose homomorphic encryption as WhatsApp appears to be now using. No person can read the messages, but the computer can scan and analyze them.
If Twitter actually does implement E2E encrypted DMs, I predict there will be a LOT of hand-wringing.
The same NYT and WaPo writers who have been writing attack pieces on Elon Musk for the past month will write about how horrible it is that people can communicate in private and how horrible their communications might be. Maybe a few EU politicians will make some threatening noises about banning Twitter, as well.
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.
I am both an idealist and a realist. I'm very much aware of how much surveillance governments run on their own citizens. There's no place in the world that is exempt from this. So you could either move to Mars and hope the Elon doesn't do things like everyone else, or you can try to effect change here, but it's an uphill battle. All governments are drunk with the power they have, and they are not going to give it up willingly.
And yet if you look at the state of the art in surveillance for most governments in the world (buying tools from NSO Group) it seems that many governments have given up on mass surveillance of messages in transit, and instead are focusing their resources on targeted surveillance through device hacking.
So some power has clearly been given up. Not willingly. But still it has.
And in the Snowden leaks you see that even the NSA had problems with tools like Tor and Tails.
Granted that was a decade ago, but there's no reason to believe that work by privacy activists to promote adoption of practices like SSL and START-TLS, or tools like Signal, has not had some impact on the cost and availability of mass surveillance to governments.
I'm not sure where you get your information, but the only reason a government would abandon "in-transit" surveillance is if they have full coverage from another source.
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.)
How does encryption work? If it’s truly end to end encrypted then you can’t see your messages on multiple devices or recover your old messages from another device, right? If your encryption key is not in the cloud then it’s on the device right?
The encryption key can be on the cloud further encrypted with an "E2E" password. When you add a new device, you just enter the E2E password and all your messages can be seen.
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.
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.
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.
Even if that's true, it's still valuable and praiseworthy for Twitter to take this step.
If some small open source communication tool that was important to Hacker News readers added end-to-end encryption we'd all be cheering, no? So why isn't it a big deal (in some sense at least) for Twitter to do it?
Based on the number of people replying "don't post twitter threads, they're user hostile 1/22" I am not sure twitter is celebrated here by the majority.
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.
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.