New email section #1672

Merged
dngray merged 1 commits from pr-new_email_section into master 2020-03-01 12:06:07 +00:00
dngray commented 2020-01-30 09:46:02 +00:00 (Migrated from github.com)

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

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[bot] commented 2020-01-30 09:46:57 +00:00 (Migrated from github.com)

Deploy preview for privacytools-io ready!

Built with commit b8781e4378

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

Deploy preview for *privacytools-io* ready! Built with commit b8781e4378488c1578089f8a98d53a287f78e53b https://deploy-preview-1672--privacytools-io.netlify.com
ghost commented 2020-01-30 11:28:39 +00:00 (Migrated from github.com)

Disroot supports zero access encryption. Not enabled by default, will prevent staff from having access to your email.

That manual is for their nextcloud instance & not email service.

> Disroot supports zero access encryption. Not enabled by default, will prevent staff from having access to your email. That manual is for their nextcloud instance & not email service.
dngray commented 2020-01-30 13:24:06 +00:00 (Migrated from github.com)

Disroot supports zero access encryption. Not enabled by default, will prevent staff from having access to your email.

That manual is for their nextcloud instance & not email service.

Ah yes, my bad. They are doing some changes though shortly, so hopefully that will be done by March.

In any case I have sent them an email to find out what they do.

> > Disroot supports zero access encryption. Not enabled by default, will prevent staff from having access to your email. > > That manual is for their nextcloud instance & not email service. Ah yes, my bad. They are doing some changes though shortly, so hopefully that will be done by March. In any case I have sent them an email to find out what they do.
dngray commented 2020-01-30 16:09:32 +00:00 (Migrated from github.com)

Note to self:

Another thing I want to improve is that warning.

Even when using end-to-end encryption technology like GPG, email is inherently insecure and should not be trusted for sensitive communications. Metadata is always communicated in plaintext, and even when encryption is used correctly it is very easy for either party to accidentally respond to or forward a previously encrypted message in plaintext in many clients.

This is why I made MTA-STS/DANE a base requirement, realistically you do have to trust your server and the remote server to keep that metadata secret.

Also at this time Google, Yahoo and Outlook all use MTA-STS, TLS-RPT so it makes sense it to be a base requirement. Inevitably users will end up emailing people on those services.

We recommend the following email providers for routine notifications and messages from other services that require an email address. For communications that need to be safe and secure, you should use a dedicated instant messaging tool, such as Signal.

I think also we shouldn't recommend one specific messenger here now that the instant messenger page has been revamped.

GPG also does not easily support modern crypto functionality such as key rotation and forward secrecy.

Worth reading this https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/

Additionally the message should not refer to "GPG" that is one implementation of PGP, there are others, eg Other Free Software OpenPGP.

