New email section #1672
No reviewers
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#1672
Loading…
Reference in New Issue
No description provided.
Delete Branch "pr-new_email_section"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Deploy preview for privacytools-io ready!
Built with commit
b8781e4378
https://deploy-preview-1672--privacytools-io.netlify.com
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.
Note to self:
Another thing I want to improve is that warning.
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.
I think also we shouldn't recommend one specific messenger here now that the instant messenger page has been revamped.
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.
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
Some small nit-picky suggestions (haven't reviewed all of it but this is so far).
Also I think in their section we can just say Posteo and not Posteo.de.
I'm wondering if instead of adding phrase "Visit to create an account," we simply hyperlink the title of each section?
@ -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."
---
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)?
Looks good, but do not understand why Mailbox.org is above Posteo or Protonmail?
Edit:
Just on a basic look through of ThatOnePrivacySite:
I do not understand how this rating list can be justified.
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]
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.
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.
@ -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 can do that easily enough and then that would also resolve #1673
I agree. I have to admit with that I followed the style of the VPN page.
Agreed, its how they refer to themselves on their website.
Wow that was really a munted sentence. heh.
@ -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."
---
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.
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:
Cons:
IMAP/POP/SMTP/JMAP/:
Pros:
Cons:
Custom client (eg Tutanota):
Pros:
Cons:
Thought I'd leave some suggestions and corrections.
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
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.
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.
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
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."
---
There's a typo in YubKey, should be YubiKey
@ -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."
---
Well spotted.
Thanks for that, I did not know.
have you got a source for that coming in V4?
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/
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.
@ -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 andtext-secondary
for supplementary info).@ -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.
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.
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."
---
LGTM, but I would probably make this link a call-to-action.
@ -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 think we've moved past this with the Q&A on email metadata
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. ?
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"?
I don't like that either. It's just what was there before.
Yes this sounds much better
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.
something is messed up here. you are missing a closing div. I don't know why these lines exist in the first place
cleanup
useless?
illegal html, ul cannot exist inside p tag
stray li tag??
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".
Adding @dawidpotocki because he's going to fix the anonaddy and mailcow logos!
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>.
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"Missing a period at the end, and capitalize the next sentence
Source code [...]
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?
Typo?
They seem to be using the old word hidden service, so up to you whether you will accept this or the other suggestion.
I think their TOTP support is only for NextCloud?
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.
@ -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>
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.
Couple more edits
Missing a comma after
processors
I'd remove the second Posteo, like so
Doubled only
Missing a . at the end of the last sentence
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.
Nah that would have been my mistake. Guess that shows how old I am.
I was not aware of that, I'll be sure to update that then and check with them about it.
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.
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.
https://community.torproject.org/onion-services/ is the upstream if you are interested
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
for a while.
@ -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>.
I think I'll go with that.
@ -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>
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?
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.
Have you got a link for the Q2 2020 prediction? The one you supplied doesn't say 2020.
Okay I won't mention it then. I won't mention Hubzilla until it becomes generally available.
Generally any provider which provides external temporary mailboxes does so, so the user recipient doesn't have to configure OpenPGP in for their reply.
I know WKD support works with Thunderbird according to the enigmail changelog:
/me is a strong proponent of the oxford comma
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.
Until we finish #904 we probably shouldn't either link to nor mention any specific hardware, just technologies.
Literally up above you said this was not possible with their webmail:
Should this be clarified?
Edit Actually I'd do this and not link to them in this case:
or...
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...
Is this enabled by default? If so:
If not,
Can't check Tor currently, do they have an EV certificate for their onion domain?
see: protonmail wkd suggestion
is this suggestion factually accurate?
How the heck would this be true? lol
Do they enable their server-side encryption by default?
How does this work then
For Soverin we said:
Is this also true here?
Otherwise if it is zero-access we should state that as well.
@ -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 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
Fair point.
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
I think @JonahAragon means it's inconsistent. One says it can be done in webmail, the other says it can't.
Yes they do:
Should we mention their TOTP implementation is a Roundcube plugin, hence why IMAP/SMTP is not protected?
https://posteo.de/en/site/faq
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.
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.
@ -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>
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.
I'm thinking we could just use a little sup number, and then anchor it at the bottom of the page like Wikipedia style?
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.
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.
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.
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.
@ -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."
---
There is a duplicate in email software page, we should make this into a separate file.
@ -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."
---
Fixed see
9ff3b08e01
Only posts I could find, and they weren't official:
So I might just take out the Q1/Q2 thing, it might take longer.
I think this has been resolved as of
cbf2b09541
that way if it's late we don't have to update the page.@ -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>
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.
@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
Oh, good catch, removed as I think we've well and truly covered that topic.
b2f252939c
@ -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>
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.
So I've done this
1d457dbe38
how do you think it looks? hmm seems like we could remove a column.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.
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.
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.
LGTM 👍🏼
@ -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"
Quick correction. You can also search by Subject in web/mobile
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?
I agree
@ -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"
We will be sure to reflect that, fixed in
e22625deac
Fair enough, as long as we mention that the bridge requires a paid account.
Hi, @blacklight447-ptio asked for our feedback on the new e-mail page. These are our suggestions:
General
mailbox.org
Technology
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:
Security
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.
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.
General
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
They do for webmail, customers can even choose to buy a Yubikey direct from Mailbox pre-enrolled:
You can then set the security level:
And method:
Or you can enroll a key that you purchased elsewhere:
I think it might only support the Yubikey though.
I have made a note of that
00d0021c78
. There is some degree of trust placed in the provider.Technology
I think I have clarified that with
c122bcb346
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:
Done:
2ebb28c05b
I'd say all our providers meet this:
Added this requirement
27e0bf3cc3
Security
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
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.
I've also decided to remove the base requirement on standard access protocols added in
3046548812 (diff-8cc7b2b0d78dd2501610391c086a8516R41)
andb52f6b7b1e (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.
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 😳
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).
@ -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 a bit redundant, I’d remove the encrypted so that it says is E2EE
@ -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>
ugh yeah. lol.
Hate to be that guy
Doesn’t really sound right, maybe switch it to
uses
or removethat
You're right, and I am clearly tired.
Thanks for your changes, @dngray.
mailbox.org seems to use Yubico OTP via Yubico Cloud. It makes sense that they can preconfigure a YubiKey when purchased on their website in this case. All other references are always "OTP", not "U2F". Furthermore, they support OATH-TOTP and OATH-HOTP according to the screenshots.
There are actually open requests for U2F and WebAuthn support. Both requests are still open. So it seems that there is no support for U2F.
(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:
(Feel free to reword this if necessary!)
Ah yes, you're right. How does
7d21d548a7
sound.For record purposes, I've included a screenshot of the other options:
That was also my understanding from https://webauthn.guide hence the "scoped" part of it.
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:
vs
This is particularly for older or disabled people, who are more likely to get tricked by
paypal.com
vspaypaI.com
. (or any other variation).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
I think we may need to make corrections to the posteo description:
Looking at How can I use a YubiKey for two-factor authentication with Posteo? it says
Fixed:
30eaec6f1a
Great work folks, im excited to finally launch the new page!
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.
I guess the svgs are still fine
🙃
Is there a reason for listing Disroot, but not Rainloop?
Rainloop is an email client, not an email provider