New email section

[dngray]

https://deploy-preview-1672--privacytools-io.netlify.com/providers/email/

Note still a work in progress, and is subject to change. Not merging before March 2020

---

Closes: #144
Closes: #603
Closes: #733
Closes: #1038
Closes: #1345
Closes: #1626
Closes: #1652
Closes: #1671
Closes: #1670 (Superseeding it)
Closes: #1673

[netlify]

Deploy preview for privacytools-io ready!

Built with commit b8781e4

https://deploy-preview-1672--privacytools-io.netlify.com

[dngray]

We could also expand on data sovereignty, although this is really something I want to address in https://github.com/privacytoolsIO/privacytools.io/issues/1437

[nitrohorse]

Some small nit-picky suggestions (haven't reviewed all of it but this is so far).

[Zcr34]

Looks good, but do not understand why Mailbox.org is above Posteo or Protonmail?

---

Edit:

Just on a basic look through of ThatOnePrivacySite:

EMAIL SERVICE	JURISDICTION Based In (Country)	JURISDICTION Fourteen Eyes?	JURISDICTION Enemy of the Internet	LOGGING Logs Payment Info	LOGGING Logs IP Address	ACTIVISM Anonymous Payment Method	ACTIVISM Accepts Cash	ACTIVISM Accepts Gift Cards	ACTIVISM Accepts Crypto Currency	ACTIVISM Open Source Platform	ACTIVISM PGP Key Available	ACTIVISM Gives back to Privacy Causes	ACTIVISM Meets PrivacyTools IO Criteria	WEBMAIL Webmail Access	WEBMAIL Header Info Stripped	PROTOCOLS POP3	PROTOCOLS IMAP	PROTOCOLS SMTP	SECURITY User can Control Private Key	SECURITY Encryption (In Transit)	SECURITY Encryption (At Rest)	2FA 2FA Option	AVAILABILITY # of Addresses	AVAILABILITY Custom Domain	FEATURES Supports CalDAV	FEATURES Supports WebDAV	FEATURES Supports CardDAV	FEATURES Supports ActiveSync	STORAGE Email Storage (in GB)	STORAGE Document Storage (in GB)	WEBSITE # of Persistent Cookies	WEBSITE # of External Trackers	WEBSITE Server SSL Rating	WEBSITE SSL Cert issued to	PRICING $ / Month (Annual Pricing)	PRICING $ / Connection / Month	PRICING Free Trial	PRICING Refund Period (Days)	ETHICS Falsely Claims 100% Effective	ETHICS Incentivizes Social Media Spam	POLICIES Forbids Spam	POLICIES Requires Ethical Copy	POLICIES Requires Full Disclosure	AFFILIATES Practice Ethical Copy	AFFILIATES Give Full Disclosure
KolabNow	Switzerland	Cooperative	No			No	No	No	Yes	Yes	No	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes	SSL/TLS	None	No	1	Yes	Yes	Yes	Yes	No	2.00	2.00	1	1	A+	Self	8.85	8.85	Yes	0
Mailbox.org	Germany	Fourteen	No			No	No	No	Yes	No	Yes	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes	SSL/TLS	PGP	Yes	3	Yes	Yes	Yes	Yes	Yes	2.00	0.10	0	1	A+	Self	1.07	0.36	Yes	14
Posteo	Germany	Fourteen	No	No	No	Yes	Yes	No	No	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	SSL/TLS	OpenPGP	Yes	2	No	Yes	No	Yes	No	2.00	0.00	0	1	A+	Self	1.25	0.63	Yes	14
ProtonMail	Switzerland	Cooperative	No		No	Yes	Yes	No	Yes	Some	Yes	Yes	Yes	Yes		No	Yes	Yes	Yes	SSL/TLS	OpenPGP	Yes	5	Yes	No	No	No	No	5.00	0.00	1	1	A+	Self	4.00	0.80	Yes	0
Soverin	Netherlands	Nine	No	No		No	No	No	No	No	Yes	No	Yes	Yes	No	No	Yes	Yes	Yes	SSL/TLS		No	1	Yes	Yes	No	Yes	No	25.00	0.00	0	0	A+	Self	3.84	3.84	No	0
Tutanota	Germany	Fourteen	No		No	No	No	No	No	Yes	No	Yes	Yes	Yes	Yes	No	No	No	No	SSL/TLS	AES	Yes	5	Yes	Yes	No	Yes	No	1.00	0.00	1	0	A+	Self	1.25	0.25	Yes	14

I do not understand how this rating list can be justified.

[dngray]

They are in no particular order. The order is the first to be compliant with the criteria, though that being said Soverin should be moved down, as they are less compliant. Disroot will most likely be removed unless they have encryption at rest and 2FA.

[Zcr34]

They are in no particular order. The order is the first to be compliant with the criteria, though that being said Soverin should be moved down, as they are less compliant. Disroot will most likely be removed unless they have encryption at rest and 2FA.

Perhaps I am wrong, but I also don't understand why Mailbox.org is being listed.
If you are looking for custom domain then Tutanota, Kolab Now, or even Soverin seem to be better with a more open-source backing or privacy-oriented jurisdiction.

Otherwise Posteo has been my go to, in part because of their transparency report.

---

Also, I do think that "first provider to meet requirements" might be a bad idea.

The original VPN section was set up as "Recommended" and "Worth Mentioning".
I am afraid that some of the stigma may still be there making users not fully do their research. [1]

[dngray]

Perhaps I am wrong, but I also don't understand why Mailbox.org is being listed.
If you are looking for custom domain then Tutanota, Kolab Now, or even Soverin seem to be better with a more open-source backing or privacy-oriented jurisdiction.

It's based on the criteria. Mailbox meets that criteria so I don't see why it wouldn't be listed.

Currently a this time of writing Tutanota and Kolab Now do not. Soverin does, but they do lack zero knowledge encryption, something that we rate pretty highly.

Posteo might get a higher position than Soverin because it was first to meet our requirements. Additionally it does support encryption of contacts/calendars. It is also worth noting though posteo.de does not allow users to have their own domain. This binds user's identity exclusively to that particular provider.

Everyone has differing opinions on this issue hence the criteria.

The original VPN section was set up as "Recommended" and "Worth Mentioning".

We've moved away from that. What we're doing now is having a baseline of requirements then annually tightening them as more providers meet those 'best case' requirements. We do not see the point in mentioning anything less than the best.

Note that 2FA is a base requirement, an email account is the gateway a user has to any other account and thus we see it as a necessary feature.

[dngray]

I am thinking it might be a good idea to have a bit of a subsection for webmail vs standard protocols (IMAP, JMAP, POP3, SMTP etc). This is a contentious point where many say we should either make one or the other a base requirement.

There are pros and cons for each depending on one's threat model however, which is why I am reluctant to make it a base requirement.

Webmail:

Pros:

• Stronger authentication, 2FA etc. This grants a user higher security if they are logging in to many un-trusted devices.
• Ease of use (zero configuration etc)

Cons:

• Larger surface area to steal private keys
• Unless using something like Mailvelope the provider has a copy of your private keys

IMAP/POP/SMTP/JMAP/:

Pros:

• Private keys are always local to the device
• Reduced surface are when compared to a web browser

Cons:

• Password authentication only. (Gmail gets around this by using XOAuth2).

Custom client (eg Tutanota):

Pros:

• Forces client side encryption of cache files, only to be decrypted when loaded into memory. Ideally users would have full disk encryption on all their devices anyway.

Cons:

• Specific to provider, not a universal standard, encourages custom encryption incompatible with the rest of the industry, thus centralizing email to that service

[fm]

Thought I'd leave some suggestions and corrections.

[jonaharagon]

grammar 'n stuff

[ghost]

Hi, @blacklight447-ptio asked for our feedback on the new e-mail page. These are our suggestions:

General

• Change PGP to OpenPGP as OpenPGP is the name of the actual standard.
• Change SSL to TLS as SSL is outdated for a long time and really a legacy term.
• Several times, encryption of data at rest is mentioned as a feature. You also included encryption of data in transit by discussing the use of TLS and E2EE. However, what about encryption of data in use? Are there some e-mail providers that could read your data in their server's memory when accessed by the user?

mailbox.org

• U2F support: As far as we know, mailbox.org does not support U2F at the moment.
• Encryption of incoming e-mail: There should be some information that the e-mail is in cleartext until it reaches your mailbox where it is encrypted. So this feature only protects your e-mails if somebody accesses your mailbox. There is no protection against a MitM or any protection of data in transit before the e-mail reaches your mailbox.

Technology

Security is improved greatly when used with E2EE such as PGP. This is because the attack surface is greatly reduced when compared to in-browser cryptography.

Mailvelope is a web browser addon that offers OpenPGP in the web browser. So a Mailvelope user may be confused when reading "Use OpenPGP instead of in-browser crypto" while using OpenPGP in the web browser.

Furthermore, you oftentimes mention "zero-access encryption". This sounds like marketing lingo, likely introduced by ProtonMail. Maybe, you should use a more general term.

Privacy

You should add the following minimum requirements:

• Can be used without providing much personal data (or PII).
• Has an concise privacy policy that meets certain requirements (e.g., as defined by the European GDPR).

Security

Support for hardware authentication smartcards like the YubiKey or Nitrokey, we believe this to be more secure than TOTP.

Please mention the standards U2F and WebAuthn here, because both YK and NK support TOTP so a user might not understand the difference. Since there are some people that don't understand the difference between TOTP and U2F/WebAuthn, and/or are convinced that U2F/WebAuthn is actually less secure than TOTP, there should be a small note about the benefits of U2F/WebAuthn (e.g., more convinient to use, uses a private key on the user's device instead of relying on a shared secret, more phishing resistant).

