Alan
My feedback
9 results found
-
615 votesAlan
supported this idea
·
-
2,072 votes
We have given this quite a bit of thought, but at the present moment, it is not clear the advantages would outweigh the disadvantages.
The biggest problem is search. Encrypting all metadata would break metadata search entirely on the web client as there is still no efficient way to handle search of encrypted data within a browser.
Secondly, metadata encryption’s value from a privacy standpoint is also somewhat dubious. Because we ultimately must deliver the message to the recipient, we must know who the recipient is. At the current time, there still isn’t any proven and viable way to work around this.
Metadata encryption is an area of continued research for us, and when the opportunity arises and the technology for doing this matures, we will definitely implement it in ProtonMail.
Alan
supported this idea
·
An error occurred while saving the comment -
23 votesAlan
shared this idea
·
-
480 votesAlan
supported this idea
·
An error occurred while saving the comment Alan
commented
I am not sure if everyone is talking about the same feature.
If I reply an email to one of those "extra alias" managed under "Identity and addresses" section of Proton Mail Settings, the composer defaults to replying from that address. We can generate up to 10 / 15 / 30 of these aliases.
But this does not work with "hide-my-email" @passinbox.com aliases generated from Proton Pass. We can generate an unlimited number of these aliases.
-
58 votesAlan
supported this idea
·
-
292 votesAlan
supported this idea
·
-
388 votes
An error occurred while saving the comment Alan
commented
Answering a question below for why I did not vote on this feature – I can create an alias and setup forwarding for everything arriving at that alias to my partner's account. It doesn't work like a shared folder, e.g. where an email I delete happens to both accounts, but it does allow mails arriving on that alias to be sent to both accounts. This is good enough for my scenarios already.
-
1,691 votesAlan
supported this idea
·
-
23 votesAlan
supported this idea
·
Note that almost all ideas from the response from 8 years ago are either debunked or no longer true.
0. The metadata you need to deliver the message is different from the metadata you need to serve the message after it is delivered. Once delivered, all you need is a UUID to identify it, and the entire RFC2822 contents can happily live in an encrypted blob. The difference is whether an adversary sees plaintext headers while the message is in transit, versus plaintext headers for all your historical messages.
1. Subjects are not part of the envelope. Even if it is not a published standard, There are widely-adopted protocols to encrypt subjects. You can encrypt the subject of all outgoing messages, and encrypt the subject of an unencrypted incoming message while still being compatible to most of the world.
2. RFC8551 is already a "proposed standard". You cannot just say the technology to encrypt all headers does not exist. You can encrypt the entire message once it has been delivered to your mailbox, while still being compatible to a proposed standard.
3. One should face the consequence if they opt in to encrypting (just the subject or) all metadata. Yes, it means web-based search becomes useless if headers like "From", "To" and "Subject" are all inaccessible, but you should give us this option if this is a genuine demand from us. There are still legitimate uses of ProtonMail, e.g. a unsearchable web + a local IMAP mirror, in the encrypt-everything configuration. Or you can support limited searching of locally cached messages like what Tuta does.
4. The threat from metadata exposure is real. Subjects of all emails you ever sent & received can reveal a lot about you, even before the age of AI. Even the organizations and people you associate with allows a non-trivial profile of you being built.
5. Homomorphic encryption is indeed "an area of continued research" but please do not allow that distract us from what we can already achieve today.