Add EasyCrypt to Privacy-Conscious Email Providers list #316
No reviewers
jonah
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
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#316
Loading…
Reference in New Issue
No description provided.
Delete Branch "master"
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?
Description
Adding EasyCrypt to Privacy-Conscious Email Providers list
HTML Preview
http://htmlpreview.github.io/?https://github.com/ezcdev/privacytools.io/blob/master/index.html#email
@C-O-M-P-A-R-T-M-E-N-T-A-L-I-Z-A-T-I-O-N Thoughts?
It's not really an email provider is it? Feels like this should be listed under the
Privacy Email Tools. Furthermore every email I type in seems to be not working without any feedback why.It is not. I agree that's a better category. And it did work for me.
If something is not working please write to support@easycrypt.co. Note that JS must be enabled and only the following browsers are supported: Firefox, Chrome, Safari, Tor. Other varieties of Chromium based browsers or FF forks may work but were not tested.
Why EasyCrypt team opines that this should be in the email category is described here.
https://easycrypt.co/ contains the tracker
stats.wp.comEasyCrypt is a tool, not an email provider.
Also it's a new tool. Closed-source backend + no established trust.
Further to my comment above, https://easycrypt.co/ also uses
google-analytics.comSo much for privacy!
We use GA to measure statistics of visits to our informational website, not to our email privacy service.
You do not need to go to the website to sign up or to use the service, the signups/logins are at https://webmail.easycrypt.co/login/ and at webmail.ezcrypt2dgcicxqj.onion for https and Tor hidden service sites, respectively. No GA or even our internal user data logging there.
@ghere
How about?
Web Analytics - PRISM Break
https://prism-break.org/en/all/#web-analytics
Yep these are good solutions. When we have more resources we'll move away form GA whose only attraction is that it is free and quick to implement. For now, faced with the choice where to put our limited resources, we put them in enhancing the security of the EasyCrypt service, not of the informational website.
Wrong category.
I suggest adding it in the same way as Mail-in-a-Box. Put EC below MiaB.
This is definitely not in the same category as MiaB. EasyCrypt is a service provider that provides privacy services comparable to ProtonMail, Tutanota and Mailfence.
It's a tool, not a provider. Adding it to the provider table is a bad idea, due to the falsely superior values.
u/EasyCrypt•27 minutes ago
Hi Shifterovich,
I suggest that we take the discussion of whether EasyCrypt is a tool or a service provider off GitHub and complete it here.
EasyCrypt is definitely a service provider. We run the service from our servers in Switzerland. The service is personal, we manage user accounts and their encryption keys, and provide essentially the same function as other encrypted email providers except we allow them to use their existing email address and communicate with external PGP users. I do not understand why you classify, say, ProtonMail or Tutanota as a service provider but EasyCrypt as a "tool".
EasyCrypt
u/Shifterovich•just now
Disagree, we should discuss that publicly.
ProtonMail provides an email address, they're an email provider. EC provides encryption for an existing email address, EC is a tool like Enigmail.
EC is a provider only if Enigmail is a provider. A server-side does not make you a[n email] provider. Closed-source backend doesn't make you a provider.
Edit: clarification in [ ]
I disagree. Enigmail is a piece of software installed on a PC that leaves the key management burden on the user (which is precisely why so few people use PGP). This is definitely not a service.
EasyCrypt provides a service to the user that frees the user from the need to install stuff on his PC and from doing key management. Which is why it is a service provider.
Then why does PTIO list other closed source backend services as "providers"?
False cause. Listing providers that have a closed-source backend doesn't mean that having a closed-source backend makes you a provider.
It might be an online service, but how is it an email provider?
You want to have a superior position in the provider table, yet you're a new service with no established trust, closed-source backend and not enough resources to run an analytics platform?
Also, in the other thread you said
On what basis should we add EC then?
I second that
I don't really think that MiaB is in any category. There is just a paragraph for MiaB on its own without any specific category. You might have a point that EC is not a
Privacy Email Tool, but when you emphasis on the more or less important detail, that it is not a tool, because it is managed server side, then we should also emphasis on the more or less important detail that it is not really anEmail Provider, but it uses an existing email from a different provider.Exactly. It allows for an image and a long description. It's better than one-line descriptions of Privacy Email Tools and highlights that it's different than the other things mentioned in that section, the same way as MiaB.
Of course it is. The category is spelled out in the heading: "Become Your Own Email Provider". This has absolutely nothing in common with what EasyCrypt does.
Have a look here: https://www.privacytools.io/#addons and imagine MiaB is
Privacy Badgerand EC isuBlock Origin. This is the way EC should be listed here...I disagree. EC is not an extension or an add-on. It is a stand-alone email privacy service.
Possibly a new category could be created: "Email privacy services". We can provide the suggested headings for parameters of such services (eg which email services are supported; is the encryption end to end; kind of encryption supported; is it available as a Tor/I2P hidden service; does it require installation; does it use JS etc.)
MiaB is not an extension or an add-on as well but still listed this way...This way of listing does not have to do anything with extensions or add-ons.
Maybe...but a new category for only one service sounds overkill. Rather have it below MiaB with an expressive headline and description.
You're very confused. That's a heading, not a category.
You're misinterpreting what's been said.
Whether you like it or not, closed-source services require trust. Adding a service like yours is usually a matter of a proposal, approval, and merge.
By your pointless arguing over unimportant things, you're building everything but trust (which you lack, by the way).
I like your style.
In a strict sense, they aren't an email provider. But they aren't quite an email tool either (they provide a service: storing your keys and encrypting your emails). A tool (in my opinion) is a piece of software that I can store on my computer and use at my own discretion without requiring third parties.
I have no objection listing them with the email providers due to lack of a better category to put them on.
A somewhat better description of them is "email encryption service provider".
How is listing them as a provider more okay than listing them as a tool, if they're neither?
Like I said, it puts them at a superior position in the table while not being an email provider.
There is no clearcut category for EC but they are definitely more of a service provider than a tool. If we're rejecting them for merely not "fitting" in the existing boundaries of our title/description for that section then we could just rename the section to have a broader title.
Note: I'm not a fan of the whole email provider section or closed-source services in general (encryption and key storage must happen locally IMO). If it were up to me the whole section would be gone :P At least they are better than Gmail et al.
Fair point. I'm just glad to see an onion domain. (And IMO all projects that provide an onion domain can have superiority in a table)
Yes, but if you look at the pull request, the values were "Unlimited" for storage, etc.
The point is not to recommend Snowden-level tools, but to cover the whole spectrum of threat models. ProtonMail for fast and usable crypto, local GPG in an offline VM for maximum security when it's possible.
Ahh, I get his reasoning but not applicable" is better. Anyways, unless he re-opens the PR then I'm not really going to put more time into it.
I know, that's why I can live with it. Every step in the right direction is better, even if it's a small one.
@kewde
This was precisely my opinion and point.
We closed the PR because it resulted in vitriolic bashing of EasyCrypt rather than in constructive discussion. This included the attempt to push EasyCrypt service into the Tool category, comments about the resulting "superior position" in the encrypted email services table (should not the table just provide the correct information and let the user decide what is superior to what according to his needs, convenience and threat model, rather than block information about features of EasyCrypt that make it superior to ProtonMail, like no limit on messages and ability of full bibirectional communication with any PGP user instead of putting the user in the walled ProtonMail garden?), telling us that we are not to be trusted etc. So we closed the pull request to put an end to all this biased bashing that led nowhere. Please give me a good reason to reopen the PR Iin view of all this and possibly we will.
@Shifterovich
I thought this was supposed to be a discussion of EasyCrypt's pull request and verification that information provided in the PR about EasyCrypt is correct. I was not aware that the intent was to protect the superior position of ProtonMail in the comparison table. EasyCrypt is superior to ProtonMail in its openness (communication with any PGP user and not a walled garden), unlimited messages, inherent ability of data liberation and import/export of PGP keys, PGP/MIME support and more.
If you would tell us in advance that you want to preserve the superior position of ProtonMail in the comparison table no matter what, we would not have bothered to open the PR.
Let's check the facts.
Falsely superior position: True, since it's not an email provider yet has the best values of all the providers in the table
Yes, the information provided in the PR is incorrect.
How did you come up with that?
Yeah, except it's not an email provider and is extremely inferior in the lack of any built trust. GPG IS SUPERIOR TO EASYCRYPT --- is this how you compare stuff?
Like I already said, I'd have no problem adding you, if you:
@Shifterovich
So the only "incorrect fact" provided by EasyCrypt that you can come up with is the moot point of this thread? This is not an incorrect fact, this is your opinion, which is being disputed on this thread at length.
If this is how you "check the facts" you should submit a PR for replacement of the comparison table title by "Shifterovich's favorite email providers".
lol.
I won't waste any more time here.
Not gonna trust someone who doesn't have any sense of logic with my email crypto.
"EasyCrypt is an email provider."
True or false?
EasyCrypt will not be added.
Good luck at https://github.com/nylira/prism-break.
Sent with ProtonMail Secure Email. :)
@shifteroviich
That EasyCrypt won't be added and your personal reasons for not letting it be listed were abundantly clear to us weeks ago, which is why we canceled our PR at that time.
The only remaining question is why you needed to run the farce of "community comments" in the first place, and what it says about how privacytools.io makes its decisions.
@ghere @Shifterovich
There are multiple possible approaches to adding EC to privacytools.
We can add them to the table of email providers.
We can list EC under ProtonMail and have "N/A" for the fields that do not apply (storage is the only one?).
This is regardless of any "technical superiority" but because of the mere fact that we're comparing apples and oranges.
They provide an onion domain, which is IMO a valuable argument for putting them higher on the list.
Other email providers might see the benefit of creating an onion domain for their service if they see that we treat them differently.
We make a whole new category and search for projects/services that do the same thing EC is doing.
This is a lot of work and I'm not aware of any projects like them.
I opt for option number one, it's easier and less work. The second option arguably benefits EC even more.
@kewde @Shifterovich
Either of the suggested compromises/approaches would be fine with us.
We would also appreciate an opportunity to straighten out our differences with Shifterovich which, at least on our side, admittedly went too far...
I vote for not adding them at all.
Like I said
With our visitors' best interest in mind, I'm strongly against adding EasyCrypt.
Hope attacking PRISM Break's team with lies will work out better.
@kewde The most critical part is trust. I don't trust a service that's attacking the team of the site they want to be added to with lies after it's pointed out that their pull request is pure snake oil.
@Shifterovich
I should've been more clear, I was discussing the potential approaches of how we could add them.
We might see more services like them, we need to have a way to deal with those. I use them as a convenient example. They way I see it, this controversy started around the question "how we should approach this type of service/toolish provider" 😛
A tool (in my opinion) is a piece of software that I can store on my computer and use at my own discretion without requiring third parties. So I think we should classify them as a service provider.
Anyways, the whole section is kinda snake oil, I only kinda "trust"/know tutanota and protonmail on the list. I have no objection adding them there. Ofcourse they were going to present their project in the best way possible, and argue their case to us.. It's our job to filter out the bullshit and check the facts to the extent that we can. Also using ProtonMail as an example, and then taunting them by replying with ProtonMail didn't inspire confidence on our neutrality.
Yes, but it's more of a tool than an email provider.
That was a response to the allegations that we're protecting ProtonMail's superiority in the table :P
I can't download it and use it at my own discretion. I think they're more related to an email provider than a tool to be honest
I know you're kidding, taunting them a bit but inb4 privacytools.io bribed by protonmail shitstorm.
Tools can be online, but email providers must provide an email address.
A tool is something you can download, it can be online but if I download the HTML, CSS & JS then I should be able to use it offline. That's not the case with EC, they are a service, not a tool.
It's not because they are less of an email provider that they are therefor more of a tool :P
We don't have to work within the confined boundaries of our existing headers.
For all I care
becomes
For singular cases like these I definitely wouldn't create a new section even tho the incompatibility with the existing sections makes an appealing case.
imo this is a tool https://atelier.u-sub.net/srt2vtt/
That website provides you a service. The source code is available tho, so they also provide a tool (unlike EC).
Whether the source is available or not is irrelevant to being a tool.
Even the website states that it's a tool.
https://3142.nl/latex-diff/ is this a service?
Is this web tool a service? http://aesencryption.net/
They are just services that present themselves as tools.. 3142 provides you the service of a latex-diff. AESEncryption.net provides you with the service of AES encryption. If they suddenly close down their service then it is gone. A web page can be a tool if I can download it and it still has its use. A tutorial can be a tool, I can download the content and it doesn't lose its value. Just because it has a user interface doesn't automatically make it a tool. I'll do a bit of English magic and call them toolish services.
The distinction is also made in our DNS section, DNSCrypt is a tool, the other is a service.
https://www.privacytools.io/#dns
Just because it's not local doesn't make it not a tool.
If I did a bit of English magic, I'd say that EC is a servicish tool. And even if they were services, they'd be closer to a tool than an email provider.
That's correct, but to be classified as a tool you must be able to use it locally. A tool has independence. This discussion is like me: 'hey there is a taxi', and you're saying 'no that's a car'.
Every taxi is a car, but not all cars are taxis.
They're definitely not an email provider, but again we don't need to restrict ourselves to these imaginary boundaries. I'd rather not have these kind of services labelled under tools. The mail providers don't provide the same level of security I'd expect from a tool.
Service/web tool is closer to a tool than to an email provider. imo implementing this kind of (web)tools/services the way MiaB is implemented is the best option.