Finally, we think that a strict Content Security Policy should be a minimum requirement for the web interface. Strict CSPs block most current client-side web browser attacks (like XSS or Clickjacking) and blocking these attacks makes perfect sense when using a web client to access your e-mails.

[dngray]

Thanks for your reply @infosec-handbook there are some very good suggestions there. I think some of the most obvious ones might have slipped in from changes I accepted. (re SSL and TLS point).

I'll get to work updating this.

[dngray]

General

However, what about encryption of data in use? Are there some e-mail providers that could read your data in their server's memory when accessed by the user?

Unless all data is decrypted on the client there will always be some data accessible to the provider. Even providers which aim to do this, ie ProtonMail, Tutanota etc will have some data that is not encrypted ie incoming unencrypted emails, metadata etc. The technology isn't there to make any kind of requirement on this, especially for smaller providers not developing their own proprietary solutions.

mailbox.org

• U2F support: As far as we know, mailbox.org does not support U2F at the moment.

They do for webmail, customers can even choose to buy a Yubikey direct from Mailbox pre-enrolled:

You can then set the security level:

And method:

Or you can enroll a key that you purchased elsewhere:

I think it might only support the Yubikey though.

• Encryption of incoming e-mail: There should be some information that the e-mail is in cleartext until it reaches your mailbox where it is encrypted. So this feature only protects your e-mails if somebody accesses your mailbox. There is no protection against a MitM or any protection of data in transit before the e-mail reaches your mailbox.

I have made a note of that privacytoolsIO/privacy-tools@00d0021 . There is some degree of trust placed in the provider.

Technology

Security is improved greatly when used with E2EE such as PGP. This is because the attack surface is greatly reduced when compared to in-browser cryptography.

• Mailvelope is a web browser addon that offers OpenPGP in the web browser. So a Mailvelope user may be confused when reading "Use OpenPGP instead of in-browser crypto" while using OpenPGP in the web browser.

I think I have clarified that with privacytoolsIO/privacy-tools@c122bcb

Furthermore, you oftentimes mention "zero-access encryption". This sounds like marketing lingo, likely introduced by ProtonMail. Maybe, you should use a more general term.

The industry term tends to be "zero knowledge cryptography", however "access" I think is more precise. Knowledge might infer they don't know you've used cryptography? I can see why ProtonMail and others have started referring to it as "zero access". It's not a trademarked term, so I don't see any issues in using that term.

Privacy

You should add the following minimum requirements:

• Can be used without providing much personal data (or PII).

Done: privacytoolsIO/privacy-tools@2ebb28c

• Has an concise privacy policy that meets certain requirements (e.g., as defined by the European GDPR).

I'd say all our providers meet this:

• ProtonMail - GDPR
• Mailbox - Data Protection Policy in accordance with EU General Data Protection Regulation (GDPR)
• Posteo - Privacy policy
• Soverin
• Disroot - Privacy Policy

Added this requirement privacytoolsIO/privacy-tools@27e0bf3

Security

Support for hardware authentication smartcards like the YubiKey or Nitrokey, we believe this to be more secure than TOTP.

• Please mention the standards U2F and WebAuthn here, because both YK and NK support TOTP so a user might not understand the difference. Since there are some people that don't understand the difference between TOTP and U2F/WebAuthn, and/or are convinced that U2F/WebAuthn is actually less secure than TOTP, there should be a small note about the benefits of U2F/WebAuthn (e.g., more convinient to use, uses a private key on the user's device instead of relying on a shared secret, more phishing resistant).

Yes, this is an error, we're not specifying specific hardware products, as that will be out of scope and in scope of the hardware section being worked on by others. Fixed privacytoolsIO/privacy-tools@c95fa40

• Finally, we think that a strict Content Security Policy should be a minimum requirement for the web interface. Strict CSPs block most current client-side web browser attacks (like XSS or Clickjacking) and blocking these attacks makes perfect sense when using a web client to access your e-mails.

At the moment the only provider which we have that meets that is Posteo and Mailbox.org. We might approach providers and ask them to do this for a later tightening of the requirements.

[dngray]

I've also decided to remove the base requirement on standard access protocols added in privacytoolsIO/privacy-tools@3046548#diff-8cc7b2b0d78dd2501610391c086a8516R41 and privacytoolsIO/privacy-tools@b52f6b7#diff-5e5aab7d4c183162a48e6efc2270b5a8R45.

The reason we believe something like this should exist is for data liberty purposes. Users should have the freedom to move from one provider to another without the possibility of having their data difficult to obtain, import or export.

The argument about "in browser cryptography" for E2EE is actually more complicated than it would seem at a glance.

One side of the argument says that using email clients like Thunderbird for example is "more secure" than using cryptography served to you in your browser because of reduced "surface area". While concerns about XSS style attacks and crap implementations are valid, there are things that mitigate this, eg. strict CSPs, well designed and reviewed code etc.

The argument also doesn't consider browser plugins like Mailvelope. These plugins have been audited, are not served by the provider, but are technically "in browser".

The side that argues for mail clients also argues that email providers should not produce cryptography, because they have knowledge of their own systems, and if they have knowledge of the actual code doing the cryptography, they could compromise it to not work, send plaintext copy etc. This would certainly be a concern for any company operating in Australia eg with the Assistance and Access Bill, or this less dense summary.

Therefore we would not be recommending any provider which did not have an open source client, or seemed apprehensive about alternate distribution channels like F-Droid, Linux repos etc where there are reproducible builds exist. We do believe third party verification is paramount to putting a stop to government mandated backdoors.

The argument also assumes that users are the ones which are faultless and that it will be the provider which in fact suffers the breach. In reality we know this is often not the case.
It's far more likely users will be targeted through spear phishing campaigns that aim to steal their private keys. It's also far more likely that providers will have the resources to employ staff to secure their systems.

Standard access protocols often mean that exotic multi factor authentication systems need by-passes, such as application specific passwords etc in order to keep access open for legacy email clients.

Unfortunately the approach that Google uses ie. as an OAuth provider doesn't seem that common. It is in fact actually possible to login using a Google account, and access IMAP, with 2FA.

Typically on Thunderbird, when someone puts in their email address @gmail.com the gmail.com autoconfig is hit which mandates the login mechanism.

It would be nice to see the Autoconfiguration mechanism more popular, one doesn't even need to store it in Mozilla's ISPDB, they can put it in example.com/.well-known/autoconfig/mail/config-v1.1.xml directory.

[ghost]

Thanks for your changes, @dngray.

mailbox.org

U2F support: As far as we know, mailbox.org does not support U2F at the moment.

They do for webmail, customers can even choose to buy a Yubikey direct from Mailbox pre-enrolled:

mailbox.org seems to use Yubico OTP via Yubico Cloud. It makes sense that they can preconfigure a YubiKey when purchased on their website in this case. All other references are always "OTP", not "U2F". Furthermore, they support OATH-TOTP and OATH-HOTP according to the screenshots.

There are actually open requests for U2F and WebAuthn support. Both requests are still open. So it seems that there is no support for U2F.

---

It is more resistant to phishing based attacks, as opposed to a shared secret used with TOTP.

(You changed this line today.) U2F/WebAuthn are considered more phishing resistant because during authentication, the tokens calculate an authentication response based on the current domain name in the web browser. For instance, if you are on paypal.com and use U2F, the token gets a challenge from the web browser and sends back its correct response. However, if you are on paypa1.com, the token calculates its response using paypa1.com as the domain. This results in a wrong response that is still sent to the server. An attacker can't use this wrong response for authentication. This mechanism assumes that the web browser correctly verified the identity of the web server via an HTTPS certificate.

