Email metadata is crucial to the most basic functionality of email (where it came from, and where it has to go).
this is true for virtually all other messaging platforms, like XMPP, Matrix, IRC, WhatsApp, etc. to deliver a message obviously the server needs to know from whom and to whom to deliver the message, it is super weird that this site list it as a special “metadata leakage” in email.
and some email data can never be encrypted inherently due to how email is designed.
[…] it cannot encrypt email metadata, only the message body itself
literally the only required field is the From field because some servers might compare you are the owner of the address before allowing you to send, but the To field can be also the same address as From field while never revealing in the headers to whom was the email actually send to. Also when using anonymous email address randomly generated, like in the case of Delta Chat’s chatmail servers, there is no identity tied to the email addresses.
Email metadata is stored in the message header of the email message and includes some visible headers that you may have seen such as: To, From, Cc, Date, Subject
way back since 2018 Delta Chat and some other email clients like Thunderbird (https://github.com/thunderbird/thunderbird-android/pull/3309) that support encryption, encrypt the Subject header as well
Basically if you use Delta Chat and email servers optimized for security email can be secure, and would be nice if the Privacy Guide page could provide some more modern information to avoid the spread of urban legend like this one:
Unfortunately email wasn never built for privacy. As DeltaChat and ArcaneChat both run on top of email, they suffer from many of the same privacy issues that have existed since the inception of email, over 50 years ago.
published by a person linking to your page as source here: https://lemmy.ml/post/26872974/17126836
Well, I do not understand the very technical nature of email and especially how encrypted emails work and the things they are supposed to have for it to be used or considered a viable and reliable for private messaging/communication.
That said, from all that I have read and understood about Delta Chat and even XMPP chat services - they are fantastic options for your highly private and encrypted communication needs. And I personally do advocate for it and recommend to others along with Signal. I think they should be recommended by PG too but I do not know the specific reason why they are not. It is likely a technicality or a specific requirement as they have set for why it may not qualify (but that’s my best guess).
We are making this statement relative to the instant messengers we do recommend, which virtually all provide above-average metadata protection across the board (besides Matrix but that is noted as well).
one thing is headers and another actual sending instructions, “metadata leak” is considered only when you leak to another server to whom your server sent the message to, while my server (perhaps self-hosted?) process the request to send a message to N email addresses that doesn’t mean I have to put them in any header, hence the receiver email server can’t know the full list of people I sent the message to, only that one of their users received it.
I really doubt how “seal sender” from Signal can be considered safe, it is opportunistic, it is no where shown in the UI if your message is sent over sealed sender, you have to enable some obscure option in the app settings and THEN you are able to see an icon ONLY when manually selecting a message and checking the message metadata/info, are we supposed to do this painful manual check for every message to verify it was sent with sealed sender???
besides the point that I am really skeptical about how is this really helping, you are connected authenticated to the signal server they know your IP and timing, it should be possible to know that the same IP that is trying to send unauthenticated with sealed sender is the same IP of the account tied to phone number X that is connected at that right moment listening for incoming messages, also in an active conversation between two persons it is obvious who they are even with sealed sender BECAUSE THERE IS A CENTRAL SERVER, that can do a lot of network analysis by having the whole picture of the network
anyways, thanks for replying I think some things make sense, but the “it is only possible to encrypt the body, the subject is leaked” is obviously wrong
also the “the date you send the message is leaked” this is an optional header it could have whatever date, but anyways can’t any server know the date you sent a message by, well, just checking at the time you are actually sending the message? this is also questionable “metadata leak”, in any other platform the server knows at what time the user is sending the message, more in “instant messengers”
I think that this is getting too much into the difference between what people commonly understand email to mean and what email technically is on a protocol level.
All of our email guides are written for the common understanding of what email is, which is what email always has been since like the 70s.
You can probably build a secure platform on top of anything, including email, but arguably if you do so it is no longer email as people understand it, and you’re essentially relegating email to be a dumb pipe to transfer bits. So… I think it is confusing to still call this new application email.
I think you realize this because ArcaneChat’s website doesn’t mention “e-mail” once on its homepage, and Delta Chat seems to be (correctly IMHO) largely moving away from “e-mail” in their marketing and promoting Chatmail instead.
This would only be the case if you are sending to multiple receiver email servers.
I somewhat agree but this is why I said above-average and not perfect, because some attempt at obfuscation is made.
Subject line encryption is not super common among PGP email clients as far as I know, so while I know it definitely does exist I would not characterize the existing statements as “extremely misleading” either.
I will work on some changes in this draft:
FYI - the primary reason we don’t recommend email has always been PGP’s lack of forward secrecy, not primarily its metadata issues. I can reword some of these sections to make that more clear though.
but if some bold claim like “subject can’t be encrypted by the apps that use OpenPGP, they only encrypt the body” this is just misinformation, isn’t the whole point of a “privacy guide” to point then to the tools that actually can encrypt the subject? wouldn’t that be more helpful for privacy?
I totally agree, and it is good to inform people about the problems with the classic usage of email, but the guide could point out that there are safer ways to use email
yes, and also because the “no no, email can’t be secure” folks that pop up everywhere and point to articles as the mentioned guide
We have a fairly specific use-case in mind for our email recommendations:
email is best used for receiving transactional emails (like notifications, verification emails, password resets, etc.) from the services you sign up for online
Tools that go beyond typical email security also tend to hamper this use-case. I frankly really wouldn’t want to use Delta/Arcane Chat to sign up for a newsletter or a Netflix account or whatever. They just aren’t built for that.
Thus wouldn’t compare them to Thunderbird, we’d compare them to IM clients like SimpleX, and here Delta Chat unfortunately falls short when it comes to Forward Secrecy which we consider to be fairly important.
Basically, I don’t think Delta/Arcane Chat should get a special status on our website because they’re based on email, I think it is more accurate to compare them to instant messengers despite them being based on email, and write our guides accordingly.
I run my own mail server and have for a couple of decades now. I have lived through the transition to TLS between clients and servers, the beginnings of SPF and DKIM. The addition of DMAC, etc. In addition, I have GPG Tools installed on my laptop client as well as a PGP capable client on my phone. So I am pretty sure I know how email works.
PGP does not encrypt the subject. Period. That is what is in the documentation and that is what I see when I examine the email. Fundamentally it comes down to this: The subject line is in the headers while PGP only encrypts the body.
The sending client has very little control over what headers start out on an email and none on the others that it accumulates on its journey so there is not much that can be done by the client to encrypt them.
For what it’s worth, I strongly recommend that people don’t run their own mail server. If it were not a legacy thing with me and some tight integration custom integration with some other things, I’d quickly move to having someone else manage my email for me.
but to be honest, I am also not happy with the “everything have to be PFS” mentality a lot of people have without really thinking too much on the matter, in theory, yes, it is nice but in practice this is rarely useful, for example, for PFS to be useful the user needs to use disappearing messages, otherwise if the attacker gets access to the phone, ex. Signal, rather than extracting the private key from the app they can just directly read all the unencrypted messages in the device itself. If you are going to depend in some ephemeral communication, one can as well just easily create a new profile in apps like Delta Chat, use it for some “operation” or protest and delete the profile afterwards, this is more reasonable than assuming a person at risk will use the same profile for family and activism, and for family chats people often don’t want to lose the family messages and pictures so they will not use disappearing messages
You cannot make a secure system on an insecure base, let us not spread misinformation. The criticisms you highlighted are privacy not security concerns anyway, I think you are confused. I can understand batting for your product, but encrypted email is the biggest snake oil sold ever.
Encrypted subject lines are not part of the specification, so they are not encrypted when someone implements the standard. Creating your own hacky implementation does not make it a PGP implementation, it just makes your implementation a PGP compatible custom implementation.
Ah, so this is a marketing issue. You can’t market your insecure solution since PG has a warning against using an insecure solution?
All insecure, except Whatsapp, which has privacy issues.
Write a PoC then ig? Or maybe you are talking about the privacy aspect of it where if someone controls the entire network they can correlate? Isn’t this possible everywhere. In fact, in email, if I pwn your service, I can do a lot more worse than just correlation.
Ah, now it all makes sense. The “decentralized is secure” or the “decentralized is private” delusion crowd. Central servers means nothing, same as decentralized means nothing except what is on the label. It does not automatically make something secure or insecure.
No it is exactly right. You are Tutamail category: Custom protocol, not PGP.
Lol, nice security posture from a “secure” messenger.
I just signed up to point out this seems to be incorrect once a specific extension reaches larger adoption. Thunderbird does it by default, arguably the biggest open-source client. At this point if your e-mail client doesn’t do it, you should switch clients rather than blame it on PGP.
This seems somewhat incorrect as well when talking about metadata security.
Lol, specifications are as the name says, specific. Adoption does not matter, reach does not matter, no providers using it also does not matter. The specification is exactly what the RFC says, everything else is implementation which may be standard or custom with support for standard. You seem to be confused between what these words with heavy technical meanings actually mean, and what a layman thinks they should mean.
No it is exactly correct. For far too long have people made certain terms proxies for their trust. Open source means source is open, centralized means there is a single provider, decentralized means there are multiple providers, etc. Nothing else. There is no other guarantee inherent in the definition itself. It literally does not mean anything else except what it says on the label, irrespective of how hard marketing pushes it.
You did not correctly interpret what I am saying. To give a muddy example, if I define 1=1 and someone comes in says (1+2)/3 = 1 , then this is a difference in implementation. The definition of 1 itself is the specification. If the specification has defined getting 1 through 1=1 is the standard, then (1+2)/3 = 1 is compatible with the specification, but is NOT the standard. It is a custom implementation that maintains compatibility. Tutamail breaks compatibility, idk if arcane chat maintains or does not maintain. But by implementing subject line encryption, they are creating a custom implementation, and hence they are not PGP.
Central server does not matter for metadata collection, because a service being central is not related to its metadata handling at all. You are again confused by what you think centralized means, when it does not mean anything except there is a single provider. I won’t be able to clarify more, I would recommend learning about why terms need to be specific and exact instead of hand waved notions and vague ideas. I am saying “Elephant is a mammal within the animal kingdom classification”, while you keep repeating “Elephant is a herbivore”, which is unrelated to anything the original claim is.
I have not answered your centralized question because it is off topic here. Demand your clarifications in a separate thread. The other part is it is not theoretical, it is how standards are set. Feel free to read the RFC.
