✨ Feature Suggestion | Add section to email providers for high threat level users #1765

New Issue

2020-03-05T23:53:00Z

Zenithium commented

2020-03-05 23:53:00 +00:00

(Migrated from github.com)

Description

I don't know if this should go as worth mentioning or a different section but it would be nice to have a provider for users that doesn't require JavaScript like Elude (Tor), danwin1210 (Tor), Postman (I2P), secMail (Tor) etc. along with a warning that all communication through these services should be encrypted beforehand with PGP. Note: I am not certain that all these services don't require JavaScript but I can look into it if this issue is considered.

This is tangentially related to #297 and #880

## Description I don't know if this should go as worth mentioning or a different section but it would be nice to have a provider for users that doesn't require JavaScript like [Elude (Tor)](http://eludemaillhqfkh5.onion/), [danwin1210 (Tor)](http://danielas3rtn54uwmofdo3x2bsdifr47huasnmbgqzfrec5ubupvtpid.onion/mail/index.php), [Postman (I2P)](http://hq.postman.i2p/), [secMail (Tor)](http://secmailw453j7piv.onion/src/login.php) etc. along with a warning that all communication through these services should be encrypted beforehand with PGP. Note: I am not certain that _all_ these services don't require JavaScript but I can look into it if this issue is considered. This is tangentially related to #297 and #880

dngray commented

2020-03-06 00:08:55 +00:00

(Migrated from github.com)

The issue with these services is nobody really knows who runs them, it could very well be a state's intelligence agency.

"High threat" users should really just avoid using anything which is not E2EE and leaves metadata.

The issue with these services is nobody really knows who runs them, it could very well be a state's intelligence agency. "High threat" users should really just avoid using anything which is not E2EE and leaves metadata.

👍 1

Zenithium commented

2020-03-06 00:29:14 +00:00

(Migrated from github.com)

The issue with these services is nobody really knows who runs them, it could very well be a state's intelligence agency.

"High threat" users should really just avoid using anything which is not E2EE and leaves metadata.

That is why I explicitly said that communications should always be encrypted through these services and hence who runs them is irrelevant. The important thing is that users can use the service without exposing themselves to JavaScript which could be malicious and compromise the user. And while it might be run by a state, it might just be run by a normal person, and hidden services have the advantage of the location of the server being unknown hence no government can act against it and try seize it and whatnot unless the host leaks their IP somehow.

I agree that E2EE services are the best but sometimes having other options is useful, and in any case using PGP accomplishes E2EE.

I guess it might be debatable that users with such high threat models have probably already done their research and it might not be necessary for us to cater to them at all, but having the information out there should always be useful, at least to other curious users who are not in such a situation (but perhaps might find themselves in it one day).

> The issue with these services is nobody really knows who runs them, it could very well be a state's intelligence agency. > > "High threat" users should really just avoid using anything which is not E2EE and leaves metadata. That is why I explicitly said that communications should always be encrypted through these services and hence who runs them is irrelevant. The important thing is that users can use the service without exposing themselves to JavaScript which could be malicious and compromise the user. And while it might be run by a state, it might just be run by a normal person, and hidden services have the advantage of the location of the server being unknown hence no government can act against it and try seize it and whatnot unless the host leaks their IP somehow. I agree that E2EE services are the best but sometimes having other options is useful, and in any case using PGP accomplishes E2EE. I guess it might be debatable that users with such high threat models have probably already done their research and it might not be necessary for us to cater to them at all, but having the information out there should always be useful, at least to other curious users who are not in such a situation (but perhaps might find themselves in it one day).

dngray commented

2020-03-06 00:53:09 +00:00

(Migrated from github.com)

That is why I explicitly said that communications should always be encrypted through these services and hence who runs them is irrelevant.

Metadata is still not encrypted To:, From: etc.

The important thing is that users can use the service without exposing themselves to JavaScript which could be malicious and compromise the user.

Well that's not specific to those providers, any provider which allows you to use an email client solves that problem.

And while it might be run by a state, it might just be run by a normal person, and hidden services have the advantage of the location of the server being unknown hence no government can act against it and try seize it and whatnot unless the host leaks their IP somehow.

If that were the case then no government would ever take down any criminal material/sites on .onion services and they do for a plethora of other reasons, mostly related to the operator.

As we really don't know how these services are run, who they're run by, if they're run in someone's spare time, whether they will be around in the future or receive regular security updates, I do not think we can recommend them.