On the other hand, OATH-TOTP calculates its response (the 6-digit one-time password) based on the current time and a shared secret. This shared secret is generated by the web server and sent to the client during setup (e.g., using a QR code). The client-side TOTP application then stores this secret and uses it for generating OTPs in the future. This is less secure than U2F/WebAuthn since the web server not only knows the secret but it also generates it (and you don't know if this was a random value). So a server-side attacker could extract this shared secret. Contrary to this, U2F/WebAuthn tokens contain a private key that never leaves the client-side token. The web server can't store any secrets.

Regarding phishing, there is no protection when using OATH-TOTP. A fake website like paypa1.com can first ask for your username and password and then for your TOTP secret. A man-in-the-middle can directly use this for authentication (yes, in reality, the code is only valid for up to 30 seconds, but this is sufficient for automated attacks).

To cut a long story short, we suggest the following changes:

Support for hardware authentication, ie U2F and WebAuthn. U2F and WebAuthn are more secure as they use a private key stored on a client-side hardware device to authenticate users, as opposed to a shared secret that is stored on the web server and on the client side when using TOTP. Furthermore, U2F and WebAuthn are more resistant to phishing as their authentication response is based on the authenticated domain name.

(Feel free to reword this if necessary!)

[dngray]

mailbox.org seems to use Yubico OTP via Yubico Cloud. It makes sense that they can preconfigure a YubiKey when purchased on their website in this case. All other references are always "OTP", not "U2F". Furthermore, they support OATH-TOTP and OATH-HOTP according to the screenshots.

There are actually open requests for U2F and WebAuthn support. Both requests are still open. So it seems that there is no support for U2F.

Ah yes, you're right. How does privacytoolsIO/privacy-tools@7d21d54 sound.

For record purposes, I've included a screenshot of the other options:

It is more resistant to phishing based attacks, as opposed to a shared secret used with TOTP.

(You changed this line today.) U2F/WebAuthn are considered more phishing resistant because during authentication, the tokens calculate an authentication response based on the current domain name in the web browser. For instance, if you are on paypal.com and use U2F, the token gets a challenge from the web browser and sends back its correct response. However, if you are on paypa1.com, the token calculates its response using paypa1.com as the domain. This results in a wrong response that is still sent to the server. An attacker can't use this wrong response for authentication. This mechanism assumes that the web browser correctly verified the identity of the web server via an HTTPS certificate.

That was also my understanding from https://webauthn.guide hence the "scoped" part of it.

On the other hand, OATH-TOTP calculates its response (the 6-digit one-time password) based on the current time and a shared secret. This shared secret is generated by the web server and sent to the client during setup (e.g., using a QR code). The client-side TOTP application then stores this secret and uses it for generating OTPs in the future. This is less secure than U2F/WebAuthn since the web server not only knows the secret but it also generates it (and you don't know if this was a random value). So a server-side attacker could extract this shared secret. Contrary to this, U2F/WebAuthn tokens contain a private key that never leaves the client-side token. The web server can't store any secrets.

Regarding phishing, there is no protection when using OATH-TOTP. A fake website like paypa1.com can first ask for your username and password and then for your TOTP secret. A man-in-the-middle can directly use this for authentication (yes, in reality, the code is only valid for up to 30 seconds, but this is sufficient for automated attacks).

Agreed 100%. Realistically anything like that would certainly be automated. I also think that hardware keys have a much better user experience, in terms of flow:

1. "is it plugged in?" Yes?

vs

1. "Did you check the site's domain?"
2. "Did you enter the code in time?"
3. "Did you not make a mistake with the number etc?"

This is particularly for older or disabled people, who are more likely to get tricked by paypal.com vs paypaI.com. (or any other variation).

To cut a long story short, we suggest the following changes:

Support for hardware authentication, ie U2F and WebAuthn. U2F and WebAuthn are more secure as they use a private key stored on a client-side hardware device to authenticate users, as opposed to a shared secret that is stored on the web server and on the client side when using TOTP. Furthermore, U2F and WebAuthn are more resistant to phishing as their authentication response is based on the authenticated domain name.

(Feel free to reword this if necessary!)

I actually really like the way you worded that. It's very succinct and to the point, (which is the main objective), so I have left it as is. privacytoolsIO/privacy-tools@7d407e9

[dngray]

I think we may need to make corrections to the posteo description:

You can use either TOTP or U2F security key.

Looking at How can I use a YubiKey for two-factor authentication with Posteo? it says

Note: The current version of the YubiKey TOTP help program (as of 11/03/2015) does not support U2F enabled YubiKeys (i.e. YubiKey Plus, Fido U2F Security Key). Take this into account when choosing your YubiKey.

Fixed: privacytoolsIO/privacy-tools@30eaec6

[blacklight447]

Great work folks, im excited to finally launch the new page!

[Mikaela]

Reading through the preview (not code or checking that links work as Matrix gave me an impresssion of urgency) LGTM.

[dngray]

Reading through the preview (not code or checking that links work as Matrix gave me an impresssion of urgency) LGTM.

Yeah the code and links have been checked multiple times, I think by now.

[Mikaela]

I guess the svgs are still fine

[dawidpotocki]

🙃

[Kovaelin]

Is there a reason for listing Disroot, but not Rainloop?

[fm]

Rainloop is an email client, not an email provider