BTW, email is a big privacy issue in general. It's too expensive (mainly time-wise) to create new email addresses, but if you use the same one, it creates tons of links. Ideally, you should use one email per service. I've had two ideas in this area:
First, you could create a simple email forwarding service like this:
- Without registration (but maybe with a tiny fee via eg. Lightning), take a user's email address, generate a random key, and use the random key to encrypt the email address.
- Also encrypt the email address with a server secret.
- Give the user an email address of the form
ENCRYPTED_EMAIL.DECRYPTION_KEY@asdf.com - When the service receives email at a forwarding address, it decrypts the email first using its server secret, and then using the provided decryption key. Then it forwards the email to the email address
- To destroy forwarding addresses, users could provide the service with both their forwarding address and target address, and the service could then send a confirmation email.
This would be convenient, and it'd fix the problem of services being able to connect users across multiple sites through email-address reuse. But it trusts the forwarder not to log the per-email decryption keys or give up the server secret key. Though if multiple services like this existed, you could chain emails through them to increase security.
My second idea is:
- The user would be using his own software (like eg. Thunderbird or perhaps prontonmail). From this software, the user could instantly create low-capacity throwaway accounts on the server. Each throwaway account could be (or behave similar to) a POP3 account with low capacity (eg. 50MB) and quick message expiration (eg. 60 days).
- The client software would use Tor and careful polling to download all of the messages on its throwaway accounts without leaking to the server info about which accounts are connected. To improve anonymity and efficiency, you could perhaps use
PIR, or the server could publish hourly/daily bloom filters meant to match email addresses which received mail in the time period. The client software would collect all of the messages into a single inbox for the end-user. Since it polls frequently, the client wouldn't have to worry about the low limits on the individual throwaways.
- The server could anonymously require a small one-time for each throwaway account by using blinded bearer certificates.
With this, the server shouldn't ever be able to connect any of the accounts together. You could also send mail from the throwaways.
The main thing necessary for this second idea is a really smart email client meant to juggle many throwaways. You also need a cooperative server allowing quick account creation (like cock.li), ideally via an API.
