Recent searches
Search options
Administered by:
Ⓥ
(he/him) @tortie @sbb @waeiski Yup :/ @Mer__edith Any chance of diversifying away from AWS? Main reason I brought this up is for anti-Amazon reasons, not privacy issues.
@chiraag @tortie @sbb @waeiski @Mer__edith This is not "the elephant in the room" and neither is deltachat a reasonable alternative. The metadata that delta leaves is *significant* and can be tied to an individual. That's why it is crucial to use a "trusted" mail provider, because delta doesn't use any of the advancements in cryptography of the last decade.
The data traces Signal leaves on AWS is not personal data, the metadata is minimal and they make efforts to reduce it further. AWS is still a problem, but one of Availability (what if Bezos cancels his contract with them?).
Please do not compare them based on where they store the data, if the amount and kind of data stored is very different.
@sbb@c.im@ljrk @chiraag @tortie @waeiski @Mer__edith I wish that the #EU would clarify its stance regarding #Signal: *is the AWS hosting problematic for them or not*? Let's assume *not OK* for a minute.
As to a Signal alternative, I *wish* I could recommend #XMPP over #Deltachat today. *AFAIK*, in XMPP, #OMEMO does perfect forward secrecy/double-ratcheting - but alas, the #iOS and #MacOS clients aren't the greatest at present. That lack of all common OS' having feature parity (very reliable notifications, Reactions, etc.) makes me hesitate in recommending XMPP for *everyone* today (but it's great for geeks).
Whereas Deltachat at least has usability parity for features across each OS it supports (which I feel users would highly expect *first*, before demanding a more modern encryption). Yes, autocrypt has no perfect forward secrecy, etc. and other metadata-related criticisms. But Deltachat is simple enough to learn, *allows servers to realistically be used in the desired country*, and works on all the common platforms. It's a decent choice for *today*, as a well-rounded choice (where tradeoffs must be made somewhere). And once the XMPP clients get better (in MacOS/iOS), I'll recommend XMPP as a goto *then*.
@sbb @ljrk @chiraag @tortie @waeiski @Mer__edith
Let's assume it is indeed not a problem for Signal's case, and let's further assume that Delta indeed crucially leaks metadata.
Then it is strongly advised to recommend Signal and advise against Delta chat or any of Delta's metadata-leaking alternatives.
"Let's assume" is really a beautiful phrase, is it not? You can just create just about every reality from thin air that is convenient for an argument!
@sbb @chiraag @tortie @waeiski @Mer__edith EU's stance is quite clear: It's about PII. Signal stores no data relevant to the GDPR in the first place, thus it is completely irrelevant from a legal perspective where the data is stored. But this is only the "legality" and privacy regulatory aspect. Furthermore, from a security perspective, the data stored cannot be tied to you. You can look at leaked internal FBI documents detailing what info they get from Signal, if you really want to. So to conclude this: There's no such assumption to be made.
And sure, users often demand features first, encryption second. But this post was about the handling of PII and not about features. And your "well-rounded compromise" is a very bad compromise indeed, when you don't compromise on properties that are completely irrelevant with proper encryption (location) but compromise on features that are relevant regardless of where your server is located (encryption). This is a very bad trade-off indeed.
If you don't even know what Signal does (not) store on their servers, then I surely hope you don't give any recommendations, because they can only be uninformed.
@ljrk @sbb @chiraag @tortie @waeiski @Mer__edith please don't abandon Signal for those way less secure alternatives because of this. This kind of misinformation puts people in danger.
Here are just a few examples:
https://soatok.blog/2024/08/04/against-xmppomemo/
https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/
@scatty_hannah @ljrk
I think this is a little Signal evangelical, tbh. I think the most common and most valid critique of xmpp + omemo is that you don't know what the servers of the people you converse with log, metadata wise.
The big disadvantage of signal is that you need a phone number. And until very recently that this phone number was publicly announced to anyone in a group chat. Quite a few of people in oppressed and surveilled groups got doxed to the authorities this way.
@scatty_hannah @ljrk Conversations colors every message bright red, that was sent unencrypted, it's not like you wouldn't notice. And the phone number thingy is practically much more relevant than the difference between between 128 and 256 bit AES.
I'm not saying leave signal, signal is fine but not anyone who suggests xmpp or uses it is completely stupid.
@scatty_hannah @ljrk Also it often feels like people suggest signal can't see any metadata, that's not true ofc they know who you are sending a message to. They just don't log it. So you have to trust them (and the authorities who never got any information out of signal so far) that they really don't. I trust that, especially because of the fact in the brackets. But it's not cryptography or any technical security in that regard.
@blauertee @scatty_hannah soatok is not a signal evangelist. He just knows a lot about cryptography. As do the people behind Signal. And that shows.
@blauertee
@scatty_hannah @ljrk
"Quite a few got doxxed?"
Got any proof of this or just more Signal FUD?
@ryansingel @scatty_hannah @ljrk I'm not gonna go into more detail here for reasons. But we're pretty sure that some government secret agents got into some groups and we also know that most of the people in that group didn't take the extra opsec step to get a burner number so, it's pretty safe to say that those agencies wrote down those numbers that are tied to the identities of those people.
I don't see how anyone could see such an obvious opsec flaw as just "FUD".
@scatty_hannah @ljrk @sbb @chiraag @tortie @waeiski @Mer__edith
there's a reason after all @soatok still generally recommends Signal:
https://soatok.blog/signal-crypto-review-2025-part-8/
@ulfi @sbb @chiraag @tortie @waeiski @Mer__edith Think of Delta Chat is PGP-encrypted mails, because that's the core of the protocol. Meaning: The server ultimately knows all senders/recipients, when messages where sent, etc. It also is in the perfect position to carry out sophisticated MitM attacks.
@ljrk @sbb @chiraag @tortie @waeiski @Mer__edith Ok but this is also true for most messengers and even worse for centralized messengers like signal because you can not change to trusted servers in signal 
And Delta Chat forces user verification (at least if you use a chatmail account) so I see no specific MitM vulnerability?
@ulfi @sbb @chiraag @tortie @waeiski @Mer__edith No, that's simply wrong. That data is *not* available to Signal and thus it's not worse because the server doesn't know such data in the first place.
MitM is possible because you have servers that relay messages. End-User verification is neat, but only prevents impersonation, not all MitM attacks.
@ulfi @sbb @chiraag @tortie @waeiski @Mer__edith
For me if nobody works for them then this entire discussion is pure academic speculation. Because we can't be sure what code they are REALLY running. And this is a real problem with centralized platforms.
If I was head of FBI/NSA I would spread misinformation about lack of data from Signal like crazy. So people feel safe and trust Signal.
Of course above is also pure speculation. But plausibility is the same.
@as400 @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith No, it's not, because the data has to get on their servers in the first place. We know how the client works and we can see how a server would need to interact with them. And sure, we cannot know what code they're running but the key architecture of Signal /doesn't require you to trust them/. And that's the damn point.
Which is completely different to, say, DeltaChat, where a lot of trust is still on the server. And with any federated system, you need to effectively trust *all* those servers that are partaking in the federation. Which is honestly a lot worse.
And yes, this is baseless speculation in comparison to the *real* and *tangible* threats that all other messengers pose. Sure, you may distrust Signal for all those things, but then the only reasonable conclusion would be to not use any IM. And not to move from Signal to some federated pseudo-private bullshit of some crypto amateurs.
@ulfi @sbb @chiraag @tortie @waeiski @Mer__edith
There is also another thing one needs to remember. These google binary gms blobs for notifications which are present in every Signal client. Doing god knows what.
I admit I might be biased. Because I don't trust anything made by tech bros and their mega corporations. So I'm trying to stay away from this crap. And feel much safer when using #deltachat with my own mail server for me and my wife. At least I control this "infrastructure" 
@as400 @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith These blobs are probably one of the most researched and reversed pieces of code there are.
Again, it's not about trusting. It's about building things that don't require trust. And your self-hosted mail server is comparatively easy to compromise, it stores compromising meta data – and worse, so does every server you are communicating with. So it doesn't matter at /all/ that you're self-hosting. Or does it matter if you have a local copy of a file, if you also upload it to GDrive (here: send a mail to a foreign server)?
@ljrk @as400 @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith how would you need to trust the server with delta chat, given it's 100% pgp blobs to the server? i've also heard they had multiple audits, the "amateur" label surprises me. i think they even get various funding. (i might be wrong though, feel free to elaborate!)
@ell1e @as400 @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith Because the server stores metadata, you can see who sent what message when. This alone is dangerous enough for activists, but if only one of your communication partners' servers gets popped, this can be trivially correlated on your side and be used against you.
In addition, using PGP doesn't mean modern cryptographic best practices: Forward Secrecy, etc. – meaning a partial compromise has a far bigger fallout than necessary.
Everyone can get audits, even amateurs. But the audit doesn't mean a /thing/ if the threat model of your application excludes various attacks by design.
@ell1e @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith
Threat model, excluding attacks by design you say. I say words are cheap. Or more precisely buzzwords.
Here is how to pinpoint Signal user location without any users interaction. Signal for activists :)
https://gist.github.com/hackermondev/45a3cdfa52246f1d1201c1e8cdef6117
@ljrk @as400 @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith I don't know how signal does it, but as far as I know for Delta Chat if you use a custom email account you can change how long it stores the metadata, which I think depends on after how long of a gap you still want to be able to sync the history to another device. most messengers need to briefly know the metadata anyway, for delivery to the target, and for device sync, etc. for perfect forward secrecy i personally feel like once a device is taken over, most people will have the logs stored locally anyway but i get that a lot of people feel differently about it.
The thing is, DeltaChat is now best used with Chatmail, which give you as many anonymous mail accounts as you want, and that's the simplest installation path (just click on "Create a new profile" and you're done)
So this means an observer can know xcha398ohu@nine.testrun.org had a conversation with h98fah2nhrc@nine.testrun.org. You can't derive much from that. The whole point is to create new profile for specific actions, so only that data can be correlated, contrary to Signal where you have a single account so additional steps need to be taken in the code to prevent linkage.
Also, the default setting is to delete messages from the server as soon as it is downloaded so there's only a window during which information can be seen.
@ell1e @as400 @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith
@ljrk @ell1e @as400 @sbb @chiraag @tortie @waeiski @Mer__edith
Signal knows the IP where a message comes from and the IP where a message goes to. The same as federated systems. The difference:
Signal stores this data for millions of users.
Federated Servers store this data for their users and communication partners.
Both Systems try to avoid metadata but this only work if the service is not infiltrated.
@ulfi @ljrk @ell1e @as400 @sbb @tortie @waeiski @Mer__edith Whether or not Signal "knows" this information, we know from court requests that they don't *store* that information. For example, here's the latest court order they got and their response: https://signal.org/bigbrother/santa-clara-county/
@ulfi @ljrk @ell1e @as400 @sbb @tortie @waeiski @Mer__edith I trust they wouldn't lie to the Feds when asked to turn over all info they have, though...like, *already* the Feds don't like them because they minimize info stored, you don't think they'd shut them down if they were lying and saying they didn't have info they actually had?
@ljrk Large part of the Signal server is Amazon DynamoDB (the database) + Amazon SQS (message queues) proprietary SaaS. And Signal server was never publicly audited. Even if it was audited, Signal never published any audit reports.
@ulfi @monnier @ljrk @as400 @sbb @tortie @waeiski
* If you're that concerned about IP address, you should be using Tor or a trustworthy VPN anyway.
* Amount of data to send is padded in certain cases (e.g. attachments/media).
Also, literally all of that is available to *any* server using *any* protocol, so that's not a unique indictment of Signal (yes, even decentralized systems have access to *gasp* IP addresses, latency, and amount of data).
@chiraag @monnier @ljrk @as400 @sbb @tortie @waeiski Yes that is true, but there are three differences:
1) In a decentralized system I can choose a server I trust or run my own (I do)
2) The amount of data visible to one server is significantly smaller in a decentralized system
3) In a decentralized system no single instance can decide if you are allowed to join the network or not.
@ulfi @monnier @ljrk @as400 @sbb @tortie @waeiski
1) Sure, but it speaks volumes that in almost every federated system, there are a few big players. Email: Google, Microsoft, (maybe) Yahoo, and maybe Proton. Mastodon: m.s, m.o, mstdn.social, etc. None of these technically forbid running your own, but most people don't *want* to run their own (or don't have time), and also don't have time to vet 'trustworthy' servers.
1/?
@ulfi @monnier @ljrk @as400 @sbb @tortie @waeiski
Additionally, you not only have to trust your own server, but every server yours connects to. Your emails are not only stored on your email server, but your receipient's as well. This is even more true with Mastodon, XMPP, etc. Trust doesn't just stop at your server because your data isn't only stored on your server.
2/?
@ulfi @monnier @ljrk @as400 @sbb @tortie @waeiski
2) Agreed. However, this is a moot point if the nature of the protocol demands more metadata be available to the server. Signal's servers literally don't know who sent which message (Sealed Sender), only where to deliver it. Meanwhile, in email, tons of metadata is not only unencrypted by default, but *can't* be encrypted according to the spec. Same with Matrix and XMPP - the servers have access to far more metadata than Signal's does.
3/?
@ulfi @monnier @ljrk @as400 @sbb @tortie @waeiski I mean, again, if you're that concerned about IP address, I hope you're using Tor. Your Mastodon server also knows your IP address, and if it's a VPS then your VPS provider knows it too. We can play this game all day.
Also, IP address != recipient - in most places, multiple people have the same public IP address, so that's not even accurate (even in your home, unless you live alone).
@ulfi @monnier @ljrk @as400 @sbb @tortie @waeiski I think it's also dangerous to call the real work Signal has done to *significantly* reduce metadata exposure to the server 'just marketing'. It not only does them a disservice, it can convince others that Signal is just like any other messenger, and it really isn't.
@chiraag @monnier @ljrk @as400 @sbb @tortie @waeiski I am not concerned about some IPs on some small servers. I am concerned about tons of IPs on a single server. This means big data which means a lot of power in a single hand. I am concerned when a single instance can decide about millions of conversations. Where power is concentrated, it is abused. Communication should be democratic and free, not in a single hand.
@ulfi @monnier @ljrk @as400 @sbb @tortie @waeiski I agree that communication should be democratic and free, but not at the cost of good cryptography. If there's a federated equivalent which is genuinely as good (cryptographically) as Signal, then we're talking. But that's simply not the case right now. At all.
@ulfi @sbb @chiraag @tortie @waeiski @Mer__edith Because they don't have that data. That's not how signal chats work, the server is mostly a rendezvous server, with the actual message sender and recipient not available to the server.
This is key and different to Delta. Where you can use a passive MitM to get a lot of meta data – without breaking the encryption. Feds could literally get a copy of the encrypted messages without you noticing. While encrypted, this is terrible enough already, because recovering a static key is often very realistically possible for them. And since delta doesn't use forward secrecy, they can just store all those message and hit you over the head years later – and decrypt everything. It's fucked, absolutely dumb and irresponsible to use this for activist purposes. It's a fun toy project but has no space in infosec.
@ljrk @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith
You very confidently write things that are not and/or only partially true.
- Signal's server sees the recipient of every message.
- Signal's server does not see the sender of messages if sealed senders is used. However, sealed senders can't be used on the first message to a user. Also the server can always request the client to resend a message without sealed sender without a warning to or a confirmation from the user.
@ljrk @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith
If desired, it would be trivial for Signal's server / AWS to record:
- Every sender/recipient pair for messages that don't use sealed sender
- Disable sealed sender selectively for some messages (e.g. based on recipient, sender's IP address or just randomly distributed)
If we assume AWS to be malicious, they could already know at this point a) who ever chatted with whom on Signal and b) messaging frequency and timings of targeted chats.
@ljrk @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith
Signal also uploads the phone numbers in the contact books of a user's phone. Yes that's optional, but a very large number of users has it enabled. And yes, Signal makes an attempt to be privacy-friendly here by using Intel SGX, which means *they* can't access it, but Intel (and thereby likely the US gov) can.
This feature even affects non-Signal users and users that disable it, as they likely still show up on contact books of others.
@pixelschubsi @ulfi @sbb @chiraag @tortie @waeiski @Mer__edith Yes, an actively compromised Signal server does see message routes – however that's the same for XMPP. I was sloppy in describing the difference, but I honestly grew tired after such load of bullshit here.
A Signal server that's popped at one point in time does not have routing history and sealed sender then prevents future chats getting compromised. AFAIK clients would notice if the server doesn't allow sealed sender suddenly.
It's still suboptimal how Signal is positioned w.r.t. geo-political threats – but the named alternatives are so much worse in all these aspects, it makes me cry.
IIRC Signal uses bloom filters for the phone matching thing but I may be mistaken there.
But at worst govs know phone numbers you have (which is not enough for anything) or who you wrote with once (neither) while stopping you to be able to covertly continue messaging (attack against Availability). The latter thing is IMHO the worst of them, and Signal In-Availability is the main threat I'm seeing.
@ulfi @sbb @ljrk @chiraag @tortie @waeiski @Mer__edith
The core difficulty for most federated messaging systems is that there's a lot of information available without breaking encryption. XMPP and email (DeltaChat is built on the same core as email) have this problem. There are basically two cases:
- You're using the same mail server as a bunch of other people.
- You're using a self-hosted or otherwise small mail server.
In the second case, simply seeing a connection to that mail server gives a good indication of who someone is talking to. A passive adversary can monitor connections to that server and, even without breaking TLS, let alone the end-to-end encryption, can see who is talking to you.
In the first case, whoever operates the server (e.g. Google for gmail) can see the sender of every incoming message and the receiver of every outgoing message. Even if there's end-to-end encryption for the messages, they can build a connection graph.
If you want to use it for, say, organising a union, it doesn't actually matter what the message content is, the metadata is enough for retaliation.
For XMPP/email, a lot of the privacy guarantees are as strong as the least trustworthy server in a communication. If one person is using gmail in a group thread, Google will still be able to learn the identities of everyone in that chat. Again, this doesn't depend on breaking encryption and even if there is 100% secure end-to-end encryption, they can still learn a lot from the metadata. And, because of the federation, I have to trust my server and your server if we want to talk.
Signal has other problems, but avoids these. They've built the system so that they don't know this metadata. When you send a message with the sealed sender feature (on by default), you connect as an unauthenticated users and deliver a message to a mailbox. The receiver connects later and grabs the message and decrypts it. The server doesn't have an automatic way of determining the sender's identity (though they probably can if they correlate IPs - using Signal over TOR can mitigate this) and so can't build this graph of the people who are communicating.
For most attacks, the metadata is at least as interesting as the message content.
Signal isn't above criticism. I've written other complaints about them in the past. The reason I recommend Signal is that all of the problems I have with Signal can be fixed with incremental changes, whereas the problems with XMPP and COI can be fixed only by completely redesigning the protocol from the ground up in a way that would break all existing clients and servers.