You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have used the search function to see if someone else has already submitted the same bug report.
I will describe the problem with as much detail as possible.
App version
6.802
Where did you get the app from?
F-Droid
Android version
LineageOS 20.1 (Android 13)
Device model
Fairphone 4
Steps to reproduce
add a account as usual
enable OpenPGP on that account by selecting a key
do not change any other settings concerning OpenPGP / Autocrypt
(esp. "Autocrypt mutual" should be disabled)
send a new (unencrypted & unsigned) mail to yourself
open the newly received mail & check the headers
Expected behavior
IMO it is reasonable to expect that this mail does not contain an AutoCrypt header with my configured OpenPGP key. I think so because K9-Mail does not declare that additional data might be shared, hence (at least in the EU regarding GDPR) it should only share data which is technically required to send that mail. As that mail is not encrypted & not signed and as mutual encryption was disabled, K9-Mail is not technically required to submit my public key.
Actual behavior
The sent mail contains an Autocrypt header containing the configured OpenPGP key.
Additional Info
Issue #4836 already reported this misbehavior, but that issue was mostly ignored and did not discuss the potential legal issue arising from that behavior. Because this report is from ca. 4 years ago, I decided to open a new issue.
I understand that it is useful to automatically attach the public key to all outgoing mails, I see following problems in the current implementations:
The current behavior is neither explained to the user nor can it be specifically disabled. And IMO there are use cases for using OpenPGP without Autocrypt.
The current behavior can result in a leak of personal data, especially in combination with the multiple identities feature. E.g. if a user does want to send a mail from an anonymous alias and its provider allows this by simply using a different FROM address, K9-Mail can leak the identity of that user. Or that users PGP key might contain additional information they do not want to share with every mail (e.g. secondary mail addresses).
IMO the current behavior is illegal under GDPR, because that behavior is non-optional, not explained to the user and not technically required for the service the users are expecting (sending an unencrypted, unsigned mail).
The text was updated successfully, but these errors were encountered:
We can add a message to the settings screen stating that enabling encryption will include the public key in all outgoing messages. Would this be clear enough?
Note: K-9 Mail implements the Autocrypt standard and includes your OpenPGP public key in all outgoing messages.
I don't think the GDPR applies here since we're not collecting any information about the user.
cketti
changed the title
auto-enabling Autocrypt with OpenPGP is violating the users privacy
Add note about OpenPGP public key being included in all outgoing messages
May 13, 2024
Checklist
App version
6.802
Where did you get the app from?
F-Droid
Android version
LineageOS 20.1 (Android 13)
Device model
Fairphone 4
Steps to reproduce
Expected behavior
IMO it is reasonable to expect that this mail does not contain an AutoCrypt header with my configured OpenPGP key. I think so because K9-Mail does not declare that additional data might be shared, hence (at least in the EU regarding GDPR) it should only share data which is technically required to send that mail. As that mail is not encrypted & not signed and as mutual encryption was disabled, K9-Mail is not technically required to submit my public key.
Actual behavior
The sent mail contains an
Autocrypt
header containing the configured OpenPGP key.Additional Info
Issue #4836 already reported this misbehavior, but that issue was mostly ignored and did not discuss the potential legal issue arising from that behavior. Because this report is from ca. 4 years ago, I decided to open a new issue.
I understand that it is useful to automatically attach the public key to all outgoing mails, I see following problems in the current implementations:
The text was updated successfully, but these errors were encountered: