Hide group emails from data mining

Feature Proposal
1

Right now Delta chat sending messages using field To: that disclose all groups emails and allows to track relations between emails.

In case of communication with correspondents who using “free” email account from providers such as google, yahoo, etc, email provider can build connection graph between people who using delta.chat. Using Bcc: field will eliminate such disclosure.

Expected behavior

Since the whole purpose of Delta chat is to make communication as private as possible, I suggesting to use
Bcc: field on sending instead of To: and relations between correspondents, - keep inside of encrypted message as technical field.

2 Likes
2

Doesn’t deltachat implement the memoryhole standard?

iirc moving To: headers to the encrypted part is not part of the memoryhole standard, but the memoryhole spec could be adjusted I guess.

3

As far as I can see on the server, field To: isn’t hided and all group’s emails visible in plain text including “Display name”.

I think that memoryhole on its own wouldn’t help to resolve disclosure issue, but will help to keep track of group members on receiving side, that’s what I mentioned as technical encrypted field.

Originator’s MTA should know where to send group emails and have no clue about autocrypt. That’s what Bcc: field is for. Originator’s MTA knowing all emails it need to send, but receiving MTA will not, it will see only originator during handshake in ENVELOPE FROM stanza.
Receiving MTA will fill empty field To: in such case with text “undisclosed recipients;” or leave it simply empty.

4

puh, if you have people in the group who use MUAs which do not implement this and can not parse the recipients from the body, and therefore can not reply to everyone, this is a usability mess. I agree that it is a good way to make tracking even harder, but it needs careful standardization and implementation. I also think it should be opt-in in the beginning (for a group, not for a user). It could work quite well with delta-chat only verified groups though.

1 Like
5

I see what you mean…
But as far as I found, in reality DC making a standard as email messenger and while it still Beta, I think other MUA who willing to implement encrypted communication using DC protocol would benefit using Bcc: and parse encrypted mail headers either as part of memoryhole or my preference would be: “Wrap the whole message as an message/rfc822 sub-part” and “Only use embedded text/rfc822-headers parts”.

I think if mutual p2p encryption have been established then subsequent communication should use encrypted email header only regardless if it is a group or p2p. I think also that it isn’t a good idea to combine in group members, who aren’t established encrypted channels otherwise it would be a mess for sure regardless of my proposal.

6

Yes, it would make sense to me to move to BCC addressing then.
But the support for regular unencrypted messaging (backwards compatibility for contacting not-yet-deltachat-using email users (opportunistic autocrypt) is also an awesome feature. => Both ideas make a good combination!

7

I think also that it isn’t a good idea to combine in group members, who aren’t established encrypted channels otherwise it would be a mess for sure regardless of my proposal.

“Secure groups” are part of the qr scanning lab testing feature, they don’t allow unencrypted communication. (Leaving aside the discussion whether it is legit to promote “trusting any scanned QR contact to introduce and change other’ keys” to be in any way associated with “secure”.)

There are also some other cases in which one might want some more control over the encryption: