@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.
@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*.
@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.
@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.
@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.