> That is why I explicitly said that communications should always be encrypted through these services and hence who runs them is irrelevant. [Metadata](https://www.privacytools.io/providers/email/#metadata) is still not encrypted `To:`, `From:` etc. > The important thing is that users can use the service without exposing themselves to JavaScript which could be malicious and compromise the user. Well that's not specific to those providers, any provider which allows you to use an email client solves that problem. > And while it might be run by a state, it might just be run by a normal person, and hidden services have the advantage of the location of the server being unknown hence no government can act against it and try seize it and whatnot unless the host leaks their IP somehow. If that were the case then no government would ever take down any criminal material/sites on .onion services and they do for a plethora of other reasons, mostly related to the operator. As we really don't know how these services are run, who they're run by, if they're run in someone's spare time, whether they will be around in the future or receive regular security updates, I do not think we can recommend them.

Zenithium commented

2020-03-06 01:10:09 +00:00

(Migrated from github.com)

Well that's not specific to those providers, any provider which allows you to use an email client solves that problem.

I agree with that, but many provider websites are not navigatable with JS disabled and so registration can not even be achieved. I admit that I do not know which of the currently listed providers (if any) allow registration without JS and allow third-party email clients.

If that were the case then no government would ever take down any criminal material/sites on .onion services and they do for a plethora of other reasons, mostly related to the operator.

Obviously I wasn't claiming that no hidden services have ever been taken down by governments, I'm just saying that they're way harder to find than if you have your company address written on the site.

As we really don't know how these services are run, who they're run by, if they're run in someone's spare time, whether they will be around in the future or receive regular security updates, I do not think we can recommend them.

I do agree that these services are often not around for long which could be problematic for users, but this is not unique to these services as all providers have a clause in their ToS that allows them to close their services without any reason or notice.

> Well that's not specific to those providers, any provider which allows you to use an email client solves that problem. I agree with that, but many provider websites are not navigatable with JS disabled and so registration can not even be achieved. I admit that I do not know which of the currently listed providers (if any) allow registration without JS **and** allow third-party email clients. > If that were the case then no government would ever take down any criminal material/sites on .onion services and they do for a plethora of other reasons, mostly related to the operator. Obviously I wasn't claiming that no hidden services have ever been taken down by governments, I'm just saying that they're way harder to find than if you have your company address written on the site. > As we really don't know how these services are run, who they're run by, if they're run in someone's spare time, whether they will be around in the future or receive regular security updates, I do not think we can recommend them. I do agree that these services are often not around for long which could be problematic for users, but this is not unique to these services as all providers have a clause in their ToS that allows them to close their services without any reason or notice.

5a384507-18ce-417c-bb55-d4dfcc8883fe commented

2020-03-06 01:38:18 +00:00

(Migrated from github.com)

I agree with that, but many provider websites are not navigatable with JS disabled and so registration can not even be achieved. I admit that I do not know which of the currently listed providers (if any) allow registration without JS and allow third-party email clients.

The only webmail that can be used without JS is squirrelmail, and I think NixNet mail, but from all of the listed on PT they require it.

I agree that a section with e-mail specifically for self contained networks would be awesome, but as of now, none of the e-mail provider meet the criteria, therefore, couldn't be listed.

Also, if your threat model is that high, you shouldn't be using e-mail at all, but rather an instant messenger.

>I agree with that, but many provider websites are not navigatable with JS disabled and so registration can not even be achieved. I admit that I do not know which of the currently listed providers (if any) allow registration without JS and allow third-party email clients. The only webmail that can be used without JS is squirrelmail, and I think NixNet mail, but from all of the listed on PT they require it. I agree that a section with e-mail specifically for self contained networks would be awesome, but as of now, none of the e-mail provider meet the criteria, therefore, couldn't be listed. ---- Also, if your threat model is **that** high, you shouldn't be using e-mail at all, but rather an instant messenger.

5a384507-18ce-417c-bb55-d4dfcc8883fe commented

2020-03-06 01:42:06 +00:00

(Migrated from github.com)

I agree that E2EE services are the best but sometimes having other options is useful, and in any case using PGP accomplishes E2EE.

No, it doesn't, PGP can't encrypt headers and other e-mail metadata, also, e-mail doesn't support Open Wispers System, so if your encryption keys are stolen, brute forced, or else, all of your previous messages will be visible.

And with regards to using Tor on Safest, and JS attacks, I will comment on your CTemplar issue.

>I agree that E2EE services are the best but sometimes having other options is useful, and in any case using PGP accomplishes E2EE. No, it doesn't, PGP can't encrypt headers and other e-mail metadata, also, e-mail doesn't support Open Wispers System, so if your encryption keys are stolen, brute forced, or else, all of your previous messages will be visible. And with regards to using Tor on Safest, and JS attacks, I will comment on your CTemplar issue.

Zenithium commented

2020-03-06 02:06:04 +00:00

(Migrated from github.com)

I am unsure if metadata falls under E2EE since I thought only message content is covered by that but that might be a misunderstanding on my part. AFAIK providers of any E2EE service always see metadata since the communication is passing through their network.

I consider brute forcing to be stretching it in terms of arguments; as for keys being stolen, it that case wouldn't the machine already be compromised anyway? Stolen keys would be one of many problems at that time. I do agree that PGP not having forward secrecy is a weakness, and as I stated above I do not think this is the safest method of communication, I simply want to start a discussion about whether this should be added with adequate warnings for users like the one already present with additional stress on using PGP.

I am unsure if metadata falls under E2EE since I thought only message content is covered by that but that might be a misunderstanding on my part. AFAIK providers of any E2EE service always see metadata since the communication is passing through their network. I consider brute forcing to be stretching it in terms of arguments; as for keys being stolen, it that case wouldn't the machine already be compromised anyway? Stolen keys would be one of many problems at that time. I do agree that PGP not having forward secrecy is a weakness, and as I stated above I do not think this is the safest method of communication, I simply want to start a discussion about whether this should be added with adequate warnings for users like the one already present with additional stress on using PGP.

5a384507-18ce-417c-bb55-d4dfcc8883fe commented

2020-03-06 02:17:04 +00:00

(Migrated from github.com)

I am unsure if metadata falls under E2EE since I thought only message content is covered by that but that might be a misunderstanding on my part. AFAIK providers of any E2EE service always see metadata since the communication is passing through their network.

Depends on the provider, Signal based applications are metadata resistant, whereas Whatsapp for example...

I consider brute forcing to be stretching it in terms of arguments

Maybe today, but at some point in the future old encryption methods will be breakable, and that data can still be used against your, also with the arise of quantum computers some encryption algorithms will become outdated (I'm not saying it's the case here).

as for keys being stolen, it that case wouldn't the machine already be compromised anyway? Stolen keys would be one of many problems at that time.

I guess a MITM attack could achieve this with snooping, but I may be wrong; It could also be that the attacker got access to your database but not to use your phone as if they had complete access.

I do agree that PGP not having forward secrecy is a weakness, and as I stated above I do not think this is the safest method of communication, I simply want to start a discussion about whether this should be added with adequate warnings for users like the one already present with addition stress on using PGP.

Great then, I do think that having an only-SCN e-mail provider would be nice, but as I stated above, you are better using a clear net provider with proper server security that also has a .onion, if some of them work on their website, I don't see why they shouldn't be listed.
Still, I think a good start would be to not tell people that if they threat model are three letter state agencies they should use e-mail, but rather the complete opposite.

>I am unsure if metadata falls under E2EE since I thought only message content is covered by that but that might be a misunderstanding on my part. AFAIK providers of any E2EE service always see metadata since the communication is passing through their network. Depends on the provider, Signal based applications are metadata resistant, whereas Whatsapp for example... >I consider brute forcing to be stretching it in terms of arguments Maybe today, but at some point in the future old encryption methods will be breakable, and that data can still be used against your, also with the arise of quantum computers some encryption algorithms will become outdated (I'm not saying it's the case here). >as for keys being stolen, it that case wouldn't the machine already be compromised anyway? Stolen keys would be one of many problems at that time. I guess a MITM attack could achieve this with snooping, but I may be wrong; It could also be that the attacker got access to your database but not to use your phone as if they had complete access. >I do agree that PGP not having forward secrecy is a weakness, and as I stated above I do not think this is the safest method of communication, I simply want to start a discussion about whether this should be added with adequate warnings for users like the one already present with addition stress on using PGP. Great then, I do think that having an only-SCN e-mail provider would be nice, but as I stated above, you are better using a clear net provider with proper server security that also has a .onion, if some of them work on their website, I don't see why they shouldn't be listed. Still, I think a good start would be to ***not*** tell people that if they threat model are three letter state agencies they should use e-mail, but rather the complete opposite.

blacklight447 commented

2020-03-06 14:49:44 +00:00

(Migrated from github.com)

I would also argue that i really do not want to recommend E-mail to high threat users. i rather point them towards something like Signal, Briar , or SecureDrop, depending on what situation they are in.

dngray commented

2020-03-06 16:50:20 +00:00

(Migrated from github.com)

I'm going to close this, as recommending providers run by unknown individuals to "high threat" individuals is irresponsible, and really is no better than using any other provider.

People with high threat should be using E2EE with no metadata where possible and refrain from using email.

I'm going to close this, as recommending providers run by unknown individuals to "high threat" individuals is irresponsible, and really is no better than using any other provider. People with high threat should be using E2EE with no metadata where possible and refrain from using email.

This repo is archived. You cannot comment on issues.