If two people e-mail, and one uses Deltachat and one uses another mail client, the subject could be visible and useful.
In particular for chatmail this is completely unnecessary and only creates a privacy concern which is why I suggest to change it. It seems only to be there for legacy reasons which don’t make sense any more.
There are another mail clients which understand PGP encryption in general, but can’t understand encrypted topic?
So, can I vote 
(in classic Roman meaning)? 
Yes. Or, at least, they do not store the mail subjects so that the user can index the mails by topic. Claws, for instance.
Now that I have figured out that I can add a subject to an encrypted message by beginning my message with a manual subject, thus:
Subject: [subject I want]
[newline]
[body text I want]
…I agree more strongly with Adbenitez that configurable encrypted subject lines are low-priority. I would be happy to omit the automatically-added encrypted subject lines on manual messages (or have a setting to omit or set them).
I would prefer to keep the encrypted subject lines in automatic interclient messages, because a subject saying “Multiple Device Synchronization” tells me (and my filters) that I can ignore the message.
subjects are completely forbidden in chatmail, and delta chat never leaks data in subject in messages, this topic is about sending UNENCRYPTED CLASSIC EMAIL, using an existing classic email account, in this case everything is unencrypted and setting a subject wanted
Yes, for unencrypted mail, simple user-set unencrypted subjects have no additional privacy risk and are very convenient.
I think Peppa is worried about someone (who has changed their profile name) unexpectedly having their original profile name revealed, to their chat partners, in the encrypted subject of an encrypted chat.
the profile name is always shared in every message, independently of being part of the subject or not, so that is not a valid concern
Yes, but it is a bit unexpected that a profile name you changed a year before adding a contact would be shared with that contact.
Most profile names are pretty bland, but humans do use nyms that reveal sensitive personal information sometimes.
old profile names are not shared in the subject on new emails, the subject is generated with your current profile name and the user doesn’t receive anything they haven’t received already in any case
Hmm, this is DeltaTouch, but I tested, changing the profile names on both ends (to different things). In a 2-person chat, the encrypted subject subsequently remained “Re: Message from [original profile name]”. I guess because all the messages are replies?
1 Like
I think it should be something like “Conversation with XXXXXX@domain.tld, YYYYY@domain.tld, ZZZZZZ@domain.tld”
The advantages are:
- Each conversation thread/chat has a different subject which can be sorted by other SMTP clients. Many programs use the subject line for conversation grouping so everyone will be able to easily group conversation threads regardless of client app preference. Currently, the “…” subject does not differentiate between conversations.
- Recipient addresses are already going to be visible by recipients and servers and other SMTP clients so there is no additional private information being revealed.
Is it about encrypted or cleartext subject?
Both, for added confusion! 
Half this thread has been sorting out the confusion caused by trying to discuss both, in parallel. But they are related.
Status quo: Subjects of both unencrypted and encrypted mail are added automatically by the client (the encrypted mails technically have both encrypted subjects and unencrypted subject headers, but the unencrupted subject headers are, by internet-wide RFC standard, set to “…”, so they are not up for debate). The user cannot choose what the autosubjects say. There has been an enormous long debate on the forum about what the autosubject should say. It was settled by a poll (sorry, @adamzea).
Now, @adbenitez intends to add user-configurable unencrypted subjects, for unencrypted mail only. 
User-configurable encrypted subjects for encrypted mail may come later (a switch to turn off autosubjects for encrypted mail would make the subjects configurable).
@peppa is worried that the autosubjects (for both erncrypted and unencrypted mails) don’t change when you change your profile name.
I suggest moving Peppa’s concern to a new narrower topic, and postponing the rest of this topic.
3 Likes
the subject is only set in the first message, then afterwards you just reply, but that is what I meant, you already sent an email to that person when you had another name set, it doesn’t matter now that you change your name and you are not leaking anything by not changing the subject, all emails are in the person’s inbox and they can clearly see the display name (NAME <email@example>) nicely displayed in the sender column of their email client
why would you need to see this on an encrypted thread anyways? also we are moving away from leaking metadata, in the future it might become harder for the server to even know that an email correspond to a group, they will look the same as encrypted private messages, so putting the group memberlist unencrypted in the subject for some weird niche use case is unlikely to happen
and for unencrypted groups the subject is the group name so the thread will be nice then and make sense, but for encrypted groups I don’t see the need for this (nor when the disadvantages are much bigger)
@Peppa, I have tested some more, and @adbenitez is right. The autogenerated subjects of groups contain groupnames, and don’t contain profile names. Only the autogenerated subjects of two-person chats contain the profile name.
Two-person chats contain the profile name used by the person who sends the first message to the chat at the time when they send it. If someone changes their profile name and then starts a new two-person chat, the new chat uses the new profile name, but old chats still use the old name.
So the only person who will see your original profile name in an encrypted subject is the one other person you have in that chat. And they see the profile name you were using when you started that chat.
In unencrypted two-person chats, eavesdroppers might also see your old name. But Adbenitez is fixing that by making subjects configurable in unencrypted chats.
So I don’t think there is a privacy concern.
Especially if some of the participants are using classic clients, it would be nice to have subjects follow the old mail conventions:
- for two-person chats, user-configurable subjects
- for groups, the name of the mailinglist/group, inside square brackets, followed by the user-configurable subject
I imagine this would be particularly useful for broadcast groups.
I tried to make it a narrow topic to start but there got tangential discussions started and added confusion 
My concern is not about revealing your old profile name to the other person in the chat but about unwittingly revealing your identity to hostile authorities in case of device seizure or device search. I think my original post makes this clear but its worth repeating because maybe the logic got lost somewhere in this thread:
Threat models don’t always remain static and unchanging, and its good to acknowledge and accommodate this. For example two persons might start with casual chatting then move to talking more overtly about political topics after some time, then realize it is not so wise to have their real identity linked to the chat. Or one person might decide to attend a protest, or travel into an oppressive country known for device searches at the border. Or a regime change and new laws can make a topic which was previously safe to discuss in a chat as something legal, such as birth control, suddenly illegal. And many more examples.
DC already lets you change your profile name, which is good, but the subject lines present a hidden danger that most users will not even be aware of. So unfortunately the current design invites bad opsec by letting users think they protected their identity when they change their profile name and think they can have mitigated the risk of hostile authorities searching the other person’s device while in fact still letting these hostile authorities see their identity anyway. I think this is a valid concern, and since subject lines don’t serve any purpose for chatmail users as they are hidden in DC anyway, and since the current behavior defies user expectations (the idea that your old profile name is forever being sent invisibly to the chat with every message is very strange), I don’t see any reason not to fix this.
If a device is seized from a person, they are likely to be identified by their wallet or passport or appearance or who turns up to bail them or banking app or just tracking of the phone’s past locations. So I think you are talking about the risk of seizure of a contact’s device. Investigators might find the old profile name of a contact that the seized device was talking to. They might also find deleted contacts, which can persist in the database.
I agree that indefinite subject persistence is counterintuitive, and I think configurable subjects are the only thing likely to resolve the debates on subjects, since people have incompatible wants.
I think the expectation that profiles are containerized, and do not retain any information removed from the interface, is a natural one. It seems the UI acknowledges this, as a design ideal (for instance, there are settings that exist to do containerization, like per-profile proxies, and explicit warnings about information being retained after deletion). The software is obviously not perfect yet 
, but it seems to be heading in the direction you want.
1 Like
Yes exactly this.
For classic email configurable subjects makes sense. For chatmail the subjects are hidden anyway and don’t have any purpose, so it would be better to set it to something like “(no subject)” then "Re: Message from [original profile name]”!
I agree!
Yes and I would like to nudge it a bit further in that direction by removing profile names in the subject line at least for chatmail! This is an overlooked privacy/opsec risk and the risk is not obvious at all to the user. I understand why the current subject line happened but it doesn’t make sense to keep it like that.