mirror of
https://github.com/privacyguides/privacyguides.org.git
synced 2026-02-06 17:40:34 +00:00
update: Remove "zero-access" et al. (#3193)
This commit is contained in:
@@ -19,7 +19,7 @@ Email is practically a necessity for using any online service, however we do not
|
||||
|
||||
For everything else, we recommend a variety of email providers based on sustainable business models and built-in security and privacy features. Read our [full list of criteria](#criteria) for more information.
|
||||
|
||||
| Provider | OpenPGP / WKD | IMAP / SMTP | Zero-Access Encryption | Anonymous Payment Methods |
|
||||
| Provider | OpenPGP / WKD | IMAP / SMTP | Encrypted Storage | Anonymous Payment Methods |
|
||||
|---|---|---|---|---|
|
||||
| [Proton Mail](#proton-mail) | :material-check:{ .pg-green } | :material-information-outline:{ .pg-blue } Paid plans only | :material-check:{ .pg-green } | Cash <br>Monero via third party |
|
||||
| [Mailbox Mail](#mailbox-mail) | :material-check:{ .pg-green } | :material-check:{ .pg-green } | :material-information-outline:{ .pg-blue } Mail only | Cash |
|
||||
@@ -116,9 +116,9 @@ Proton Mail supports TOTP [two-factor authentication](https://proton.me/support/
|
||||
|
||||
#### :material-check:{ .pg-green } Data Security
|
||||
|
||||
Proton Mail has [zero-access encryption](https://proton.me/blog/zero-access-encryption) at rest for your emails and [calendars](https://proton.me/news/protoncalendar-security-model). Data secured with zero-access encryption is only accessible by you.
|
||||
Proton Mail stores your [emails](https://proton.me/blog/zero-access-encryption) and [calendars](https://proton.me/news/protoncalendar-security-model) with PGP-based encryption at rest, where only you have the decryption keys needed to access them later.
|
||||
|
||||
Certain information stored in [Proton Contacts](https://proton.me/support/proton-contacts), such as display names and email addresses, are not secured with zero-access encryption. Contact fields that support zero-access encryption, such as phone numbers, are indicated with a padlock icon.
|
||||
Certain information stored in [Proton Contacts](https://proton.me/support/proton-contacts), such as display names and email addresses, are **not** secured with your own encryption keys, so Proton is able to read them. Contact fields which are protected with your own encryption keys, such as phone numbers, are indicated with a padlock icon.
|
||||
|
||||
#### :material-check:{ .pg-green } Email Encryption
|
||||
|
||||
@@ -195,7 +195,7 @@ Mailbox Mail has a digital legacy feature for all plans. You can choose whether
|
||||
|
||||
## More Providers
|
||||
|
||||
These providers store your emails with zero-knowledge encryption, making them great options for keeping your stored emails secure. However, they don't support interoperable encryption standards for E2EE communications between different providers.
|
||||
These providers encrypt your emails in a way that only you can read them later, making them great options for keeping your stored emails secure. However, they don't support interoperable encryption standards for E2EE communications between different providers.
|
||||
|
||||
<div class="grid cards" markdown>
|
||||
|
||||
@@ -251,7 +251,7 @@ Tuta supports [two-factor authentication](https://tuta.com/support#2fa) with eit
|
||||
|
||||
#### :material-check:{ .pg-green } Data Security
|
||||
|
||||
Tuta has [zero-access encryption at rest](https://tuta.com/support#what-encrypted) for your emails, [address book contacts](https://tuta.com/support#encrypted-address-book), and [calendars](https://tuta.com/support#calendar). This means the messages and other data stored in your account are only readable by you.
|
||||
Tuta stores your [emails](https://tuta.com/support#what-encrypted), [address book contacts](https://tuta.com/support#encrypted-address-book), and [calendars](https://tuta.com/support#calendar) with strong encryption where only you have the decryption keys. This means the messages and other data stored in your account cannot be read by anyone other than you after they are stored.
|
||||
|
||||
#### :material-information-outline:{ .pg-blue } Email Encryption
|
||||
|
||||
@@ -275,14 +275,14 @@ We regard these features as important in order to provide a safe and optimal ser
|
||||
|
||||
**Minimum to Qualify:**
|
||||
|
||||
- Must encrypt email account data at rest with zero-access encryption.
|
||||
- Must encrypt email account data at rest with asymmetric encryption, where only the user has the private keys needed to decrypt it.
|
||||
- Must be capable of exporting emails as [Mbox](https://en.wikipedia.org/wiki/Mbox) or individual .EML with [RFC5322](https://datatracker.ietf.org/doc/rfc5322) standard.
|
||||
- Allow users to use their own [domain name](https://en.wikipedia.org/wiki/Domain_name). Custom domain names are important to users because it allows them to maintain their agency from the service, should it turn bad or be acquired by another company which doesn't prioritize privacy.
|
||||
- Must operate on owned infrastructure, i.e. not built upon third-party email service providers.
|
||||
|
||||
**Best Case:**
|
||||
|
||||
- Should encrypt all account data (contacts, calendars, etc.) at rest with zero-access encryption.
|
||||
- Should encrypt all account data (contacts, calendars, etc.) at rest with asymmetric encryption, where only the user has the private keys needed to decrypt it.
|
||||
- Should provide integrated webmail E2EE/PGP encryption as a convenience.
|
||||
- Should support WKD to allow improved discovery of public OpenPGP keys via HTTP. GnuPG users can get a key with this command: `gpg --locate-key example_user@example.com`.
|
||||
- Support for a temporary mailbox for external users. This is useful when you want to send an encrypted email without sending an actual copy to your recipient. These emails usually have a limited lifespan and then are automatically deleted. They also don't require the recipient to configure any cryptography like OpenPGP.
|
||||
@@ -314,7 +314,7 @@ Email servers deal with a lot of very sensitive data. We expect that providers w
|
||||
**Minimum to Qualify:**
|
||||
|
||||
- Protection of webmail with 2FA, such as [TOTP](basics/multi-factor-authentication.md#time-based-one-time-password-totp).
|
||||
- Zero-access encryption, which builds on encryption at rest. The provider does not have the decryption keys to the data they hold. This prevents a rogue employee leaking data they have access to or remote adversary from releasing data they have stolen by gaining unauthorized access to the server.
|
||||
- Encryption at rest, using asymmetric encryption where the service provider does not have the decryption keys to the data they hold. This prevents a rogue employee leaking data they have access to, or a remote adversary from releasing data they have stolen by gaining unauthorized access to the server.
|
||||
- [DNSSEC](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) support.
|
||||
- No TLS errors or vulnerabilities when being profiled by tools such as [Hardenize](https://hardenize.com), [testssl.sh](https://testssl.sh), or [Qualys SSL Labs](https://ssllabs.com/ssltest); this includes certificate related errors and weak DH parameters, such as those that led to [Logjam](https://en.wikipedia.org/wiki/Logjam_(computer_security)).
|
||||
- A server suite preference (optional on TLS 1.3) for strong cipher suites which support forward secrecy and authenticated encryption.
|
||||
|
||||
Reference in New Issue
Block a user