Note to self: Another thing I want to improve [is that warning](https://github.com/privacytoolsIO/privacytools.io/blob/master/pages/software/email.html). > Even when using end-to-end encryption technology like GPG, email is inherently insecure and should not be trusted for sensitive communications. Metadata is always communicated in plaintext, and even when encryption is used correctly it is very easy for either party to accidentally respond to or forward a previously encrypted message in plaintext in many clients. This is why I made MTA-STS/DANE a base requirement, realistically you do have to trust your server and the remote server to keep that metadata secret. Also at this time Google, Yahoo and Outlook all use MTA-STS, TLS-RPT so it makes sense it to be a base requirement. Inevitably users will end up emailing people on those services. > We recommend the following email providers for routine notifications and messages from other services that require an email address. For communications that **need** to be safe and secure, you should use a dedicated instant messaging tool, such as Signal. I think also we shouldn't recommend one specific messenger here now that the instant messenger page has been revamped. > GPG also does not easily support modern crypto functionality such as key rotation and forward secrecy. Worth reading this https://arstechnica.com/information-technology/2016/12/signal-does-not-replace-pgp/ Additionally the message should not refer to "GPG" that is one implementation of [PGP](https://en.wikipedia.org/wiki/Pretty_Good_Privacy), there are others, eg [Other Free Software OpenPGP](https://wiki.gnupg.org/OtherFreeSoftwareOpenPGP).
dngray commented 2020-01-30 16:12:22 +00:00 (Migrated from github.com)

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

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 (Migrated from github.com) reviewed 2020-02-01 19:18:52 +00:00
nitrohorse (Migrated from github.com) left a comment

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

Some small nit-picky suggestions (haven't reviewed all of it but this is so far).
nitrohorse (Migrated from github.com) commented 2020-02-01 19:05:18 +00:00
    <p><strong>Mailbox.org</strong> is a email service with a focus on being secure, ad-free, and privately powered by 100% eco-friendly energy. They have been in operation since <strong>2014</strong>. Mailbox is based in Berlin, <span class="flag-icon flag-icon-de"></span> Germany. Accounts start at 2 GB of storage, and more storage can be purchased. Visit <a href="https://mailbox.org">mailbox.org</a> to create an account.</p>
```suggestion <p><strong>Mailbox.org</strong> is a email service with a focus on being secure, ad-free, and privately powered by 100% eco-friendly energy. They have been in operation since <strong>2014</strong>. Mailbox is based in Berlin, <span class="flag-icon flag-icon-de"></span> Germany. Accounts start at 2 GB of storage, and more storage can be purchased. Visit <a href="https://mailbox.org">mailbox.org</a> to create an account.</p> ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:09:50 +00:00
    <p>ProtonMail also has <a href="https://protonmail.com/blog/zero-access-encryption">zero access encryption at rest</a>. ProtonMail cannot decrypt emails that you have previously received, additionally ProtonMail supports searching encrypted emails. However, for this feature, you must either use their webmail, email client, or bridge software to view your email.</p>
```suggestion <p>ProtonMail also has <a href="https://protonmail.com/blog/zero-access-encryption">zero access encryption at rest</a>. ProtonMail cannot decrypt emails that you have previously received, additionally ProtonMail supports searching encrypted emails. However, for this feature, you must either use their webmail, email client, or bridge software to view your email.</p> ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:10:37 +00:00
    <p>ProtonMail has <a href="https://protonmail.com/support/knowledge-base/how-to-use-pgp">integrated encryption</a> in their webmail.</p>
```suggestion <p>ProtonMail has <a href="https://protonmail.com/support/knowledge-base/how-to-use-pgp">integrated encryption</a> in their webmail.</p> ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:10:51 +00:00
    <p>ProtonMail <a href="https://protonmail.com/blog/security-updates-2019">announced support</a> for discovery of public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>.</p>
```suggestion <p>ProtonMail <a href="https://protonmail.com/blog/security-updates-2019">announced support</a> for discovery of public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>.</p> ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:11:17 +00:00
    <p>ProtonMail has <a href="https://protonmail.com/support/knowledge-base/encrypt-for-outside-users">encryption for outside users</a>.</p>
```suggestion <p>ProtonMail has <a href="https://protonmail.com/support/knowledge-base/encrypt-for-outside-users">encryption for outside users</a>.</p> ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:11:59 +00:00
    <p>Visionary accounts for €24/Month also allow access to ProtonVPN at a discounted price in addition to providing multiple accounts, domains, aliases, and storage.</p>
```suggestion <p>Visionary accounts for €24/Month also allow access to ProtonVPN at a discounted price in addition to providing multiple accounts, domains, aliases, and storage.</p> ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:12:22 +00:00
    <p><strong>Soverin</strong> is an email provider which focuses on being private, ad-free, and powered by sustainable energy. They have been in operation since <strong>2015</strong>. Soverin is based in <span class="flag-icon flag-icon-nl"></span> Amsterdam and does not have a free trial. Accounts start at 25 GB. Visit <a href="https://soverin.net">soverin.net</a> to create an account.</p>
```suggestion <p><strong>Soverin</strong> is an email provider which focuses on being private, ad-free, and powered by sustainable energy. They have been in operation since <strong>2015</strong>. Soverin is based in <span class="flag-icon flag-icon-nl"></span> Amsterdam and does not have a free trial. Accounts start at 25 GB. Visit <a href="https://soverin.net">soverin.net</a> to create an account.</p> ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:13:19 +00:00
    <p>Soverin supports <a href="https://support.soverin.net/hc/en-us/articles/360008819553-Setting-up-2-Factor-Authentication-2FA-Webmail-only">two factor authentication</a> for webmail only with <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a>. They do not allow hardware key authentication such as with a <a href="https://en.wikipedia.org/wiki/YubiKey">Yubikey</a> and <a href="https://en.wikipedia.org/wiki/Nitrokey">Nitrokey</a>.
```suggestion <p>Soverin supports <a href="https://support.soverin.net/hc/en-us/articles/360008819553-Setting-up-2-Factor-Authentication-2FA-Webmail-only">two factor authentication</a> for webmail only with <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a>. They do not allow hardware key authentication such as with a <a href="https://en.wikipedia.org/wiki/YubiKey">Yubikey</a> and <a href="https://en.wikipedia.org/wiki/Nitrokey">Nitrokey</a>. ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:16:25 +00:00
    <p><strong>Posteo</strong> is a email provider that focuses on anonymous, secure, and private email. Their servers are powered by 100% sustainable energy. They have been in operation since <strong>2009</strong>. Posteo is based in <span class="flag-icon flag-icon-de"></span> Germany. Posteo has a free 14-day trial. Posteo comes with 2 GB for the monthly cost and an extra gigabyte can be purchased for 0.25€ per month. Visit <a href="https://posteo.de">posteo.de</a> to create an account.</p>
```suggestion <p><strong>Posteo</strong> is a email provider that focuses on anonymous, secure, and private email. Their servers are powered by 100% sustainable energy. They have been in operation since <strong>2009</strong>. Posteo is based in <span class="flag-icon flag-icon-de"></span> Germany. Posteo has a free 14-day trial. Posteo comes with 2 GB for the monthly cost and an extra gigabyte can be purchased for 0.25€ per month. Visit <a href="https://posteo.de">posteo.de</a> to create an account.</p> ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:16:54 +00:00
    <p><strong>Disroot</strong> offers email amongst <a href="https://disroot.org/en/#services">other services</a>. The service is maintained by volunteers and its community. They have been in operation since <strong>2015</strong>. Disroot is based in <span class="flag-icon flag-icon-nl"></span> Amsterdam. Disroot is free and uses open source software such as Roundcube to provide service. Users support the service through donations and buying extra storage. The mailbox limit is 1 GB, but extra storage can be purchased 0.15€ per GB per month paid yearly. Visit <a href="https://disroot.org/en/services/email">disroot.org</a> to create an account.</p>
```suggestion <p><strong>Disroot</strong> offers email amongst <a href="https://disroot.org/en/#services">other services</a>. The service is maintained by volunteers and its community. They have been in operation since <strong>2015</strong>. Disroot is based in <span class="flag-icon flag-icon-nl"></span> Amsterdam. Disroot is free and uses open source software such as Roundcube to provide service. Users support the service through donations and buying extra storage. The mailbox limit is 1 GB, but extra storage can be purchased 0.15€ per GB per month paid yearly. Visit <a href="https://disroot.org/en/services/email">disroot.org</a> to create an account.</p> ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:17:58 +00:00
    <p><strong>ProtonMail</strong> is a email service with a focus on private, encrypted, secure, and easy to use. They have been in operation since <strong>2013</strong>. ProtonMail is based in Genève, <span class="flag-icon flag-icon-ch"></span> Switzerland. Accounts start at 500 MB for the free version. These accounts are however limited and do not allow the use of the <a href="https://protonmail.com/bridge">ProtonMail Bridge</a>, which is required to use a regular email client. Visit <a href="https://protonmail.com">protonmail.com</a> to create an account.</p>
```suggestion <p><strong>ProtonMail</strong> is a email service with a focus on private, encrypted, secure, and easy to use. They have been in operation since <strong>2013</strong>. ProtonMail is based in Genève, <span class="flag-icon flag-icon-ch"></span> Switzerland. Accounts start at 500 MB for the free version. These accounts are however limited and do not allow the use of the <a href="https://protonmail.com/bridge">ProtonMail Bridge</a>, which is required to use a regular email client. Visit <a href="https://protonmail.com">protonmail.com</a> to create an account.</p> ```
nitrohorse (Migrated from github.com) reviewed 2020-02-01 19:24:25 +00:00
nitrohorse (Migrated from github.com) commented 2020-02-01 19:20:28 +00:00
```suggestion ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:21:24 +00:00

Also I think in their section we can just say Posteo and not Posteo.de.

Also I think in their section we can just say Posteo and not Posteo.de.
nitrohorse (Migrated from github.com) commented 2020-02-01 19:22:05 +00:00
    <p>Posteo.de only only accepts credit/debit cards, PayPal, and cash. They claim that PII that they receive in connection with bank transfers, PayPal, credit cards is not linked to your account.</p>
```suggestion <p>Posteo.de only only accepts credit/debit cards, PayPal, and cash. They claim that PII that they receive in connection with bank transfers, PayPal, credit cards is not linked to your account.</p> ```
nitrohorse (Migrated from github.com) commented 2020-02-01 19:23:59 +00:00
    <p>Disroot accepts PayPal, direct deposit, <strong>Bitcoin</strong>, <strong>Faircoin</strong>, and Patreon when purchasing extra mailbox storage. Donations can be made through Librepay, Flattr, and Monero as well.</p>
```suggestion <p>Disroot accepts PayPal, direct deposit, <strong>Bitcoin</strong>, <strong>Faircoin</strong>, and Patreon when purchasing extra mailbox storage. Donations can be made through Librepay, Flattr, and Monero as well.</p> ```
nitrohorse commented 2020-02-01 19:25:30 +00:00 (Migrated from github.com)

I'm wondering if instead of adding phrase "Visit to create an account," we simply hyperlink the title of each section?

I'm wondering if instead of adding phrase "Visit <url> to create an account," we simply hyperlink the title of each section?
nitrohorse (Migrated from github.com) reviewed 2020-02-01 19:27:59 +00:00
@ -5,3 +4,4 @@
title: "Private Email Providers"
description: "Find a secure email provider that will keep your privacy in mind. Don't settle for ad-supported platforms. Never trust any company with your privacy, always encrypt."
---
nitrohorse (Migrated from github.com) commented 2020-02-01 19:27:59 +00:00

Wondering if we'd want to PR this addition of c0x0 separately so it's not tied to this PR (which is still WIP until March)?

Wondering if we'd want to PR this addition of c0x0 separately so it's not tied to this PR (which is still WIP until March)?
Zcr34 commented 2020-02-01 22:14:56 +00:00 (Migrated from github.com)

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.

Looks good, but do not understand why Mailbox.org is above Posteo or Protonmail? __________________ **Edit**: Just on a basic look through of [ThatOnePrivacySite](https://thatoneprivacysite.net/email-comparison/#detailed-email-comparison): | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |---------------|---------------------------------|-----------------------------|------------------------------------|---------------------------|-------------------------|-----------------------------------|-----------------------|-----------------------------|----------------------------------|-------------------------------|----------------------------|---------------------------------------|-----------------------------------------|------------------------|------------------------------|----------------|----------------|----------------|---------------------------------------|----------------------------------|-------------------------------|----------------|-----------------------------|----------------------------|--------------------------|--------------------------|---------------------------|------------------------------|-------------------------------|----------------------------------|---------------------------------|--------------------------------|---------------------------|----------------------------|------------------------------------|--------------------------------|--------------------|------------------------------|--------------------------------------|---------------------------------------|-----------------------|--------------------------------|-----------------------------------|----------------------------------|---------------------------------| | 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 commented 2020-02-02 01:55:47 +00:00 (Migrated from github.com)

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.

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 commented 2020-02-02 03:27:52 +00:00 (Migrated from github.com)

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]

> 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](https://mailbox.org/) is being listed. If you are looking for custom domain then [Tutanota](https://www.wikipedia.org/wiki/Tutanota), [Kolab Now](https://www.wikipedia.org/wiki/Kolab_Now), or even [Soverin](https://soverin.net/) seem to be better with a more open-source backing _or_ privacy-oriented jurisdiction. Otherwise [Posteo](https://www.wikipedia.org/wiki/Posteo) has been my go to, in part because of their [transparency report](https://posteo.de/en/site/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](https://deploy-preview-1580--privacytools-io.netlify.com/providers/vpn/)]
dngray commented 2020-02-02 06:03:23 +00:00 (Migrated from github.com)

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.

> Perhaps I am wrong, but I also don't understand why [Mailbox.org](https://mailbox.org/) is being listed. > If you are looking for custom domain then [Tutanota](https://www.wikipedia.org/wiki/Tutanota), [Kolab Now](https://www.wikipedia.org/wiki/Kolab_Now), or even [Soverin](https://soverin.net/) 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 (Migrated from github.com) reviewed 2020-02-02 06:08:56 +00:00
@ -5,3 +4,4 @@
title: "Private Email Providers"
description: "Find a secure email provider that will keep your privacy in mind. Don't settle for ad-supported platforms. Never trust any company with your privacy, always encrypt."
---
dngray (Migrated from github.com) commented 2020-02-02 06:08:56 +00:00

I can do that easily enough and then that would also resolve #1673

I can do that easily enough and then that would also resolve #1673
dngray commented 2020-02-02 06:09:52 +00:00 (Migrated from github.com)

I'm wondering if instead of adding phrase "Visit to create an account," we simply hyperlink the title of each section?

I agree. I have to admit with that I followed the style of the VPN page.

> I'm wondering if instead of adding phrase "Visit to create an account," we simply hyperlink the title of each section? I agree. I have to admit with that I followed the style of the VPN page.
dngray (Migrated from github.com) reviewed 2020-02-02 07:46:05 +00:00
dngray (Migrated from github.com) commented 2020-02-02 07:46:04 +00:00

Agreed, its how they refer to themselves on their website.

Agreed, its how they refer to themselves on their website.
dngray (Migrated from github.com) reviewed 2020-02-02 07:46:43 +00:00
dngray (Migrated from github.com) commented 2020-02-02 07:46:43 +00:00

Wow that was really a munted sentence. heh.

Wow that was really a munted sentence. heh.
dngray (Migrated from github.com) reviewed 2020-02-02 08:05:31 +00:00
@ -5,3 +4,4 @@
title: "Private Email Providers"
description: "Find a secure email provider that will keep your privacy in mind. Don't settle for ad-supported platforms. Never trust any company with your privacy, always encrypt."
---
dngray (Migrated from github.com) commented 2020-02-02 08:05:31 +00:00

Actually I decided against that because the indenting etc changed as a part of this PR. It's going to cause a conflict later that will need to be fixed. 4 weeks isn't that long.

Actually I decided against that because the indenting etc changed as a part of this PR. It's going to cause a conflict later that will need to be fixed. 4 weeks isn't that long.
dngray commented 2020-02-03 03:30:21 +00:00 (Migrated from github.com)

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
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](https://www.mailvelope.com) 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](https://developers.google.com/gmail/imap/xoauth2-protocol)). ### 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 (Migrated from github.com) reviewed 2020-02-05 21:45:13 +00:00
fm (Migrated from github.com) left a comment

Thought I'd leave some suggestions and corrections.

Thought I'd leave some suggestions and corrections.
fm (Migrated from github.com) commented 2020-02-05 21:28:04 +00:00

Here's a better, more recent reddit thread for YubiKey 2FA
https://www.reddit.com/r/ProtonMail/comments/cheoy6/when_u2f/feh2lw0/

TLDR: It's coming sometime in Q2 2020 with the revamp of their SSO login backend

Here's a better, more recent reddit thread for YubiKey 2FA https://www.reddit.com/r/ProtonMail/comments/cheoy6/when_u2f/feh2lw0/ TLDR: It's coming sometime in Q2 2020 with the revamp of their SSO login backend
fm (Migrated from github.com) commented 2020-02-05 21:30:01 +00:00

However, for this feature, you must either use their webmail, email client, or bridge software to view your email.

Might be worth adding only from, to and subject are searchable in webmail and mobile apps. Bridge is needed for full text searching. However, full-text searching is coming to webmail and mobile apps in v4. No ETA.

> However, for this feature, you must either use their webmail, email client, or bridge software to view your email. Might be worth adding only _from, to and subject_ are searchable in webmail and mobile apps. Bridge is needed for full text searching. However, full-text searching is coming to webmail and mobile apps in v4. No ETA.
fm (Migrated from github.com) commented 2020-02-05 21:33:41 +00:00

also allow access to ProtonVPN at a discounted price

Visionary actually includes ProtonVPN Plus with an extra 5 devices in the price. The current wording makes it sound like you have to pay extra, but get a discount.

> also allow access to ProtonVPN at a discounted price Visionary actually includes ProtonVPN Plus with an extra 5 devices in the price. The current wording makes it sound like you have to pay extra, but get a discount.
fm (Migrated from github.com) commented 2020-02-05 21:38:11 +00:00

Pricing depends if you own the domain or not. If you own the domain, it's €29/year. However you can purchase a domain through them. Price increases to €44/year for a .com or €39/year for a .net

Pricing depends if you own the domain or not. If you own the domain, it's €29/year. However you can purchase a domain through them. Price increases to €44/year for a .com or €39/year for a .net
fm (Migrated from github.com) commented 2020-02-05 21:40:59 +00:00

They aliases, however [...]

missing a have after they

> They aliases, however [...] missing a _have_ after _they_
@ -5,3 +4,4 @@
title: "Private Email Providers"
description: "Find a secure email provider that will keep your privacy in mind. Don't settle for ad-supported platforms. Never trust any company with your privacy, always encrypt."
---
fm (Migrated from github.com) commented 2020-02-05 21:19:51 +00:00

There's a typo in YubKey, should be YubiKey

There's a typo in _YubKey_, should be _YubiKey_
dngray (Migrated from github.com) reviewed 2020-02-06 03:28:55 +00:00
@ -5,3 +4,4 @@
title: "Private Email Providers"
description: "Find a secure email provider that will keep your privacy in mind. Don't settle for ad-supported platforms. Never trust any company with your privacy, always encrypt."
---
dngray (Migrated from github.com) commented 2020-02-06 03:28:54 +00:00

Well spotted.

Well spotted.
dngray (Migrated from github.com) reviewed 2020-02-06 03:29:09 +00:00
dngray (Migrated from github.com) commented 2020-02-06 03:29:08 +00:00

Thanks for that, I did not know.

Thanks for that, I did not know.
dngray (Migrated from github.com) reviewed 2020-02-07 13:42:59 +00:00
dngray (Migrated from github.com) commented 2020-02-07 13:42:59 +00:00

have you got a source for that coming in V4?

have you got a source for that coming in V4?
fm (Migrated from github.com) reviewed 2020-02-07 13:56:44 +00:00
fm (Migrated from github.com) commented 2020-02-07 13:56:44 +00:00
Here you go: https://www.reddit.com/r/ProtonMail/comments/dv4740/status_of_v40_search_capability/ https://www.reddit.com/r/ProtonMail/comments/cqwk2a/protonmail_v4_and_content_search/ex21b4e/
dngray (Migrated from github.com) reviewed 2020-02-07 15:20:58 +00:00
dngray (Migrated from github.com) commented 2020-02-07 15:20:58 +00:00

Hmm, I think I'll list the €29 value then. Seeing as I have not listed the value with custom domains from for other providers.

To be honest, I would avoid buying a domain from the same place as a website/email provider.

Hmm, I think I'll list the €29 value then. Seeing as I have not listed the value with custom domains from for other providers. To be honest, I would avoid buying a domain from the same place as a website/email provider.
jonah reviewed 2020-02-10 16:35:40 +00:00
@ -5,3 +4,4 @@
title: "Private Email Providers"
description: "Find a secure email provider that will keep your privacy in mind. Don't settle for ad-supported platforms. Never trust any company with your privacy, always encrypt."
---

I don't like this change, I don't think it gets the point across. If we are using a warning like this at the top it should be to the point. I also liked the old one and disagree that it is misleading or needing of a change in the first place.

If you want to elaborate further on the virtues and drawbacks of GPG, add a further info section like this one instead: https://www.privacytools.io/providers/vpn/#info

You also need to use proper colors in this card (text-danger for warning text and text-secondary for supplementary info).

I don't like this change, I don't think it gets the point across. If we are using a warning like this at the top it should be to the point. I also liked the old one and disagree that it is misleading or needing of a change in the first place. If you want to elaborate further on the virtues and drawbacks of GPG, add a further info section like this one instead: https://www.privacytools.io/providers/vpn/#info You also need to use proper colors in this card (`text-danger` for warning text and `text-secondary` for supplementary info).
jonah reviewed 2020-02-10 16:43:38 +00:00
@ -5,3 +4,4 @@
title: "Private Email Providers"
description: "Find a secure email provider that will keep your privacy in mind. Don't settle for ad-supported platforms. Never trust any company with your privacy, always encrypt."
---

Based on https://github.com/privacytoolsIO/privacytools.io/pull/1672#issuecomment-580327809, here's what I would do I guess:

! WARNING
[text-danger] Even when using end-to-end encryption technology like GPG, email will still contain metadata that is not encrypted end-to-end. Additionally, GPG does not support forward secrecy. If either your or the recipients' private keys are ever stolen, all previous messages encrypted with them will be exposed.
[text-secondary] Some email providers use Opportunistic TLS to protect email metadata between servers, however both your email provider and the recipients' will still be able to view the metadata. As an alternative to email, consider switching conversations to a secure instant messenger that does support forward secrecy.
[btn-outline-secondary: Recommended Instant Messengers]

Everything else is not immediately important information. I would definitely keep these particular cards limited to 2 paragraphs.

Based on https://github.com/privacytoolsIO/privacytools.io/pull/1672#issuecomment-580327809, here's what I would do I guess: ! WARNING [`text-danger`] Even when using end-to-end encryption technology like GPG, email will still contain [metadata](https://en.wikipedia.org/wiki/Email#Message_header) that is not encrypted end-to-end. Additionally, GPG does not support [forward secrecy](https://en.wikipedia.org/wiki/Forward_secrecy). If either your or the recipients' private keys are ever stolen, all previous messages encrypted with them will be exposed. [`text-secondary`] Some email providers use [Opportunistic TLS](https://en.wikipedia.org/wiki/Opportunistic_TLS) to protect email metadata between servers, however both your email provider and the recipients' will still be able to view the metadata. As an alternative to email, consider switching conversations to a secure instant messenger that does support forward secrecy. [`btn-outline-secondary`: Recommended Instant Messengers] Everything else is not immediately important information. I would *definitely* keep these particular cards limited to 2 paragraphs.
image

You should move everything the 4 providers on that page collectively support to the minimum side if you aren't doing so already. Set the bars as high as possible.

<img width="1211" alt="image" src="https://user-images.githubusercontent.com/3637842/74170967-5b5a4480-4bf3-11ea-9fa5-f1d5554823f5.png"> You should move everything the 4 providers on that page collectively support to the minimum side if you aren't doing so already. Set the bars as high as possible.
jonah reviewed 2020-02-11 14:23:42 +00:00
jonah left a comment

grammar 'n stuff

grammar 'n stuff
@ -4,3 +4,3 @@
title: "Best Secure Email Providers for Privacy"
title: "Private Email Providers"
description: "Find a secure email provider that will keep your privacy in mind. Don't settle for ad-supported platforms. Never trust any company with your privacy, always encrypt."
---
      <p class="card-text text-danger">When using end-to-end encryption technology like <a href="https://en.wikipedia.org/wiki/Pretty_Good_Privacy">PGP</a>, email will still have some metadata that is not encrypted in the header of the email. <a href="/providers/email/#info">Read more about email metadata.</a></p>

LGTM, but I would probably make this link a call-to-action.

```suggestion <p class="card-text text-danger">When using end-to-end encryption technology like <a href="https://en.wikipedia.org/wiki/Pretty_Good_Privacy">PGP</a>, email will still have some metadata that is not encrypted in the header of the email. <a href="/providers/email/#info">Read more about email metadata.</a></p> ``` LGTM, but I would probably make this link a call-to-action.
      <p class="card-text text-danger">PGP also does not support <a href="https://en.wikipedia.org/wiki/Forward_secrecy">Forward secrecy</a>, which means if either your private key or the recipient's is ever stolen, <strong>all</strong> previous messages encrypted with it will be exposed. <a href="/providers/email/#info">How do I protect my private keys?</a></p>
```suggestion <p class="card-text text-danger">PGP also does not support <a href="https://en.wikipedia.org/wiki/Forward_secrecy">Forward secrecy</a>, which means if either your private key or the recipient's is ever stolen, <strong>all</strong> previous messages encrypted with it will be exposed. <a href="/providers/email/#info">How do I protect my private keys?</a></p> ```
      <p class="card-text text-secondary">Alternatively, consider moving prolonged conversation to a medium that does support Forward secrecy.</p>
```suggestion <p class="card-text text-secondary">Alternatively, consider moving prolonged conversation to a medium that does support Forward secrecy.</p> ```
dngray (Migrated from github.com) reviewed 2020-02-12 14:42:14 +00:00
@ -5,3 +4,4 @@
title: "Private Email Providers"
description: "Find a secure email provider that will keep your privacy in mind. Don't settle for ad-supported platforms. Never trust any company with your privacy, always encrypt."
---
dngray (Migrated from github.com) commented 2020-02-12 14:42:14 +00:00

I think we've moved past this with the Q&A on email metadata

I think we've moved past this with the Q&A on email metadata
blacklight447 commented 2020-02-12 17:38:30 +00:00 (Migrated from github.com)

In the section where we describe that people can run their own email server at the bottom of the page, I think we need to press more on the fact that running an email server securely is hard, and requires regular maintenance, so its not an option for the average non tech savvy user.

Also the title of the page sounds a bit weird to me: "best secure".

How about changing it to: The most privacy friendly secure email providers. ?

In the section where we describe that people can run their own email server at the bottom of the page, I think we need to press more on the fact that running an email server securely is hard, and requires regular maintenance, so its not an option for the average non tech savvy user. Also the title of the page sounds a bit weird to me: "best secure". How about changing it to: The most privacy friendly secure email providers. ?
dngray commented 2020-02-13 02:11:08 +00:00 (Migrated from github.com)

In the section where we describe that people can run their own email server at the bottom of the page, I think we need to press more on the fact that running an email server securely is hard, and requires regular maintenance, so its not an option for the average non tech savvy user.

Good point, I'm also thinking of splitting that Q&A section. Eg " Further Information and Dangers" we could have a heading just called "Email metadata" and another one "Email encryption"?

Also the title of the page sounds a bit weird to me: "best secure".

I don't like that either. It's just what was there before.

How about changing it to: The most privacy friendly secure email providers. ?

Yes this sounds much better

> In the section where we describe that people can run their own email server at the bottom of the page, I think we need to press more on the fact that running an email server securely is hard, and requires regular maintenance, so its not an option for the average non tech savvy user. Good point, I'm also thinking of splitting that Q&A section. Eg " Further Information and Dangers" we could have a heading just called "Email metadata" and another one "Email encryption"? > Also the title of the page sounds a bit weird to me: "best secure". I don't like that either. It's just what was there before. > How about changing it to: The most privacy friendly secure email providers. ? Yes this sounds much better
dngray commented 2020-02-13 03:01:40 +00:00 (Migrated from github.com)

Removing Confidant Mail mention.

Last version was 0.45 released 2018-09-06 (minor release). Doesn't seem under active development. Discussion forums offline, and I couldn't find a link to a source repo in version control so it's not community maintained, eg PRs etc. Also the binary releases ship old versions of GnuPG.

Removing Confidant Mail mention. Last version was 0.45 released 2018-09-06 (minor release). Doesn't seem under active development. Discussion forums offline, and I couldn't find a link to a source repo in version control so it's not community maintained, eg PRs etc. Also the binary releases ship old versions of GnuPG.
jonah reviewed 2020-02-13 04:16:28 +00:00

something is messed up here. you are missing a closing div. I don't know why these lines exist in the first place

something is messed up here. you are missing a closing div. I don't know why these lines exist in the first place
jonah reviewed 2020-02-13 04:27:48 +00:00
jonah left a comment

cleanup

cleanup

useless?

useless?

illegal html, ul cannot exist inside p tag

illegal html, ul cannot exist inside p tag

stray li tag??

stray li tag??

cleanup

image
> cleanup <img width="1560" alt="image" src="https://user-images.githubusercontent.com/3637842/74401700-b48ac980-4de7-11ea-858f-f9b3403d1900.png">
dngray (Migrated from github.com) reviewed 2020-02-13 04:43:13 +00:00
dngray (Migrated from github.com) commented 2020-02-13 04:43:13 +00:00

This was intended to be used re https://github.com/privacytoolsIO/privacytools.io/pull/1672#issuecomment-584220268 however none of our providers actually universally support "all of those things".

This was intended to be used re https://github.com/privacytoolsIO/privacytools.io/pull/1672#issuecomment-584220268 however none of our providers actually universally support "all of those things".
dngray commented 2020-02-13 10:34:08 +00:00 (Migrated from github.com)

Adding @dawidpotocki because he's going to fix the anonaddy and mailcow logos!

Adding @dawidpotocki because he's going to fix the anonaddy and mailcow logos!
fm (Migrated from github.com) reviewed 2020-02-13 15:33:39 +00:00
fm (Migrated from github.com) left a comment

Just a lil' bit more feedback

Just a lil' bit more feedback
@ -28,0 +197,4 @@
<h3>Who can see the email metadata?</h3>
<p>Email metadata is able to be seen by your email client software (or webmail) and any servers relaying the message from you to any recipients. Sometimes email servers will also use external parties to protect against spam.</p>
<h3>What is email metadata?</h3>
<p>Email software will often show some visible headers that you may have seen such as: <code>To</code>, <code>From</code>, <code>Cc</code>, <code>Date</code>, <code>Subject</code>.
fm (Migrated from github.com) commented 2020-02-13 15:25:39 +00:00

Since E2EE means "End to end encryption" the sentence effectively reads "Why can't email metadata be encrypted end to end encryption"; there should be a with before the E2EE.

Alternatively, the word encrypted could be removed and the sentence read "Why can't email metadata be E2EE"

Since E2EE means "End to end encryption" the sentence effectively reads _"Why can't email metadata be encrypted end to end encryption"_; there should be a `with` before the E2EE. Alternatively, the word `encrypted` could be removed and the sentence read _"Why can't email metadata be E2EE"_
fm (Migrated from github.com) commented 2020-02-13 15:30:03 +00:00

Can be self-hosted.

Missing a period at the end, and capitalize the next sentence Source code [...]

> Can be self-hosted. Missing a period at the end, and capitalize the next sentence `Source code [...]`
Mikaela (Migrated from github.com) reviewed 2020-02-13 16:08:55 +00:00
Mikaela (Migrated from github.com) left a comment

I think the top recommendations are somewhat unclear on encryption, at times encryption seems to mean OpenPGP and then turn into temporary mailboxes that are encryption for external users like the external users couldn't be manually using OpenPGP? WKD also isn't explained in much detail and it's left unclear whether the service will provide WKD for external clients or the service will fetch the key of external user from WKD?

I think the top recommendations are somewhat unclear on encryption, at times encryption seems to mean OpenPGP and then turn into temporary mailboxes that are encryption for external users like the external users couldn't be manually using OpenPGP? WKD also isn't explained in much detail and it's left unclear whether the service will provide WKD for external clients or the service will fetch the key of external user from WKD?
Mikaela (Migrated from github.com) commented 2020-02-13 15:45:54 +00:00
    <p>Mailbox.org doesn't accept Bitcoin or any other cryptocurrencies as a result of their payment processor BitPay suspending operations in Germany. They do accept <strong>Cash by mail</strong>, <strong>cash payment to bank acccount</strong>, bank transfer, credit card, PayPal and couple of German only processors paydirekt and Sofort.</p>

Typo?

```suggestion <p>Mailbox.org doesn't accept Bitcoin or any other cryptocurrencies as a result of their payment processor BitPay suspending operations in Germany. They do accept <strong>Cash by mail</strong>, <strong>cash payment to bank acccount</strong>, bank transfer, credit card, PayPal and couple of German only processors paydirekt and Sofort.</p> ``` Typo?
Mikaela (Migrated from github.com) commented 2020-02-13 15:48:48 +00:00
    ProtonMail is <a href="https://protonmail.com/tor">accessible via Tor</a>. Their onion service is <a href="https://protonirockerxow.onion/">protonirockerxow.onion</a>.

They seem to be using the old word hidden service, so up to you whether you will accept this or the other suggestion.

```suggestion ProtonMail is <a href="https://protonmail.com/tor">accessible via Tor</a>. Their onion service is <a href="https://protonirockerxow.onion/">protonirockerxow.onion</a>. ``` They seem to be using the old word hidden service, so up to you whether you will accept this or the other suggestion.
Mikaela (Migrated from github.com) commented 2020-02-13 15:49:17 +00:00
    <p>Mailbox.org allows for <a href="https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol">IMAP</a> connections via their <a href="https://kb.mailbox.org/display/MBOKBEN/The+Tor+exit+node+of+mailbox.org">Tor onion service</a>.</p>
```suggestion <p>Mailbox.org allows for <a href="https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol">IMAP</a> connections via their <a href="https://kb.mailbox.org/display/MBOKBEN/The+Tor+exit+node+of+mailbox.org">Tor onion service</a>.</p> ```
Mikaela (Migrated from github.com) commented 2020-02-13 15:52:34 +00:00

I think their TOTP support is only for NextCloud?

I think their TOTP support is only for NextCloud?
Mikaela (Migrated from github.com) commented 2020-02-13 15:55:34 +00:00

Have you contacted them about this? Last I heard of their Diaspora* pod, it was slowly being discontinued in favour of Hubzilla and not part of their LDAP and at the moment its register page tells me that open registrations are currently closed.

Have you contacted them about this? Last I heard of their Diaspora\* pod, it was slowly being discontinued in favour of Hubzilla and not part of their LDAP and at the moment its register page tells me that open registrations are currently closed.
Mikaela (Migrated from github.com) commented 2020-02-13 16:00:00 +00:00
        <li>Availability of the email provider's services over a <a href="https://en.wikipedia.org/wiki/.onion">.onion Service</a>.</li>
```suggestion <li>Availability of the email provider's services over a <a href="https://en.wikipedia.org/wiki/.onion">.onion Service</a>.</li> ```
@ -28,0 +186,4 @@
<h3>How do I protect my private keys?</h3>
<p>A smartcard (such as a <a href="https://support.yubico.com/support/solutions/articles/15000006420-using-your-yubikey-with-openpgp">Yubikey</a> or <a href="https://www.nitrokey.com">Nitrokey</a>) works by receiving an encrypted email message from a device (phone, tablet, computer etc) running an email/webmail client. The message is then decrypted by the smartcard and the decrypted content is sent back to the device.</p>
<p>It is advantageous for the decryption to occur on the smartcard so as to avoid possibly exposing your private key to a compromised device.</p>
</div>
Mikaela (Migrated from github.com) commented 2020-02-13 16:03:30 +00:00

I don't know if it's of interest here, but multiple countries issue S/MIME certificates on identity cards including, but not limited to Finland and Estonia. I don't know of anyone actually using them though and it's a pain to get working under any system.

I don't know if it's of interest here, but multiple countries issue S/MIME certificates on identity cards including, but not limited to Finland and Estonia. I don't know of anyone actually using them though and it's a pain to get working under any system.
fm (Migrated from github.com) reviewed 2020-02-13 16:13:08 +00:00
fm (Migrated from github.com) left a comment

Couple more edits

Couple more edits
fm (Migrated from github.com) commented 2020-02-13 15:56:36 +00:00

[...] and couple of German only processors, paydirekt and Sofort.

Missing a comma after processors

> [...] and couple of German only processors, paydirekt and Sofort. Missing a comma after `processors`
fm (Migrated from github.com) commented 2020-02-13 15:57:32 +00:00

Posteo is based in Germany. Posteo has a free 14-day trial.

I'd remove the second Posteo, like so

Posteo is based in Germany and has a free 14-day trial.

>Posteo is based in Germany. Posteo has a free 14-day trial. I'd remove the second Posteo, like so > Posteo is based in Germany and has a free 14-day trial.
fm (Migrated from github.com) commented 2020-02-13 15:59:34 +00:00

Posteo only only accepts credit/debit cards [..]

Doubled only

> Posteo only only accepts credit/debit cards [..] Doubled only
fm (Migrated from github.com) commented 2020-02-13 16:11:05 +00:00

Missing a . at the end of the last sentence

Missing a . at the end of the last sentence
dngray (Migrated from github.com) reviewed 2020-02-13 16:16:59 +00:00
dngray (Migrated from github.com) commented 2020-02-13 16:16:58 +00:00

I have checked in my Disroot account and yes you can for webmail only. The documentation doesn't indicate that however hence why I removed the link.

I have checked in my Disroot account and yes you can for webmail only. The documentation doesn't indicate that however hence why I removed the link.
dngray (Migrated from github.com) reviewed 2020-02-13 16:17:37 +00:00
dngray (Migrated from github.com) commented 2020-02-13 16:17:37 +00:00

Nah that would have been my mistake. Guess that shows how old I am.

Nah that would have been my mistake. Guess that shows how old I am.
dngray (Migrated from github.com) reviewed 2020-02-13 16:19:33 +00:00
dngray (Migrated from github.com) commented 2020-02-13 16:19:33 +00:00

I was not aware of that, I'll be sure to update that then and check with them about it.

I was not aware of that, I'll be sure to update that then and check with them about it.
dngray commented 2020-02-13 16:22:45 +00:00 (Migrated from github.com)

Just a lil' bit more feedback

Much appreciated! also thanks, @fm @Mikaela !

I am thinking of also doing a summary matrix table, I've had 3 requests for that. What do you guys think? Something like https://github.com/privacytoolsIO/privacytools.io/issues/603#issuecomment-456400331 but for the features we list for each provider, so at a glance you can see what is supported.

> Just a lil' bit more feedback Much appreciated! also thanks, @fm @Mikaela ! I am thinking of also doing a summary matrix table, I've had 3 requests for that. What do you guys think? Something like https://github.com/privacytoolsIO/privacytools.io/issues/603#issuecomment-456400331 but for the features we list for each provider, so at a glance you can see what is supported.
fm commented 2020-02-13 16:24:57 +00:00 (Migrated from github.com)

I am thinking of also doing a summary matrix table, I've had 3 requests for that. What do you guys think? Something like #603 (comment) but for the features we list for each provider, so at a glance you can see what is supported.

I'm a big fan of this - seeing them all at glance, and then you can do a deep dive into each with the explanations.

> I am thinking of also doing a summary matrix table, I've had 3 requests for that. What do you guys think? Something like [#603 (comment)](https://github.com/privacytoolsIO/privacytools.io/issues/603#issuecomment-456400331) but for the features we list for each provider, so at a glance you can see what is supported. I'm a big fan of this - seeing them all at glance, and then you can do a deep dive into each with the explanations.
Mikaela (Migrated from github.com) reviewed 2020-02-13 16:26:33 +00:00
Mikaela (Migrated from github.com) commented 2020-02-13 16:26:33 +00:00

https://community.torproject.org/onion-services/ is the upstream if you are interested

https://community.torproject.org/onion-services/ is the upstream if you are interested
dngray commented 2020-02-13 16:41:45 +00:00 (Migrated from github.com)

I'm a big fan of this - seeing them all at glance, and then you can do a deep dive into each with the explanations.

well that's 4 requests then.

We could do a anchor link for each item in the table to the extended information about that provider. Keep up the good work, I shall check it later.

This bear is going zzz

for a while.

> I'm a big fan of this - seeing them all at glance, and then you can do a deep dive into each with the explanations. well that's 4 requests then. We could do a anchor link for each item in the table to the extended information about that provider. Keep up the good work, I shall check it later. This bear is going ![zzz](https://user-images.githubusercontent.com/48640805/74457351-0c750f00-4e80-11ea-9d92-c960e30a3274.jpg) for a while.
dngray (Migrated from github.com) reviewed 2020-02-14 02:45:35 +00:00
@ -28,0 +197,4 @@
<h3>Who can see the email metadata?</h3>
<p>Email metadata is able to be seen by your email client software (or webmail) and any servers relaying the message from you to any recipients. Sometimes email servers will also use external parties to protect against spam.</p>
<h3>What is email metadata?</h3>
<p>Email software will often show some visible headers that you may have seen such as: <code>To</code>, <code>From</code>, <code>Cc</code>, <code>Date</code>, <code>Subject</code>.
dngray (Migrated from github.com) commented 2020-02-14 02:45:35 +00:00

Alternatively, the word encrypted could be removed and the sentence read "Why can't email metadata be E2EE"

I think I'll go with that.

> Alternatively, the word `encrypted` could be removed and the sentence read "Why can't email metadata be E2EE" I think I'll go with that.
dngray (Migrated from github.com) reviewed 2020-02-14 02:51:34 +00:00
@ -28,0 +186,4 @@
<h3>How do I protect my private keys?</h3>
<p>A smartcard (such as a <a href="https://support.yubico.com/support/solutions/articles/15000006420-using-your-yubikey-with-openpgp">Yubikey</a> or <a href="https://www.nitrokey.com">Nitrokey</a>) works by receiving an encrypted email message from a device (phone, tablet, computer etc) running an email/webmail client. The message is then decrypted by the smartcard and the decrypted content is sent back to the device.</p>
<p>It is advantageous for the decryption to occur on the smartcard so as to avoid possibly exposing your private key to a compromised device.</p>
</div>
dngray (Migrated from github.com) commented 2020-02-14 02:51:34 +00:00

I didn't know that. Only reason I mentioned S/MIME was because someone requested that. I wonder if we can find a list of countries which do this?

I didn't know that. Only reason I mentioned S/MIME was because someone requested that. I wonder if we can find a list of countries which do this?
muppeth (Migrated from github.com) reviewed 2020-02-14 11:17:53 +00:00
muppeth (Migrated from github.com) commented 2020-02-14 11:17:52 +00:00

Hi there.
Yeah it;s true we are phasing out diaspora which is why diaspora will be also removed from our website by the end of the week. We are most probably going to switch to hubzilla but thats not ready yet and might at the end lead us to siwtching to something totally different (we are open for alternatives although hubzilla is at the moment no.1). Since hubzilla is still in alpha testing on our servers, it's not mentioned on the website but it is usable (just removed the link registration closed). and yeah hubzilla does work with our ldap (though you need to provide disoot email and not just username.

Hi there. Yeah it;s true we are phasing out diaspora which is why diaspora will be also removed from our website by the end of the week. We are most probably going to switch to hubzilla but thats not ready yet and might at the end lead us to siwtching to something totally different (we are open for alternatives although hubzilla is at the moment no.1). Since hubzilla is still in alpha testing on our servers, it's not mentioned on the website but it is usable (just removed the link registration closed). and yeah hubzilla does work with our ldap (though you need to provide disoot email and not just username.
dngray (Migrated from github.com) reviewed 2020-02-14 12:30:08 +00:00
dngray (Migrated from github.com) commented 2020-02-14 12:30:07 +00:00

TLDR: It's coming sometime in Q2 2020 with the revamp of their SSO login backend

Have you got a link for the Q2 2020 prediction? The one you supplied doesn't say 2020.

> TLDR: It's coming sometime in Q2 2020 with the revamp of their SSO login backend Have you got a link for the Q2 2020 prediction? The one you supplied doesn't say 2020.
dngray (Migrated from github.com) reviewed 2020-02-14 13:02:28 +00:00
dngray (Migrated from github.com) commented 2020-02-14 13:02:27 +00:00

we are phasing out diaspora which is why diaspora will be also removed from our website by the end of the week.

Okay I won't mention it then. I won't mention Hubzilla until it becomes generally available.

> we are phasing out diaspora which is why diaspora will be also removed from our website by the end of the week. Okay I won't mention it then. I won't mention Hubzilla until it becomes generally available.
dngray commented 2020-02-14 13:08:12 +00:00 (Migrated from github.com)

I think the top recommendations are somewhat unclear on encryption, at times encryption seems to mean OpenPGP and then turn into temporary mailboxes that are encryption for external users like the external users couldn't be manually using OpenPGP?

Generally any provider which provides external temporary mailboxes does so, so the user recipient doesn't have to configure OpenPGP in for their reply.

WKD also isn't explained in much detail and it's left unclear whether the service will provide WKD for external clients or the service will fetch the key of external user from WKD?

I know WKD support works with Thunderbird according to the enigmail changelog:

Enigmail 2.0
Released 2018-03-25, works with Thunderbird 52.0 - 60.0 and SeaMonkey 2.46 - 2.55.

Support for Web Key Directory (WKD) is implemented. Enigmail will try to download unavailable keys during message composition from WKD. If you use GnuPG 2.2.x, and your provider supports the Web Key Service protocol, you can also use Enigmail to upload your key to WKD.

> I think the top recommendations are somewhat unclear on encryption, at times encryption seems to mean OpenPGP and then turn into temporary mailboxes that are encryption for external users like the external users couldn't be manually using OpenPGP? Generally any provider which provides external temporary mailboxes does so, so the user recipient doesn't have to configure OpenPGP in for their reply. > WKD also isn't explained in much detail and it's left unclear whether the service will provide WKD for external clients or the service will fetch the key of external user from WKD? I know WKD support works with Thunderbird according to the [enigmail changelog](https://www.enigmail.net/index.php/en/download/changelog): > Enigmail 2.0 > Released 2018-03-25, works with Thunderbird 52.0 - 60.0 and SeaMonkey 2.46 - 2.55. > Support for [Web Key Directory (WKD)](https://wiki.gnupg.org/WKD) is implemented. Enigmail will try to download unavailable keys during message composition from WKD. If you use GnuPG 2.2.x, and your provider supports the [Web Key Service](https://wiki.gnupg.org/WKS) protocol, you can also use Enigmail to upload your key to WKD.
jonah reviewed 2020-02-14 16:06:40 +00:00
  <strong>Our recommended providers operate outside of the US, adopt modern email technology, and meet <a href="/providers/email/#criteria">our other criteria</a> for listing.</strong>

/me is a strong proponent of the oxford comma

```suggestion <strong>Our recommended providers operate outside of the US, adopt modern email technology, and meet <a href="/providers/email/#criteria">our other criteria</a> for listing.</strong> ``` /me is a strong proponent of the oxford comma
    <p><strong><a href="https://protonmail.com">ProtonMail.com</a></strong> is an email service with a focus on privacy, encryption, security, and ease of use. They have been in operation since <strong>2013</strong>. ProtonMail is based in Genève, <span class="flag-icon flag-icon-ch"></span> Switzerland. Accounts start with 500 MB storage with their free plan.</p>
```suggestion <p><strong><a href="https://protonmail.com">ProtonMail.com</a></strong> is an email service with a focus on privacy, encryption, security, and ease of use. They have been in operation since <strong>2013</strong>. ProtonMail is based in Genève, <span class="flag-icon flag-icon-ch"></span> Switzerland. Accounts start with 500 MB storage with their free plan.</p> ```
    <p>Free accounts are limited and do not allow the use of the <a href="https://protonmail.com/bridge">ProtonMail Bridge</a>, which is required to use a <a href="/software/email">recommended email client</a> (eg. Thunderbird) to access your email via IMAP, or to search email by body text. Their webmail and mobile apps can only search <code>To:</code>, <code>From:</code> and <code>Date:</code> (this is subject to change in v4.0 of ProtonMail) <sup><a href="https://reddit.com/comments/dv4740">[1]</a> <a href="https://reddit.com/comments/cqwk2a/comment/ex21b4e">[2]</a></sup>.</p>

We don't really have a mechanism for citations like this, so I wonder if this is the best way to show this information in the first place.

```suggestion <p>Free accounts are limited and do not allow the use of the <a href="https://protonmail.com/bridge">ProtonMail Bridge</a>, which is required to use a <a href="/software/email">recommended email client</a> (eg. Thunderbird) to access your email via IMAP, or to search email by body text. Their webmail and mobile apps can only search <code>To:</code>, <code>From:</code> and <code>Date:</code> (this is subject to change in v4.0 of ProtonMail) <sup><a href="https://reddit.com/comments/dv4740">[1]</a> <a href="https://reddit.com/comments/cqwk2a/comment/ex21b4e">[2]</a></sup>.</p> ``` We don't really have a mechanism for citations like this, so I wonder if this is the best way to show this information in the first place.
    <p>ProtonMail supports <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a> <a href="https://protonmail.com/support/knowledge-base/two-factor-authentication/">two factor authentication</a> only. The use of a <a href="https://en.wikipedia.org/wiki/Universal_2nd_Factor">U2F</a> security key is not yet supported, however this is <a href="https://reddit.com/comments/cheoy6/comment/feh2lw0">reportedly planned for Q2 2020</a>.</p>

Until we finish #904 we probably shouldn't either link to nor mention any specific hardware, just technologies.

```suggestion <p>ProtonMail supports <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a> <a href="https://protonmail.com/support/knowledge-base/two-factor-authentication/">two factor authentication</a> only. The use of a <a href="https://en.wikipedia.org/wiki/Universal_2nd_Factor">U2F</a> security key is not yet supported, however this is <a href="https://reddit.com/comments/cheoy6/comment/feh2lw0">reportedly planned for Q2 2020</a>.</p> ``` Until we finish #904 we probably shouldn't either link to nor mention any specific hardware, just technologies.
    <p>ProtonMail has <a href="https://protonmail.com/blog/zero-access-encryption">zero access encryption at rest</a>, which means they cannot decrypt emails that you have previously received. Additionally, ProtonMail supports searching encrypted emails. To use this feature you must use their webmail, email client or bridge software to view your email.</p>

To use this feature you must use their webmail

Literally up above you said this was not possible with their webmail:

The webmail and mobile apps can only search To:, From: and Date: (this is subject to change in v4.0 of ProtonMail) [1], [2].

```suggestion <p>ProtonMail has <a href="https://protonmail.com/blog/zero-access-encryption">zero access encryption at rest</a>, which means they cannot decrypt emails that you have previously received. Additionally, ProtonMail supports searching encrypted emails. To use this feature you must use their webmail, email client or bridge software to view your email.</p> ``` > To use this feature you must use their webmail Literally up above you said this was not possible with their webmail: > The webmail and mobile apps can only search To:, From: and Date: (this is subject to change in v4.0 of ProtonMail) [1], [2].
    <p>ProtonMail has <a href="https://protonmail.com/support/knowledge-base/how-to-use-pgp">integrated PGP encryption</a> in their webmail. Emails to other ProtonMail users are encrypted automatically, and encryption to non-ProtonMail users with a PGP key can be enabled easily in your account settings.</p>

Should this be clarified?

```suggestion <p>ProtonMail has <a href="https://protonmail.com/support/knowledge-base/how-to-use-pgp">integrated PGP encryption</a> in their webmail. Emails to other ProtonMail users are encrypted automatically, and encryption to non-ProtonMail users with a PGP key can be enabled easily in your account settings.</p> ``` Should this be clarified?

Edit Actually I'd do this and not link to them in this case:

    <p>ProtonMail supports the discovery of public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>. This allows users outside of ProtonMail to find the PGP keys of ProtonMail users easily, for cross-provider E2EE.</p>

    <p>ProtonMail <a href="https://protonmail.com/blog/security-updates-2019">supports</a> the discovery of their users' public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>.</p>

or...

    <p>ProtonMail <a href="https://protonmail.com/blog/security-updates-2019">supports</a> the discovery of public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>. This allows users outside of ProtonMail to find the PGP keys of ProtonMail users easily, for cross-provider E2EE.</p>

Either way, PTIO is not a press release platform. We are listing facts, not announcements. Which is not a huge difference in wording I guess, but IMHO wording like "announced" implies that we are just relaying whatever the providers publish, I think...

**Edit** *Actually* I'd do this and not link to them in this case: ```suggestion <p>ProtonMail supports the discovery of public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>. This allows users outside of ProtonMail to find the PGP keys of ProtonMail users easily, for cross-provider E2EE.</p> ``` --- ```suggestion <p>ProtonMail <a href="https://protonmail.com/blog/security-updates-2019">supports</a> the discovery of their users' public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>.</p> ``` or... ```suggestion <p>ProtonMail <a href="https://protonmail.com/blog/security-updates-2019">supports</a> the discovery of public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>. This allows users outside of ProtonMail to find the PGP keys of ProtonMail users easily, for cross-provider E2EE.</p> ``` Either way, PTIO is not a press release platform. We are listing facts, not announcements. Which is not a huge difference in wording I guess, but *IMHO* wording like "announced" implies that we are just relaying whatever the providers publish, I think...
    <p>ProtonMail allows you to <a href="https://protonmail.com/support/knowledge-base/encrypt-for-outside-users">encrypt messages to non-ProtonMail users</a> without the need for them to sign up for a ProtonMail account or use software like PGP.</p>
```suggestion <p>ProtonMail allows you to <a href="https://protonmail.com/support/knowledge-base/encrypt-for-outside-users">encrypt messages to non-ProtonMail users</a> without the need for them to sign up for a ProtonMail account or use software like PGP.</p> ```

Is this enabled by default? If so:

    <p>ProtonMail encrypts your <a href="https://protonmail.com/blog/encrypted-contacts-manager">address book contacts</a> and <a href="https://protonmail.com/blog/protoncalendar-security-model">calendars</a> with zero-access encryption, meaning they are only readable by you.</p>

If not,

    <p>ProtonMail allows you to encrypt your <a href="https://protonmail.com/blog/encrypted-contacts-manager">address book contacts</a> and <a href="https://protonmail.com/blog/protoncalendar-security-model">calendars</a> with zero-access encryption, meaning they are only readable by you..</p>
Is this enabled by default? If so: ```suggestion <p>ProtonMail encrypts your <a href="https://protonmail.com/blog/encrypted-contacts-manager">address book contacts</a> and <a href="https://protonmail.com/blog/protoncalendar-security-model">calendars</a> with zero-access encryption, meaning they are only readable by you.</p> ``` If not, ```suggestion <p>ProtonMail allows you to encrypt your <a href="https://protonmail.com/blog/encrypted-contacts-manager">address book contacts</a> and <a href="https://protonmail.com/blog/protoncalendar-security-model">calendars</a> with zero-access encryption, meaning they are only readable by you..</p> ```
    ProtonMail is accessible via Tor at <a href="https://protonirockerxow.onion/">protonirockerxow.onion</a>.

https://protonirockerxow.onion/

Can't check Tor currently, do they have an EV certificate for their onion domain?

```suggestion ProtonMail is accessible via Tor at <a href="https://protonirockerxow.onion/">protonirockerxow.onion</a>. ``` > https://protonirockerxow.onion/ Can't check Tor currently, do they have an EV certificate for their onion domain?
    <p>ProtonMail offers a "Visionary" account for €24/Month, which also enables access to ProtonVPN in addition to providing multiple accounts, domains, aliases, and extra storage.</p>
```suggestion <p>ProtonMail offers a "Visionary" account for €24/Month, which also enables access to ProtonVPN in addition to providing multiple accounts, domains, aliases, and extra storage.</p> ```
    <p><strong><a href="https://mailbox.org">Mailbox.org</a></strong> is an email service with a focus on being secure, ad-free, and privately powered by 100% eco-friendly energy. They have been in operation since <strong>2014</strong>. Mailbox.org is based in Berlin, <span class="flag-icon flag-icon-de"></span> Germany. Accounts start with 2 GB of storage, which can be upgraded as needed.
```suggestion <p><strong><a href="https://mailbox.org">Mailbox.org</a></strong> is an email service with a focus on being secure, ad-free, and privately powered by 100% eco-friendly energy. They have been in operation since <strong>2014</strong>. Mailbox.org is based in Berlin, <span class="flag-icon flag-icon-de"></span> Germany. Accounts start with 2 GB of storage, which can be upgraded as needed. ```
    <p>Mailbox.org doesn't accept Bitcoin or any other cryptocurrencies as a result of their payment processor BitPay suspending operations in Germany. However, they do accept <strong>Cash by mail</strong>, <strong>cash payment to bank account</strong>, bank transfer, credit card, PayPal and couple of German-specific processors: paydirekt and Sofort.</p>
```suggestion <p>Mailbox.org doesn't accept Bitcoin or any other cryptocurrencies as a result of their payment processor BitPay suspending operations in Germany. However, they do accept <strong>Cash by mail</strong>, <strong>cash payment to bank account</strong>, bank transfer, credit card, PayPal and couple of German-specific processors: paydirekt and Sofort.</p> ```
    <p>Mailbox.org supports <a href="https://kb.mailbox.org/display/MBOKBEN/How+to+use+two-factor+authentication+-+2FA">two factor authentication</a> for their webmail only. You can use either <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a> or a <a href="https://en.wikipedia.org/wiki/Universal_2nd_Factor">U2F</a> security key.</p>
```suggestion <p>Mailbox.org supports <a href="https://kb.mailbox.org/display/MBOKBEN/How+to+use+two-factor+authentication+-+2FA">two factor authentication</a> for their webmail only. You can use either <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a> or a <a href="https://en.wikipedia.org/wiki/Universal_2nd_Factor">U2F</a> security key.</p> ```
    <p>Mailbox.org has <a href="https://kb.mailbox.org/display/MBOKBEN/Send+encrypted+e-mails+with+Guard">integrated E2EE encryption</a> in their webmail, which simplifies sending messages to users with public PGP keys.</p>
```suggestion <p>Mailbox.org has <a href="https://kb.mailbox.org/display/MBOKBEN/Send+encrypted+e-mails+with+Guard">integrated E2EE encryption</a> in their webmail, which simplifies sending messages to users with public PGP keys.</p> ```
    <p>Mailbox.org supports the discovery of public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>. This allows users outside of Mailbox.org to find the PGP keys of Mailbox.org users easily, for cross-provider E2EE.</p>

see: protonmail wkd suggestion

```suggestion <p>Mailbox.org supports the discovery of public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>. This allows users outside of Mailbox.org to find the PGP keys of Mailbox.org users easily, for cross-provider E2EE.</p> ``` see: protonmail wkd suggestion
    <p><a href="https://en.wikipedia.org/wiki/Open-Xchange">Open-Exchange</a>, the software platform used by Mailbox.org, <a href="https://kb.mailbox.org/display/BMBOKBEN/Encryption+of+calendar+and+address+book">does not support</a> the encryption of your address book and calendar. A <a href="/software/calendar-contacts/">standalone option</a> may be more appropriate.</p>
```suggestion <p><a href="https://en.wikipedia.org/wiki/Open-Xchange">Open-Exchange</a>, the software platform used by Mailbox.org, <a href="https://kb.mailbox.org/display/BMBOKBEN/Encryption+of+calendar+and+address+book">does not support</a> the encryption of your address book and calendar. A <a href="/software/calendar-contacts/">standalone option</a> may be more appropriate.</p> ```
    <p>You can access your Mailbox.org account via IMAP/SMTP using <a href="https://kb.mailbox.org/display/MBOKBEN/The+Tor+exit+node+of+mailbox.org">their Tor hidden service</a>. However, their webmail interface cannot be accessed via their hidden service, and users may experience SSL certificate errors.</p>
```suggestion <p>You can access your Mailbox.org account via IMAP/SMTP using <a href="https://kb.mailbox.org/display/MBOKBEN/The+Tor+exit+node+of+mailbox.org">their Tor hidden service</a>. However, their webmail interface cannot be accessed via their hidden service, and users may experience SSL certificate errors.</p> ```
    <p>All accounts come with limited cloud storage that <a href="https://kb.mailbox.org/display/MBOKBEN/Encrypt+files+on+your+Drive">can be encrypted</a>. Mailbox.org also offers the alias <a href="https://kb.mailbox.org/display/MBOKBEN/Ensuring+E-Mails+are+Sent+Securely">@secure.mailbox.org</a>, which enforces the TLS encryption on the connection between mail servers, otherwise the message will not be sent at all.</p>

is this suggestion factually accurate?

```suggestion <p>All accounts come with limited cloud storage that <a href="https://kb.mailbox.org/display/MBOKBEN/Encrypt+files+on+your+Drive">can be encrypted</a>. Mailbox.org also offers the alias <a href="https://kb.mailbox.org/display/MBOKBEN/Ensuring+E-Mails+are+Sent+Securely">@secure.mailbox.org</a>, which enforces the TLS encryption on the connection between mail servers, otherwise the message will not be sent at all.</p> ``` is this suggestion factually accurate?

How the heck would this be true? lol

How the heck would this be true? lol
    <p>Posteo supports <a href="https://posteo.de/en/help/what-is-two-factor-authentication-and-how-do-i-set-it-up">two factor authentication</a> for their webmail only. You can use either <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a> or <a href="https://en.wikipedia.org/wiki/Universal_2nd_Factor">U2F</a> security key.</p>
```suggestion <p>Posteo supports <a href="https://posteo.de/en/help/what-is-two-factor-authentication-and-how-do-i-set-it-up">two factor authentication</a> for their webmail only. You can use either <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a> or <a href="https://en.wikipedia.org/wiki/Universal_2nd_Factor">U2F</a> security key.</p> ```
    <p>Posteo has <a href="https://posteo.de/en/site/encryption#pgp_webmailer">integrated encryption</a> in their webmail, which simplifies sending messages to users with public PGP keys.</p>
```suggestion <p>Posteo has <a href="https://posteo.de/en/site/encryption#pgp_webmailer">integrated encryption</a> in their webmail, which simplifies sending messages to users with public PGP keys.</p> ```
    <p>Posteo supports the discovery of public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>.</p>
```suggestion <p>Posteo supports the discovery of public keys via HTTP from their <a href="https://wiki.gnupg.org/WKD">Web Key Directory (WKD)</a>.</p> ```

Do they enable their server-side encryption by default?

    <p>Posteo encrypts your address book and calendars at rest. Posteo uses standard <a href="https://en.wikipedia.org/wiki/CalDAV">CalDAV</a> and <a href="https://en.wikipedia.org/wiki/CardDAV">CardDAV</a> protocols for calendars and contacts, which do not support E2EE. A <a href="/software/calendar-contacts/">standalone option</a> may be more appropriate.</p>

You can centrally encrypt your Posteo address book (with AES) and thereby use it securely on all devices. It is encrypted with your password – then even we have no access to your data.

How does this work then

Do they enable their server-side encryption by default? ```suggestion <p>Posteo encrypts your address book and calendars at rest. Posteo uses standard <a href="https://en.wikipedia.org/wiki/CalDAV">CalDAV</a> and <a href="https://en.wikipedia.org/wiki/CardDAV">CardDAV</a> protocols for calendars and contacts, which do not support E2EE. A <a href="/software/calendar-contacts/">standalone option</a> may be more appropriate.</p> ``` > You can centrally encrypt your Posteo address book (with AES) and thereby use it securely on all devices. It is encrypted with your password – then even we have no access to your data. How does this work then
    <p>Soverin accepts <strong>Bitcoin</strong> in addition to credit/debit cards and PayPal.</p>
```suggestion <p>Soverin accepts <strong>Bitcoin</strong> in addition to credit/debit cards and PayPal.</p> ```
    <p>Soverin supports <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a> two factor authentication <a href="https://support.soverin.net/hc/en-us/articles/360008819553-Setting-up-2-Factor-Authentication-2FA-Webmail-only">for webmail only</a>. They do not allow <a href="https://en.wikipedia.org/wiki/Universal_2nd_Factor">U2F</a> security key authentication.</p>
```suggestion <p>Soverin supports <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a> two factor authentication <a href="https://support.soverin.net/hc/en-us/articles/360008819553-Setting-up-2-Factor-Authentication-2FA-Webmail-only">for webmail only</a>. They do not allow <a href="https://en.wikipedia.org/wiki/Universal_2nd_Factor">U2F</a> security key authentication.</p> ```
    <p>Soverin uses standard <a href="https://en.wikipedia.org/wiki/CalDAV">CalDAV</a> and <a href="https://en.wikipedia.org/wiki/CardDAV">CardDAV</a> protocols for calendars and contacts, which do not support E2EE. A <a href="/software/calendar-contacts/">standalone option</a> may be more appropriate.</p>
```suggestion <p>Soverin uses standard <a href="https://en.wikipedia.org/wiki/CalDAV">CalDAV</a> and <a href="https://en.wikipedia.org/wiki/CardDAV">CardDAV</a> protocols for calendars and contacts, which do not support E2EE. A <a href="/software/calendar-contacts/">standalone option</a> may be more appropriate.</p> ```
    <p>Disroot supports <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a> two factor authentication for webmail only. They do not allow <a href="https://en.wikipedia.org/wiki/Universal_2nd_Factor">U2F</a> security key authentication.</p>
```suggestion <p>Disroot supports <a href="https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm">TOTP</a> two factor authentication for webmail only. They do not allow <a href="https://en.wikipedia.org/wiki/Universal_2nd_Factor">U2F</a> security key authentication.</p> ```

For Soverin we said:

However it doesn't appear to be "zero access", meaning it is technically possible for them to decrypt the data they have

Is this also true here?

    <p>Disroot uses full disk encryption. However, it doesn't appear to be "zero access", meaning it is technically possible for them to decrypt the data they have</p>

Otherwise if it is zero-access we should state that as well.

For Soverin we said: > However it doesn't appear to be "zero access", meaning it is technically possible for them to decrypt the data they have Is this also true here? ```suggestion <p>Disroot uses full disk encryption. However, it doesn't appear to be "zero access", meaning it is technically possible for them to decrypt the data they have</p> ``` Otherwise if it is zero-access we should state that as well.
    <p>Disroot uses standard <a href="https://en.wikipedia.org/wiki/CalDAV">CalDAV</a> and <a href="https://en.wikipedia.org/wiki/CardDAV">CardDAV</a> protocols for calendars and contacts, which do not support E2EE. A <a href="/software/calendar-contacts/">standalone option</a> may be more appropriate.</p>
```suggestion <p>Disroot uses standard <a href="https://en.wikipedia.org/wiki/CalDAV">CalDAV</a> and <a href="https://en.wikipedia.org/wiki/CardDAV">CardDAV</a> protocols for calendars and contacts, which do not support E2EE. A <a href="/software/calendar-contacts/">standalone option</a> may be more appropriate.</p> ```
      <p class="card-text text-secondary">Rather than use email for prolonged conversations, consider using a medium that does support Forward secrecy.</p>
```suggestion <p class="card-text text-secondary">Rather than use email for prolonged conversations, consider using a medium that does support Forward secrecy.</p> ```
title: "Private Email Providers"
```suggestion title: "Private Email Providers" ```
      <p>Operating outside the five/nine/fourteen-eyes countries is not necessarily a guarantee of privacy, and there are other factors to consider. However, we believe that avoiding these countries is important if you wish to avoid mass government dragnet surveillance, especially from the United States. Read our page on <a href="/providers/#ukusa">global mass surveillance and avoiding the US and UK</a> to learn more about why we feel this is important.</p>
```suggestion <p>Operating outside the five/nine/fourteen-eyes countries is not necessarily a guarantee of privacy, and there are other factors to consider. However, we believe that avoiding these countries is important if you wish to avoid mass government dragnet surveillance, especially from the United States. Read our page on <a href="/providers/#ukusa">global mass surveillance and avoiding the US and UK</a> to learn more about why we feel this is important.</p> ```
@ -5,14 +5,7 @@ title: "Email Clients"
description: "Discover free, open-source, and secure email clients, along with some email alternatives you may not have considered."
---

This warning needs to match. And if they are duplicates maybe the warning card should be in a separate file and included.

This warning needs to match. And if they are duplicates maybe the warning card should be in a separate file and included.
dngray (Migrated from github.com) reviewed 2020-02-14 16:56:54 +00:00
dngray (Migrated from github.com) commented 2020-02-14 16:56:54 +00:00

This came up in this discussion https://github.com/privacytoolsIO/privacytools.io/pull/1672#discussion_r375518463 apparently you're going to be able to search the body of email in webmail with the release of V4

This came up in this discussion https://github.com/privacytoolsIO/privacytools.io/pull/1672#discussion_r375518463 apparently you're going to be able to search the body of email in webmail with the release of V4
dngray (Migrated from github.com) reviewed 2020-02-14 16:58:00 +00:00
dngray (Migrated from github.com) commented 2020-02-14 16:57:59 +00:00

PTIO is not a press release platform

Fair point.

> PTIO is not a press release platform Fair point.
fm (Migrated from github.com) reviewed 2020-02-14 17:04:45 +00:00
fm (Migrated from github.com) commented 2020-02-14 17:04:45 +00:00

It is and you can't disable it. Only the contact name and email address are not encrypted, but they are digitally signed to prevent tampering of the record

It is and you can't disable it. Only the contact name and email address are *not* encrypted, but they are digitally signed to prevent tampering of the record
fm (Migrated from github.com) reviewed 2020-02-14 17:06:08 +00:00
fm (Migrated from github.com) commented 2020-02-14 17:06:08 +00:00

I think @JonahAragon means it's inconsistent. One says it can be done in webmail, the other says it can't.

I think @JonahAragon means it's inconsistent. One says it can be done in webmail, the other says it can't.
dngray (Migrated from github.com) reviewed 2020-02-14 17:15:55 +00:00
dngray (Migrated from github.com) commented 2020-02-14 17:15:55 +00:00

Yes they do:

$ openssl s_client -proxy 127.0.0.1:8123 -connect protonirockerxow.onion:443 
CONNECTED(00000003)
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA
verify return:1
depth=0 businessCategory = Private Organization, jurisdictionC = CH, jurisdictionST = Gen\C3\A8ve, serialNumber = CHE-354.686.492, C = CH, L = Gen\C3\A8ve, O = Proton Technologies AG, CN = protonirockerxow.onion
verify return:1
---
Certificate chain
 0 s:businessCategory = Private Organization, jurisdictionC = CH, jurisdictionST = Gen\C3\A8ve, serialNumber = CHE-354.686.492, C = CH, L = Gen\C3\A8ve, O = Proton Technologies AG, CN = protonirockerxow.onion
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA
 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIIRjCCBy6gAwIBAgIQBbCW0A+yDQfuHkeI1J5VTjANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE5MDQxNjAwMDAwMFoXDTIwMDQyMzEy
MDAwMFowgckxHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAkNIMRgwFgYLKwYBBAGCNzwCAQIMB0dlbsOodmUxGDAWBgNVBAUT
D0NIRS0zNTQuNjg2LjQ5MjELMAkGA1UEBhMCQ0gxEDAOBgNVBAcMB0dlbsOodmUx
HzAdBgNVBAoTFlByb3RvbiBUZWNobm9sb2dpZXMgQUcxHzAdBgNVBAMTFnByb3Rv
bmlyb2NrZXJ4b3cub25pb24wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQC497Gv7UPQ4okOvLIP6FwN/C3Fj2VMAGRJs19EmUZG0kUooOldowbAsppcpx2E
XDA9FolQ5mXg+7GcYLpj4yfNMRWcLXTrec0esv2sGUzKnAl9jUTjPcD7Z6X6SG1P
qqiGng4NwRq3PswEoqSN8UnUPqUZFZQw/ZAPRs7RKlJqvhtgO+YKG0v6CV/sHo9D
5tjhqWAl63NH3RA40dNvPmsJ+wOOsK/5M3lNvzE7tsn8Ag9FavyGrtFPlhx6KQDN
i4N3jezX3Snx4bpQZC1smgiuObkr8B3jc9zjHE1GIMDs2Gwe1fa3RTYcuh21tdFV
qz7xjL9Ij5WsIYf2DA1LBg41aniv9WaA/bKEnNU22daGguniJRVd9RFQsw6/FzOS
zNAJdZcX3bz3hdnwmN/DEwZb2x943jX9YWAsUmtBfV5tBT7eBy4glEEfzr6XWmFq
MDzkCxbEdKjgS7ozey5xbKzGZEE75SjUOV7SG5ygQgC4nuRGrNEEasFBg2oGIRAk
CA0ooSzaW0T4p2oDhRP826UjhSvxPMRv5rel81fWEpqNbRuVsmHISVhhjfKXg0G9
jZbRLwpRSaV2TriLp0PeGAiBYhawWXZWXl6J5Cn+v6alCLhkDMPKUEppBbKOhAnW
BVQKs4uO8ZcK6JKPckOAn14wIjvPmYhGXyLC7NabUEcWCwIDAQABo4IDezCCA3cw
HwYDVR0jBBgwFoAUPdNQpdagre7zSmAKZdMh1Pj41g8wHQYDVR0OBBYEFO/0gm4h
5cbyeBxeXZskbAJO4+OHMEAGA1UdEQQ5MDeCFnByb3Rvbmlyb2NrZXJ4b3cub25p
b26CDXByb3Rvbm1haWwuY2iCDnByb3Rvbm1haWwuY29tMA4GA1UdDwEB/wQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4wbDA0oDKg
MIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcyLmNy
bDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVy
LWcyLmNybDBLBgNVHSAERDBCMDcGCWCGSAGG/WwCATAqMCgGCCsGAQUFBwIBFhxo
dHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAcGBWeBDAEBMIGIBggrBgEFBQcB
AQR8MHowJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBSBggr
BgEFBQcwAoZGaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB
MkV4dGVuZGVkVmFsaWRhdGlvblNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMF8G
BWeBDAEfBFYwVDBSDB5odHRwczovL3Byb3Rvbmlyb2NrZXJ4b3cub25pb24wDQYJ
YIZIAWUDBAIBBQADIQDxZhALBbM1N1ai+bAWLx9HEq45wsx9mJDFhLmCU0lKrDCC
AQQGCisGAQQB1nkCBAIEgfUEgfIA8AB3ALvZ37wfinG1k5Qjl6qSe0c4V5UKq1Lo
GpCWZDaOHtGFAAABaifil64AAAQDAEgwRgIhALbiAN2dfVyHodwdoPSTWS1L+eDp
pDMWoih8sb9jwRnCAiEAq8w8TxaJzl7Apgt9AOGVawmoE+UH/CiOGGCe3PcgYMsA
dQBWFAaaL9fC7NP14b1Esj7HRna5vJkRXMDvlJhV1onQ3QAAAWon4pglAAAEAwBG
MEQCIDWzvpHyiWew+xz1wcjshHONrnu0rc0KPB+DqBHrWH69AiAfi79hFf+rYWKY
VqYpumkm5vgUiQG9nUD5Zmpup5j5GDANBgkqhkiG9w0BAQsFAAOCAQEAfXCED+4Y
G73/R9raLhstpyPL6Vv0w+lBU6/U/rsSe5P04Za4MvcXA09P0rCzlmIXNqCWRFNv
LGyoVK+QiS58ktTiH9gc2Awm0BNwHln1llabTc44kgeW0tS69lIXWHeLWHjBFKdb
8uLPN6Kbl4dGrwXfLHwiEaGWQypDi82pV+FEhcWHmO9dBZT4XQTjnMQTra2ooT+a
7T6J8k+Bru9Vit5khlaJMwm7BVQLGUdPuArwlb1HDx3f8K+4UKvz/ccEClEhWYEV
LeOIRmRmhZeIE3L9DEMI/btefIyjqgnbJMGKE8OfwArCbSqGcXyDJgnR54bqw7Mh
SboKM81WONW6dQ==
-----END CERTIFICATE-----
subject=businessCategory = Private Organization, jurisdictionC = CH, jurisdictionST = Gen\C3\A8ve, serialNumber = CHE-354.686.492, C = CH, L = Gen\C3\A8ve, O = Proton Technologies AG, CN = protonirockerxow.onion

issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4184 bytes and written 420 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Yes they do: ``` $ openssl s_client -proxy 127.0.0.1:8123 -connect protonirockerxow.onion:443 CONNECTED(00000003) Can't use SSL_get_servername depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA verify return:1 depth=0 businessCategory = Private Organization, jurisdictionC = CH, jurisdictionST = Gen\C3\A8ve, serialNumber = CHE-354.686.492, C = CH, L = Gen\C3\A8ve, O = Proton Technologies AG, CN = protonirockerxow.onion verify return:1 --- Certificate chain 0 s:businessCategory = Private Organization, jurisdictionC = CH, jurisdictionST = Gen\C3\A8ve, serialNumber = CHE-354.686.492, C = CH, L = Gen\C3\A8ve, O = Proton Technologies AG, CN = protonirockerxow.onion i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA 1 s:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIIIRjCCBy6gAwIBAgIQBbCW0A+yDQfuHkeI1J5VTjANBgkqhkiG9w0BAQsFADB1 MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE5MDQxNjAwMDAwMFoXDTIwMDQyMzEy MDAwMFowgckxHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB BAGCNzwCAQMTAkNIMRgwFgYLKwYBBAGCNzwCAQIMB0dlbsOodmUxGDAWBgNVBAUT D0NIRS0zNTQuNjg2LjQ5MjELMAkGA1UEBhMCQ0gxEDAOBgNVBAcMB0dlbsOodmUx HzAdBgNVBAoTFlByb3RvbiBUZWNobm9sb2dpZXMgQUcxHzAdBgNVBAMTFnByb3Rv bmlyb2NrZXJ4b3cub25pb24wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQC497Gv7UPQ4okOvLIP6FwN/C3Fj2VMAGRJs19EmUZG0kUooOldowbAsppcpx2E XDA9FolQ5mXg+7GcYLpj4yfNMRWcLXTrec0esv2sGUzKnAl9jUTjPcD7Z6X6SG1P qqiGng4NwRq3PswEoqSN8UnUPqUZFZQw/ZAPRs7RKlJqvhtgO+YKG0v6CV/sHo9D 5tjhqWAl63NH3RA40dNvPmsJ+wOOsK/5M3lNvzE7tsn8Ag9FavyGrtFPlhx6KQDN i4N3jezX3Snx4bpQZC1smgiuObkr8B3jc9zjHE1GIMDs2Gwe1fa3RTYcuh21tdFV qz7xjL9Ij5WsIYf2DA1LBg41aniv9WaA/bKEnNU22daGguniJRVd9RFQsw6/FzOS zNAJdZcX3bz3hdnwmN/DEwZb2x943jX9YWAsUmtBfV5tBT7eBy4glEEfzr6XWmFq MDzkCxbEdKjgS7ozey5xbKzGZEE75SjUOV7SG5ygQgC4nuRGrNEEasFBg2oGIRAk CA0ooSzaW0T4p2oDhRP826UjhSvxPMRv5rel81fWEpqNbRuVsmHISVhhjfKXg0G9 jZbRLwpRSaV2TriLp0PeGAiBYhawWXZWXl6J5Cn+v6alCLhkDMPKUEppBbKOhAnW BVQKs4uO8ZcK6JKPckOAn14wIjvPmYhGXyLC7NabUEcWCwIDAQABo4IDezCCA3cw HwYDVR0jBBgwFoAUPdNQpdagre7zSmAKZdMh1Pj41g8wHQYDVR0OBBYEFO/0gm4h 5cbyeBxeXZskbAJO4+OHMEAGA1UdEQQ5MDeCFnByb3Rvbmlyb2NrZXJ4b3cub25p b26CDXByb3Rvbm1haWwuY2iCDnByb3Rvbm1haWwuY29tMA4GA1UdDwEB/wQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwdQYDVR0fBG4wbDA0oDKg MIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVyLWcyLmNy bDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNlcnQuY29tL3NoYTItZXYtc2VydmVy LWcyLmNybDBLBgNVHSAERDBCMDcGCWCGSAGG/WwCATAqMCgGCCsGAQUFBwIBFhxo dHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMAcGBWeBDAEBMIGIBggrBgEFBQcB AQR8MHowJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBSBggr BgEFBQcwAoZGaHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkV4dGVuZGVkVmFsaWRhdGlvblNlcnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMF8G BWeBDAEfBFYwVDBSDB5odHRwczovL3Byb3Rvbmlyb2NrZXJ4b3cub25pb24wDQYJ YIZIAWUDBAIBBQADIQDxZhALBbM1N1ai+bAWLx9HEq45wsx9mJDFhLmCU0lKrDCC AQQGCisGAQQB1nkCBAIEgfUEgfIA8AB3ALvZ37wfinG1k5Qjl6qSe0c4V5UKq1Lo GpCWZDaOHtGFAAABaifil64AAAQDAEgwRgIhALbiAN2dfVyHodwdoPSTWS1L+eDp pDMWoih8sb9jwRnCAiEAq8w8TxaJzl7Apgt9AOGVawmoE+UH/CiOGGCe3PcgYMsA dQBWFAaaL9fC7NP14b1Esj7HRna5vJkRXMDvlJhV1onQ3QAAAWon4pglAAAEAwBG MEQCIDWzvpHyiWew+xz1wcjshHONrnu0rc0KPB+DqBHrWH69AiAfi79hFf+rYWKY VqYpumkm5vgUiQG9nUD5Zmpup5j5GDANBgkqhkiG9w0BAQsFAAOCAQEAfXCED+4Y G73/R9raLhstpyPL6Vv0w+lBU6/U/rsSe5P04Za4MvcXA09P0rCzlmIXNqCWRFNv LGyoVK+QiS58ktTiH9gc2Awm0BNwHln1llabTc44kgeW0tS69lIXWHeLWHjBFKdb 8uLPN6Kbl4dGrwXfLHwiEaGWQypDi82pV+FEhcWHmO9dBZT4XQTjnMQTra2ooT+a 7T6J8k+Bru9Vit5khlaJMwm7BVQLGUdPuArwlb1HDx3f8K+4UKvz/ccEClEhWYEV LeOIRmRmhZeIE3L9DEMI/btefIyjqgnbJMGKE8OfwArCbSqGcXyDJgnR54bqw7Mh SboKM81WONW6dQ== -----END CERTIFICATE----- subject=businessCategory = Private Organization, jurisdictionC = CH, jurisdictionST = Gen\C3\A8ve, serialNumber = CHE-354.686.492, C = CH, L = Gen\C3\A8ve, O = Proton Technologies AG, CN = protonirockerxow.onion issuer=C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 Extended Validation Server CA --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 4184 bytes and written 420 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- ```
fm (Migrated from github.com) reviewed 2020-02-14 17:16:00 +00:00
fm (Migrated from github.com) commented 2020-02-14 17:16:00 +00:00

Should we mention their TOTP implementation is a Roundcube plugin, hence why IMAP/SMTP is not protected?

Should we mention their TOTP implementation is a Roundcube plugin, hence why IMAP/SMTP is not protected?
dngray (Migrated from github.com) reviewed 2020-02-14 17:21:39 +00:00
dngray (Migrated from github.com) commented 2020-02-14 17:21:39 +00:00

https://posteo.de/en/site/faq

Credit is always added to your Posteo account anonymously – regardless of whether you pay by bank transfer, PayPal, credit card or in cash. We do not attach the data we receive with payments to the email accounts. We developed our own system for this in 2009, with which all payment processes are anonymised.
The payment system is the core of our concept of data reduction, above all, because we keep payment information strictly separate from our customers' email accounts, we do not attach any user information to the accounts – and can thereby ensure the fundamentally anonymous use of our email service. You can find out in detail how the anonymisation of payment processes occurs at Posteo on our payment info page.

Would I trust it to be anonymous? No. If I was paying for something anonymously I'd probably use Bitcoin but make sure that those were not linked to me in any way whatsoever. Eg working online being paid in Bitcoin, tumblers and converting through shitcoins, and currencies like monero etc, nothing that ever comes in contact with a financial institution linked to my identity.

https://posteo.de/en/site/faq > Credit is always added to your Posteo account anonymously – regardless of whether you pay by bank transfer, PayPal, credit card or in cash. We do not attach the data we receive with payments to the email accounts. We developed our own system for this in 2009, with which **all payment processes are anonymised**. The payment system is the core of our concept of data reduction, above all, because we keep payment information strictly separate from our customers' email accounts, we do not attach any user information to the accounts – and can thereby ensure the fundamentally anonymous use of our email service. You can find out in detail how the anonymisation of payment processes occurs at Posteo on our [payment info page](https://posteo.de/en/site/payment). Would I trust it to be anonymous? No. If I was paying for something anonymously I'd probably use Bitcoin but make sure that those were not linked to me in any way whatsoever. Eg working online being paid in Bitcoin, tumblers and converting through shitcoins, and currencies like monero etc, nothing that ever comes in contact with a financial institution linked to my identity.
dngray (Migrated from github.com) reviewed 2020-02-14 17:23:54 +00:00
dngray (Migrated from github.com) commented 2020-02-14 17:23:54 +00:00

I think we should, because Disroot has the same issue.

The requirement for 2FA is only for webmail, we should be clearer on that. The assumption is that IMAP would be disabled, perhaps we should warn about that.

It only really fits a threat model where a user uses a lot of different devices they don't know the history of.

I think we should, because Disroot has the same issue. The requirement for 2FA is only for webmail, we should be clearer on that. The assumption is that IMAP would be disabled, perhaps we should warn about that. It only really fits a threat model where a user uses a lot of different devices they don't know the history of.
Mikaela (Migrated from github.com) reviewed 2020-02-14 22:56:52 +00:00
@ -28,0 +186,4 @@
<h3>How do I protect my private keys?</h3>
<p>A smartcard (such as a <a href="https://support.yubico.com/support/solutions/articles/15000006420-using-your-yubikey-with-openpgp">Yubikey</a> or <a href="https://www.nitrokey.com">Nitrokey</a>) works by receiving an encrypted email message from a device (phone, tablet, computer etc) running an email/webmail client. The message is then decrypted by the smartcard and the decrypted content is sent back to the device.</p>
<p>It is advantageous for the decryption to occur on the smartcard so as to avoid possibly exposing your private key to a compromised device.</p>
</div>
Mikaela (Migrated from github.com) commented 2020-02-14 22:56:52 +00:00

Would require research, but https://en.wikipedia.org/wiki/Electronic_identification may be a good start. It doesn't mention Finland (fully sure) or Estonia (not entirely sure, but I think so), while it does mention Belgium doing email signing.

I will not do more reviewing tonight.

Would require research, but https://en.wikipedia.org/wiki/Electronic_identification may be a good start. It doesn't mention Finland (fully sure) or Estonia (not entirely sure, but I think so), while it does mention Belgium doing email signing. I will not do more reviewing tonight.
dngray (Migrated from github.com) reviewed 2020-02-15 06:19:16 +00:00
dngray (Migrated from github.com) commented 2020-02-15 06:19:16 +00:00

I'm thinking we could just use a little sup number, and then anchor it at the bottom of the page like Wikipedia style?

I'm thinking we could just use a little sup number, and then anchor it at the bottom of the page like Wikipedia style?
dngray (Migrated from github.com) reviewed 2020-02-15 06:20:09 +00:00
dngray (Migrated from github.com) commented 2020-02-15 06:20:09 +00:00

Yes, I agree with this, it's okay to mention the Yubikey and Nitrokey in the criteria that way it's only one place we have to change it to a link when we do have a hardware section.

Yes, I agree with this, it's okay to mention the Yubikey and Nitrokey in the criteria that way it's only one place we have to change it to a link when we do have a hardware section.
dngray (Migrated from github.com) reviewed 2020-02-15 06:44:56 +00:00
dngray (Migrated from github.com) commented 2020-02-15 06:44:55 +00:00

Which part? the @secure.mailbox.org or the cloud storage part?

My understanding is that if you send an email to a user@secure.mailbox.org it uses explicit TLS, meaning that if the mailbox.org SMTP server cannot start a TLS connection, it won't send the email, as opposed to falling back to plaintext.

Your suggestion, does sound better and is accurate.

Which part? the @secure.mailbox.org or the cloud storage part? My understanding is that if you send an email to a user@secure.mailbox.org it uses explicit TLS, meaning that if the mailbox.org SMTP server cannot start a TLS connection, it won't send the email, as opposed to falling back to plaintext. Your suggestion, does sound better and is accurate.
dngray (Migrated from github.com) reviewed 2020-02-15 06:52:16 +00:00
dngray (Migrated from github.com) commented 2020-02-15 06:52:15 +00:00

See I don't think it is possible. If they're serving over CalDAV/CardDAV at the point which you request the data it must be decrypted (on their end) and then packaged up and sent over the HTTP request.

I fail to see how this is "zero access encryption" maybe they keep it encrypted with your password yes, but it's not zero access. They could simply wait for you to provide your password and then monitor outgoing traffic, which is comparatively different to E2EE where it's encrypted until it is decrypted on your device. Eg. Etesync.

See I don't think it is possible. If they're serving over CalDAV/CardDAV at the point which you request the data it must be decrypted (on their end) and then packaged up and sent over the HTTP request. I fail to see how this is "zero access encryption" maybe they keep it encrypted with your password yes, but it's not zero access. They could simply wait for you to provide your password and then monitor outgoing traffic, which is comparatively different to E2EE where it's encrypted until it is decrypted on your device. Eg. Etesync.
dngray (Migrated from github.com) reviewed 2020-02-15 07:04:25 +00:00
dngray (Migrated from github.com) commented 2020-02-15 07:04:25 +00:00

It's not zero access no. I am told they might be implementing a system that encrypts with your public key incoming email like Mailbox.org does so that's worth keeping an eye on.

It's not zero access no. I am told they might be implementing a system that encrypts with your public key incoming email like Mailbox.org does so that's worth keeping an eye on.
dngray (Migrated from github.com) reviewed 2020-02-15 07:13:39 +00:00
@ -5,14 +5,7 @@ title: "Email Clients"
description: "Discover free, open-source, and secure email clients, along with some email alternatives you may not have considered."
---
dngray (Migrated from github.com) commented 2020-02-15 07:13:39 +00:00

There is a duplicate in email software page, we should make this into a separate file.

There is a duplicate in email software page, we should make this into a separate file.
dngray (Migrated from github.com) reviewed 2020-02-15 07:32:02 +00:00
@ -5,14 +5,7 @@ title: "Email Clients"
description: "Discover free, open-source, and secure email clients, along with some email alternatives you may not have considered."
---
dngray (Migrated from github.com) commented 2020-02-15 07:32:02 +00:00

Fixed see 9ff3b08e01

Fixed see https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/9ff3b08e01cf671543d3349ec30de7abb704c4d8
dngray (Migrated from github.com) reviewed 2020-02-15 08:45:24 +00:00
dngray (Migrated from github.com) commented 2020-02-15 08:45:24 +00:00

Only posts I could find, and they weren't official:

So I might just take out the Q1/Q2 thing, it might take longer.

Only posts I could find, and they weren't official: - https://reddit.com/comments/etts37/comment/ffimrr6/ - https://reddit.com/comments/dtyg2p/comment/f72gbi9/ - https://reddit.com/comments/dd17j6/comment/f2eosb6/ So I might just take out the Q1/Q2 thing, it might take longer.
dngray (Migrated from github.com) reviewed 2020-02-15 08:59:11 +00:00
dngray (Migrated from github.com) commented 2020-02-15 08:59:10 +00:00

I think this has been resolved as of cbf2b09541 that way if it's late we don't have to update the page.

I think this has been resolved as of https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/cbf2b09541a889af4ec5d3bc85efd00cd61e4ebf that way if it's late we don't have to update the page.
dngray (Migrated from github.com) reviewed 2020-02-15 09:03:14 +00:00
@ -28,0 +186,4 @@
<h3>How do I protect my private keys?</h3>
<p>A smartcard (such as a <a href="https://support.yubico.com/support/solutions/articles/15000006420-using-your-yubikey-with-openpgp">Yubikey</a> or <a href="https://www.nitrokey.com">Nitrokey</a>) works by receiving an encrypted email message from a device (phone, tablet, computer etc) running an email/webmail client. The message is then decrypted by the smartcard and the decrypted content is sent back to the device.</p>
<p>It is advantageous for the decryption to occur on the smartcard so as to avoid possibly exposing your private key to a compromised device.</p>
</div>
dngray (Migrated from github.com) commented 2020-02-15 09:03:13 +00:00

I think we might not add this, the number of countries which create S/MIME certificates for their users has to be pretty low, and it's also not relevant to everyone else outside of those few countries.

I think we might not add this, the number of countries which create S/MIME certificates for their users has to be pretty low, and it's also not relevant to everyone else outside of those few countries.
dngray (Migrated from github.com) reviewed 2020-02-15 09:29:11 +00:00
dngray (Migrated from github.com) commented 2020-02-15 09:29:10 +00:00

@JonahAragon I've updated it to not use numerical references. The first one isn't made by an official protonmail account that's only /u/ProtonMail and /u/protonmail_support as far as I know. See 286d218fbb

@JonahAragon I've updated it to not use numerical references. The first one isn't made by an official protonmail account that's only /u/ProtonMail and /u/protonmail_support as far as I know. See https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/286d218fbb1a9623f742389f4c9cbb067b934b49
dngray (Migrated from github.com) reviewed 2020-02-15 09:35:49 +00:00
dngray (Migrated from github.com) commented 2020-02-15 09:35:48 +00:00

Oh, good catch, removed as I think we've well and truly covered that topic. b2f252939c

Oh, good catch, removed as I think we've well and truly covered that topic. https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/b2f252939c36366572f5d6b657590aabc65baf2f
dngray (Migrated from github.com) reviewed 2020-02-15 10:08:35 +00:00
@ -28,0 +186,4 @@
<h3>How do I protect my private keys?</h3>
<p>A smartcard (such as a <a href="https://support.yubico.com/support/solutions/articles/15000006420-using-your-yubikey-with-openpgp">Yubikey</a> or <a href="https://www.nitrokey.com">Nitrokey</a>) works by receiving an encrypted email message from a device (phone, tablet, computer etc) running an email/webmail client. The message is then decrypted by the smartcard and the decrypted content is sent back to the device.</p>
<p>It is advantageous for the decryption to occur on the smartcard so as to avoid possibly exposing your private key to a compromised device.</p>
</div>
dngray (Migrated from github.com) commented 2020-02-15 10:08:35 +00:00

After speaking with @blacklight447-ptio we decided this could be a good thing.

We won't do it for this PR, but I have opened https://github.com/privacytoolsIO/privacytools.io/issues/1710 in which we can do research and list countries which fit into this. That way this PR can be merged without further research required.

After speaking with @blacklight447-ptio we decided this could be a good thing. We won't do it for this PR, but I have opened https://github.com/privacytoolsIO/privacytools.io/issues/1710 in which we can do research and list countries which fit into this. That way this PR can be merged without further research required.
dngray commented 2020-02-15 17:13:15 +00:00 (Migrated from github.com)

Just a lil' bit more feedback

Much appreciated! also thanks, @fm @Mikaela !

I am thinking of also doing a summary matrix table, I've had 3 requests for that. What do you guys think? Something like #603 (comment) but for the features we list for each provider, so at a glance you can see what is supported.

So I've done this 1d457dbe38 how do you think it looks? hmm seems like we could remove a column.

> > Just a lil' bit more feedback > > Much appreciated! also thanks, @fm @Mikaela ! > > I am thinking of also doing a summary matrix table, I've had 3 requests for that. What do you guys think? Something like [#603 (comment)](https://github.com/privacytoolsIO/privacytools.io/issues/603#issuecomment-456400331) but for the features we list for each provider, so at a glance you can see what is supported. So I've done this https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/1d457dbe38452d6573ffc851baf4e2a2818baecc how do you think it looks? hmm seems like we could remove a column.
fm commented 2020-02-15 17:15:50 +00:00 (Migrated from github.com)

PM should be listed as Free, since you're listing the 500MB limit.

PM should be listed as _Free_, since you're listing the 500MB limit.
dngray commented 2020-02-15 17:25:48 +00:00 (Migrated from github.com)

PM should be listed as Free, since you're listing the 500MB limit.

We probably should do that.

I don't really like that table though, and think we might remove it, with the intention of adding that information to the wiki ie: https://wiki.privacytools.io/view/Comparison_of_VPN_providers

> PM should be listed as _Free_, since you're listing the 500MB limit. We probably should do that. I don't really like that table though, and think we might remove it, with the intention of adding that information to the wiki ie: https://wiki.privacytools.io/view/Comparison_of_VPN_providers
dngray commented 2020-02-16 10:58:28 +00:00 (Migrated from github.com)

PM should be listed as Free, since you're listing the 500MB limit.

We probably should do that.

I don't really like that table though, and think we might remove it, with the intention of adding that information to the wiki ie: https://wiki.privacytools.io/view/Comparison_of_VPN_providers

So I think the table on the privacytools.io page looks kinda ugly.

The one on the wiki is here https://wiki.privacytools.io/view/Comparison_of_email_providers#Provider_comparison at a glance it provides a better comparison.

> > PM should be listed as _Free_, since you're listing the 500MB limit. > > We probably should do that. > > I don't really like that table though, and think we might remove it, with the intention of adding that information to the wiki ie: https://wiki.privacytools.io/view/Comparison_of_VPN_providers So I think the table on the privacytools.io page looks kinda ugly. The one on the wiki is here https://wiki.privacytools.io/view/Comparison_of_email_providers#Provider_comparison at a glance it provides a better comparison.
fm commented 2020-02-27 14:05:54 +00:00 (Migrated from github.com)

Should the word EUR be removed from the pricing? The € sign is already there and looks redundant. I've been thinking about it every time I see it lately. Personally, I believe it looks cleaner, too.

Screen Shot 2020-02-27 at 9 05 04 AM Screen Shot 2020-02-27 at 9 05 25 AM
Should the word **EUR** be removed from the pricing? The € sign is already there and looks redundant. I've been thinking about it every time I see it lately. Personally, I believe it looks cleaner, too. <img width="531" alt="Screen Shot 2020-02-27 at 9 05 04 AM" src="https://user-images.githubusercontent.com/3654256/75452453-53fba080-5940-11ea-8fd0-4503f3fbb995.png"> <img width="390" alt="Screen Shot 2020-02-27 at 9 05 25 AM" src="https://user-images.githubusercontent.com/3654256/75452455-54943700-5940-11ea-859d-a7dfc4571688.png">
dngray commented 2020-02-27 16:23:11 +00:00 (Migrated from github.com)

Should the word EUR be removed from the pricing? The € sign is already there and looks redundant.

We could do this. What do people think? I think the reason it was there was a carryover from the VPN page where we have providers who list prices in USD.

> Should the word **EUR** be removed from the pricing? The € sign is already there and looks redundant. We could do this. What do people think? I think the reason it was there was a carryover from the VPN page where we have providers who list prices in USD.
nitrohorse (Migrated from github.com) reviewed 2020-02-27 16:31:55 +00:00
nitrohorse (Migrated from github.com) left a comment

LGTM 👍🏼

LGTM 👍🏼
jonah reviewed 2020-02-27 17:09:29 +00:00
    <h2 id="protonmail" class="anchor"><a href="#prtotonmail"><i class="fas fa-link anchor-icon"></i></a> ProtonMail <span class="badge badge-info">Free</span> or <span class="badge badge-secondary">€48/Year (Plus)</span></h2>
```suggestion <h2 id="protonmail" class="anchor"><a href="#prtotonmail"><i class="fas fa-link anchor-icon"></i></a> ProtonMail <span class="badge badge-info">Free</span> or <span class="badge badge-secondary">€48/Year (Plus)</span></h2> ```
    <h2 id="mailbox" class="anchor"><a href="#mailbox"><i class="fas fa-link anchor-icon"></i></a> Mailbox.org <span class="badge badge-info">€12/Year</span></h2>
```suggestion <h2 id="mailbox" class="anchor"><a href="#mailbox"><i class="fas fa-link anchor-icon"></i></a> Mailbox.org <span class="badge badge-info">€12/Year</span></h2> ```
    <h2 id="posteo" class="anchor"><a href="#posteo"><i class="fas fa-link anchor-icon"></i></a> Posteo <span class="badge badge-info">€12/Year</span></h2>
```suggestion <h2 id="posteo" class="anchor"><a href="#posteo"><i class="fas fa-link anchor-icon"></i></a> Posteo <span class="badge badge-info">€12/Year</span></h2> ```
    <h2 id="soverin" class="anchor"><a href="#soverin"><i class="fas fa-link anchor-icon"></i></a> Soverin <span class="badge badge-info">€29/Year</span></h2>
```suggestion <h2 id="soverin" class="anchor"><a href="#soverin"><i class="fas fa-link anchor-icon"></i></a> Soverin <span class="badge badge-info">€29/Year</span></h2> ```
fm (Migrated from github.com) reviewed 2020-02-27 17:13:40 +00:00
@ -24,0 +12,4 @@
src="/assets/img/svg/3rd-party/protonmail.svg"
height="70"
width="200"
class="img-fluid d-block mr-auto ml-auto align-middle"
fm (Migrated from github.com) commented 2020-02-27 17:13:40 +00:00

Quick correction. You can also search by Subject in web/mobile

Quick correction. You can also search by _Subject_ in web/mobile
jonah reviewed 2020-02-27 17:17:26 +00:00

IMHO we shouldn't list two prices for ProtonMail while only listing the lowest price for other providers. ProtonMail Free is a usable service as-is. Every other service provides additional storage and/or functionality for additional fees which we aren't listing here. Thoughts?

    <h2 id="protonmail" class="anchor"><a href="#prtotonmail"><i class="fas fa-link anchor-icon"></i></a> ProtonMail <span class="badge badge-info">Free</span></h2>
    <p><strong><a href="https://protonmail.com">ProtonMail.com</a></strong> is an email service with a focus on privacy, encryption, security, and ease of use. They have been in operation since <strong>2013</strong>. ProtonMail is based in Genève, <span class="flag-icon flag-icon-ch"></span> Switzerland. Accounts start with 500 MB storage with their free plan.</p>

    <p>Free accounts have some limitations and do not allow the use of the <a href="https://protonmail.com/bridge">ProtonMail Bridge</a>, which is required to use a <a href="/software/email">recommended email client</a> (eg. Thunderbird) or to search email by body text. Paid accounts are available starting at <strong>€48/Year</strong> which include features like ProtonMail Bridge, additional storage, custom domain support, and more. The webmail and mobile apps can only search <code>To:</code>, <code>From:</code> and <code>Date:</code> (this is subject to <a href="https://reddit.com/comments/cqwk2a/comment/ex21b4e">change in v4.0</a> of ProtonMail).</p>

    <h5><span class="badge badge-success">Domains and Aliases</span></h5>
    <p>Paid ProtonMail users can use their own domain with the service. <a href="https://protonmail.com/support/knowledge-base/catch-all/">Catch-all</a> addresses are supported with custom domains. ProtonMail also supports <a href="https://protonmail.com/support/knowledge-base/creating-aliases/">subaddressing</a>, which is useful for users who don't want to purchase a domain.</p>
IMHO we shouldn't list two prices for ProtonMail while only listing the lowest price for other providers. ProtonMail Free is a usable service as-is. Every other service provides additional storage and/or functionality for additional fees which we aren't listing here. Thoughts? ```suggestion <h2 id="protonmail" class="anchor"><a href="#prtotonmail"><i class="fas fa-link anchor-icon"></i></a> ProtonMail <span class="badge badge-info">Free</span></h2> <p><strong><a href="https://protonmail.com">ProtonMail.com</a></strong> is an email service with a focus on privacy, encryption, security, and ease of use. They have been in operation since <strong>2013</strong>. ProtonMail is based in Genève, <span class="flag-icon flag-icon-ch"></span> Switzerland. Accounts start with 500 MB storage with their free plan.</p> <p>Free accounts have some limitations and do not allow the use of the <a href="https://protonmail.com/bridge">ProtonMail Bridge</a>, which is required to use a <a href="/software/email">recommended email client</a> (eg. Thunderbird) or to search email by body text. Paid accounts are available starting at <strong>€48/Year</strong> which include features like ProtonMail Bridge, additional storage, custom domain support, and more. The webmail and mobile apps can only search <code>To:</code>, <code>From:</code> and <code>Date:</code> (this is subject to <a href="https://reddit.com/comments/cqwk2a/comment/ex21b4e">change in v4.0</a> of ProtonMail).</p> <h5><span class="badge badge-success">Domains and Aliases</span></h5> <p>Paid ProtonMail users can use their own domain with the service. <a href="https://protonmail.com/support/knowledge-base/catch-all/">Catch-all</a> addresses are supported with custom domains. ProtonMail also supports <a href="https://protonmail.com/support/knowledge-base/creating-aliases/">subaddressing</a>, which is useful for users who don't want to purchase a domain.</p> ```
fm (Migrated from github.com) reviewed 2020-02-27 17:18:34 +00:00
dngray (Migrated from github.com) reviewed 2020-02-28 02:48:03 +00:00
@ -24,0 +12,4 @@
src="/assets/img/svg/3rd-party/protonmail.svg"
height="70"
width="200"
class="img-fluid d-block mr-auto ml-auto align-middle"
dngray (Migrated from github.com) commented 2020-02-28 02:48:03 +00:00

We will be sure to reflect that, fixed in e22625deac

We will be sure to reflect that, fixed in https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/e22625deacc43c04279c423822d38afc336b25fd
dngray (Migrated from github.com) reviewed 2020-02-28 02:48:51 +00:00
dngray (Migrated from github.com) commented 2020-02-28 02:48:51 +00:00

Fair enough, as long as we mention that the bridge requires a paid account.

Fair enough, as long as we mention that the bridge requires a paid account.
jonah reviewed 2020-02-28 14:36:51 +00:00
nitrohorse (Migrated from github.com) reviewed 2020-02-28 17:16:39 +00:00
ghost commented 2020-02-29 07:26:48 +00:00 (Migrated from github.com)

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.

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 commented 2020-02-29 07:41:06 +00:00 (Migrated from github.com)

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.

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 commented 2020-02-29 12:34:31 +00:00 (Migrated from github.com)

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:

order_yubikey

You can then set the security level:

otp_security_level

And method:

otp_method

Or you can enroll a key that you purchased elsewhere:

key_enrollment

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 00d0021c78 . 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 c122bcb346

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: 2ebb28c05b

  • 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:

Added this requirement 27e0bf3cc3

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 c95fa40884

  • 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.

## 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](https://kb.mailbox.org/display/MBOKBEN/How+to+use+two-factor+authentication+-+2FA), customers can even choose to buy a Yubikey direct from Mailbox pre-enrolled: ![order_yubikey](https://user-images.githubusercontent.com/48640805/75607456-459fb700-5aef-11ea-9ce1-cd2f288cc2a8.png) You can then set the security level: ![otp_security_level](https://user-images.githubusercontent.com/48640805/75607466-5bad7780-5aef-11ea-98fa-1f57fe3fd091.png) And method: ![otp_method](https://user-images.githubusercontent.com/48640805/75607469-6cf68400-5aef-11ea-8517-3082c4281730.png) Or you can enroll a key that you purchased elsewhere: ![key_enrollment](https://user-images.githubusercontent.com/48640805/75607475-7ed82700-5aef-11ea-94f5-cca2ca7223eb.png) 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 https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/00d0021c78a925001e5bff520a6b4cef1f3b2847 . 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 https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/c122bcb34651753f4dd2525d1f46f332c20061d2 > 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: https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/2ebb28c05bdcac4f85a8618b557577ab261eb58b > - 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](https://protonmail.com/gdpr) - [Mailbox - Data Protection Policy in accordance with EU General Data Protection Regulation (GDPR)](https://mailbox.org/en/data-protection-privacy-policy) - [Posteo - Privacy policy](https://posteo.de/en/site/privacy_policy) - [Soverin](https://soverin.net/legal) - [Disroot - Privacy Policy](https://disroot.org/en/privacy_policy) Added this requirement https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/27e0bf3cc3ad106da0ccb23157071428e4f9ae28 ## 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 https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/c95fa408849a25cd2f9cba883cb565d692c3f7a6 > - 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 commented 2020-02-29 13:40:18 +00:00 (Migrated from github.com)

I've also decided to remove the base requirement on standard access protocols added in 3046548812 (diff-8cc7b2b0d78dd2501610391c086a8516R41) and b52f6b7b1e (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.

I've also decided to remove the base requirement on standard access protocols added in https://github.com/privacytoolsIO/privacytools.io/commit/3046548812748b8d4a7fb44b9a96364340c8a64b#diff-8cc7b2b0d78dd2501610391c086a8516R41 and https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/b52f6b7b1ebd6a98dcfa487b46853187eb41cdf8#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](https://en.wikipedia.org/wiki/End-to-end_encryption) 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](https://en.wikipedia.org/wiki/Cross-site_scripting) style attacks and crap implementations are valid, there are things that mitigate this, eg. strict [CSPs](https://en.wikipedia.org/wiki/Content_Security_Policy), well designed and reviewed code etc. The argument also doesn't consider browser plugins like [Mailvelope](https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia#Assistance_and_Access_Bill), or this [less dense summary](https://www.zdnet.com/article/whats-actually-in-australias-encryption-laws-everything-you-need-to-know/). 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](https://f-droid.org/en/docs/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](https://de.wikipedia.org/wiki/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](https://autoconfig.thunderbird.net/v1.1/gmail.com) is hit which mandates the login mechanism. It would be nice to see the [Autoconfiguration](https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/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](https://example.com/.well-known/autoconfig/mail/config-v1.1.xml) directory.
jonah reviewed 2020-02-29 15:50:56 +00:00

Worth also mentioning that they offer "secure contact forms" so that external users can send encrypted messages and attachments without needing a tuta account. However, it costs an extra €240/year 😳

Worth also mentioning that they offer "[secure contact forms](https://tutanota.com/secure-connect)" so that external users can send encrypted messages and attachments without needing a tuta account. However, it costs an extra €240/year 😳
dngray (Migrated from github.com) reviewed 2020-02-29 15:52:30 +00:00
dngray (Migrated from github.com) commented 2020-02-29 15:52:30 +00:00

Yeah that seems like it's for businesses. I had planned to add that down there, when I removed the link from the temporary inbox section (as its not the same thing).

Yeah that seems like it's for businesses. I had planned to add that down there, when I removed the link from the temporary inbox section (as its not the same thing).
jonah reviewed 2020-02-29 16:24:25 +00:00
@ -306,0 +224,4 @@
<p>Tutanota <a href="https://github.com/tutao/tutanota/issues/198">does have plans</a> to support <a href="https://autocrypt.org">AutoCrypt</a>. This would allow for external users to send encrypted emails to Tutanota users as long as their email client supports the AutoCrypt headers.</p>
<h5><span class="badge badge-danger">.onion Service</span></h5>
<p>Tutanota does not operate a .onion service but <a href="https://github.com/tutao/tutanota/issues/528">may consider</a> it in the future.</p>

Similar to https://github.com/privacytoolsIO/privacytools.io/pull/1672#discussion_r378930854

is encrypted E2EE

Is a bit redundant, I’d remove the encrypted so that it says is E2EE

Similar to https://github.com/privacytoolsIO/privacytools.io/pull/1672#discussion_r378930854 > is encrypted E2EE Is a bit redundant, I’d remove the _encrypted_ so that it says _is E2EE_
dngray (Migrated from github.com) reviewed 2020-02-29 16:25:46 +00:00
@ -306,0 +224,4 @@
<p>Tutanota <a href="https://github.com/tutao/tutanota/issues/198">does have plans</a> to support <a href="https://autocrypt.org">AutoCrypt</a>. This would allow for external users to send encrypted emails to Tutanota users as long as their email client supports the AutoCrypt headers.</p>
<h5><span class="badge badge-danger">.onion Service</span></h5>
<p>Tutanota does not operate a .onion service but <a href="https://github.com/tutao/tutanota/issues/528">may consider</a> it in the future.</p>
dngray (Migrated from github.com) commented 2020-02-29 16:25:46 +00:00

ugh yeah. lol.

ugh yeah. lol.
ghost commented 2020-02-29 16:38:51 +00:00 (Migrated from github.com)

Hate to be that guy

This ensures that customer contact to the business using E2EE.

Doesn’t really sound right, maybe switch it to uses or remove that

Hate to be _that_ guy > This ensures that customer contact to the business using E2EE. Doesn’t really sound right, maybe switch it to `uses` or remove `that`
dngray commented 2020-02-29 17:18:00 +00:00 (Migrated from github.com)

Hate to be that guy

This ensures that customer contact to the business using E2EE.

Doesn’t really sound right, maybe switch it to uses or remove that

You're right, and I am clearly tired.

> Hate to be _that_ guy > > > This ensures that customer contact to the business using E2EE. > > Doesn’t really sound right, maybe switch it to `uses` or remove `that` You're right, and I am clearly tired.
ghost commented 2020-02-29 18:01:54 +00:00 (Migrated from github.com)

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!)

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](https://userforum.mailbox.org/topic/unterst%C3%BCtzung-von-u2f-universal-second-factor-ger%C3%A4ten) and [WebAuthn](https://userforum.mailbox.org/topic/webauthn-support) 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 commented 2020-03-01 06:22:37 +00:00 (Migrated from github.com)

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 7d21d548a7 sound.

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

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. 7d407e92a2

> 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](https://userforum.mailbox.org/topic/unterst%C3%BCtzung-von-u2f-universal-second-factor-ger%C3%A4ten) and [WebAuthn](https://userforum.mailbox.org/topic/webauthn-support) support. Both requests are still open. So it seems that there is no support for U2F. Ah yes, you're right. How does https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/7d21d548a7d336cf3f0bd1064e9991e7a64d2640 sound. For record purposes, I've included a screenshot of the other options: ![other_options](https://user-images.githubusercontent.com/48640805/75620700-e3dd5c80-5b83-11ea-9004-05928bf57122.png) > > 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. https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/7d407e92a2c343f04e75ea4c2ea069009a470e8f
dngray commented 2020-03-01 06:34:47 +00:00 (Migrated from github.com)

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: 30eaec6f1a

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? ](https://posteo.de/en/help/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: https://github.com/privacytoolsIO/privacytools.io/pull/1672/commits/30eaec6f1a33a54bac8d9e224aa41e94d2288afa
blacklight447 (Migrated from github.com) reviewed 2020-03-01 10:59:22 +00:00
blacklight447 (Migrated from github.com) left a comment

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

Great work folks, im excited to finally launch the new page!
Mikaela (Migrated from github.com) reviewed 2020-03-01 11:23:39 +00:00
Mikaela (Migrated from github.com) left a comment

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

Reading through the preview (not code or checking that links work as Matrix gave me an impresssion of urgency) LGTM.
dngray commented 2020-03-01 11:31:00 +00:00 (Migrated from github.com)

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.

> 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 (Migrated from github.com) reviewed 2020-03-01 11:35:40 +00:00
Mikaela (Migrated from github.com) left a comment

I guess the svgs are still fine

I guess the svgs are still fine
blacklight447 (Migrated from github.com) reviewed 2020-03-01 11:37:26 +00:00
blacklight447 (Migrated from github.com) approved these changes 2020-03-01 12:01:57 +00:00
dawidpotocki (Migrated from github.com) approved these changes 2020-03-01 12:05:42 +00:00
dawidpotocki (Migrated from github.com) left a comment

🙃

🙃
Kovaelin commented 2020-04-01 21:55:05 +00:00 (Migrated from github.com)

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

Is there a reason for listing Disroot, but not Rainloop?
fm commented 2020-04-01 22:04:00 +00:00 (Migrated from github.com)

Rainloop is an email client, not an email provider

Rainloop is an email client, not an email provider
This repo is archived. You cannot comment on pull requests.
No Milestone
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: privacyguides/privacytools.io#1672
No description provided.