Its just a webview app…
Yep. Installed it, started it, saw it is basically the website in an embedded browser, uninstalled it.
Like, come on, you have a web version. Why should I use an extra application to view a website. This seems like a cheap excuse for a desktop app.
Does it support offline access?
It does not. Which is the reason I wanted the app…
Are you sure?
This was in the linked article:
- Caching for offline use
Caching is not the same as actual offline functionality.
What the hell constitutes “actual offline use” for an email client
downloading emails and storing them locally for offline reading, categorizing, searching and drafting. “Caching” usually just means if you opened the app with connection, it won’t go bonkers and will probably let you finish your immediate task + some basic functionality if you lose it. Can’t close the app though.
Aaaand it’s electron garbage.
Ugh, I was looking forward to replacing Thunderbird/Bridge, but never mind.
Bridge
I am actually sort of worried that now that they put this out they will retire bridge. We will have to wait and see. Is having a browser tab open really that bad… ?? I suppose but I still like programs over web pages.
Out of the loop, what’s wrong with electron?
It’s basically Chrome. It’s not a real application, it’s a website pretending to be one. It uses a metric fuckton of RAM and eats your battery faster than Prince Andrew a minor.
If Firefox could allow their engine to be packaged like this I’d use it. The problem I see here is chromium. Everything is a trade off and we need more ways to build maintainable cross platform applications.
Slack, for example, is Electron and it runs great. One of the best apps I’ve used. And it works better than the browser version…
The hate on Lemmy of electron is a bit of an overreaction if you ask me. Yeah it uses more ram than is necessary but again everything is a trade off. Not everything can be a hard to maintain rust app. Let’s try to embrace cross platform solutions, though yes fuck chrome/google, so sure criticize that part of it.
There is Tauri which packages it with WebKit and uses Rust as backend.
Let me get this right… you’re complaining about Chromium, but you use Slack? You do realize Chromium had better Linux support for things like HW-accelerated decoding than Firefox? Also, the Chromium sandbox is superior to Firefox.
I realize Firefox business practices aren’t total garbage for humanity and that they are constantly working to improve it on like .1% budget of Google. And that they are the only real competition which keeps us in a situation where we actually have a choice in browsers. So yeah let’s only care about the technical aspects, or something
And that they are the only real competition which keeps us in a situation where we actually have a choice in browsers.
That isn’t true. You’ve got WebKit-based browsers, LadyBird/LibWeb/LibJs, Goanna, and others. Why choose Mozilla to lead the efforts, when another open source community/foundation may be better? You can also participate in the various new web specifications yourself too if you’re not happy with the direction they’re headed.
They said competition, not alternatives. As things are right now, and knowing people, not just trying to make a technical point, Firefox is the only competition.
Chromium had better Linux support for things like HW-accelerated decoding than Firefox?
Source? Experienced the exact opposite, especially on Wayland.
You can track the bug history here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1751363
You can see here Chromium had support for this for several years prior:
https://aur.archlinux.org/cgit/aur.git/log/PKGBUILD?h=chromium-vaapi
Android being based on Linux prob has something to do with Chromium’s strong Linux support, but Mozilla has consistently prioritized Windows/Mac. Despite it still be challenging, building Chromium from source has always been a lot easier IMO than trying to create a custom build of Firefox.
Regardless, when it comes to privacy, Chromium itself is pretty stripped down and has policy-based integrations that put it on par with Firefox in terms of security. Even with Firefox, you’d have to modify quite a few policies to improve security. Tor/Mullvad Browser though do a better job in many ways and there is no equal to those privacy enhancements on Chromium that I know of, unless you’re using something like GrapheneOS.
Point being, people like to complain about Chromium a lot & act like Apple fan bois for Firefox, when in reality privacy is nearly the same with both with some minor configurations.
Chromium is not stripped down at all, just use googerteller and see. It contacts Google everywhere, on the password list, on the account list, in some settings pages, and just randomly sometimes.
It is very crazy. And also it is not fingerprint resistant at all.
I am using all flag settings, policies and GUI settings possibly existing and it still is like that. So no, it is not the same privacy-wise.
What the heck are you talking about? Chromium is one of the hardest packages to build and it takes forever. Firefox has FAR fewer dependencies. Chromium’s privacy enhancements are a joke.
Let’s try to embrace cross platform solutions,
[JavaFX has entered the chat.]
I don’t know what javafx is, but java is hell. For me. I’m glad it works for others
I don’t know what javafx is
Each electron App is actually a full independent chromium browser install running a website. It’s easy to code for and works cross platform as a result, but it’s essentially just a website, although they can run offline depending on what’s been built in to the local app.
Each electron app running on your system is a separate full chromium app running, with no sharing of resources between each instance. So they take up a lot of space each and duplicate all the resource usage, and potentially the security flaws.
It’s just the webapp. If we want the webapp we use a browser.
Slack desktop app is built with electron and works much better than the web app in my experience. So no it’s not actually always that simple.
Now that Chromium has persistent File System Access permission support, what benefit does Electron have over a PWA other than “Native-looking” menu bars?
It’s what you deploy to your users if you want to work around ad blockers and browser extensions. It’s a great tool to get operating system level access to exfiltrate information about your users and identify them uniquely, even if they would prefer that not to happen.
All that with the help of Google’s telemetry engine aka Chrome, which further helps Alphabet to manifest their interpretation of web standards in the world.
We worked to move things onto the web. Now people bring the web back to your desktop with every application bringing it’s own browser shell. We have come full circle and we’re now using 10x the resources.
Electron is the prime example of everything that is wrong in IT.
Wow. That sounds horrible. Do you have a source about the system level access statement? I would like to see people’s thoughts on it, if it’s as bad as it sounds, I’m surprised I haven’t heard about it before
What source do you need? It’s almost literally the mission statement of Electron.
I’ve never gone to the webpage of electron
Yeah, Proton is awesome, that’s for sure. Now, being a “security and privacy” company, it blows my mind that they put so much effort on making apps for Windows and Mac first, leaving Linux behind, and when they finally get to it, they just dump in a glorified PWA. This world is really weird 🤣🤣
And that they decided to go with RPM and DEB instead of just doing a Flatpak
Capitalism is weird? Ok, but this is what we have.
Idk, got thunderbird set up and feeling pretty happy with it.
(Webmail provider releases a bespoke desktop app)
(me, old fart, bumbles out from behind the cables and servers and muck)You fools! Have any of you whippersnappers ever heard of IMAP? No? Thought so.
[I’m not that familiar with ProtonMail. Chances are they already support IMAP. In which case: … …why? Why this? Why in this day and age?]
It’s worse than you thought.
The webmail provider released a dedicated browser that can only open the webmail and called it a “desktop” app.
Additionally, they don’t support IMAP. There’s an app to run on your computer that becomes a bridge. The proprietary protocol is translated to IMAP. You can’t use your favorite client if your operating system can’t run that bridge and you’re not a premium user because for “reasons” only premium users can run that local bridge
they don’t support IMAP
They don’t support IMAP because they want emails to remain end-to-end encrypted, and IMAP doesn’t have any way of doing that. The gateway decrypts the emails locally, then serves them as plain text.
We need something better than IMAP, that’s designed for modern use cases. Something that’s not stateful… Maybe a web service or something like that. JMAP seems promising but barely any providers have implemented it.
Still, if an user prefers the convenience of using any client instead of e2e, could enable it in a setting. Maybe the user subscribed because they liked the interface and the overall features of the plan, and not because of the encrypted email solution and just wants to add the account on the mobile client instead of a dedicated app
Being closed like this IMHO is just to increase user retention
If thex subscribed because of the interface (ehich is certainly plausible), what would they need IMAP support for? Also, if you really want IMAP, xou can have it, you just need their (open source) Proton Bridge for it (thats a sofrware) so that ut retains all features. But then I would need my own email client.
On mobile you’re forced to use their “open source” app that is only available on the closed source app stores and not on fdroid because it uses Google push services
Not true, it’s been available on Fdroid for quite some time now. And it doesn’t need play services for the notifications to work either.
It’s available on an unofficial repository that can be optionally added to fdroid, it’s not available on fdroid
“After years of pushing their proprietary and closed solutions to privacy minded people Proton decided that it was in their best interest to further bury said users into their service as a form of vendor lock-in. To achieve this they made more non-standard desktop clients for their groupware features (contacts and calendars) and the bridge will be discontinued soon.”
Only if there wasn’t CardDAV, CalDAV, IMAP, SMTP and dozens of other highly standardized protocols to handle e-mailing and groupware.
Is the bridge actually being discontinued? People have been saying that a lot recently but I’ve not seen any evidence for it, and not in the linked article.
I’m annoyed that they don’t support SMTP, but realistically they actually can’t unless they have the ability to read your email, which they don’t.
Is the bridge actually being discontinued?
No, but what from their moves it is very clear it won’t live long.
they don’t support SMTP, but realistically they actually can’t unless they have the ability to read your emai
Technically they do use SMTP… and it’s possible for a provider and provide submission and generic SMTP do clients without having to read the email content.
There are lots of ways to do e2e encryption on e-mail (no server access to the contents) over SMTP (OpenPGP, S/MIME etc.). There are also header minimization options to prevent metadata leakage. And Proton decided NOT to use any of those proven solutions (in a standard and open way at least) and go for some obscure implementation instead because it fits their business better and makes development faster.
no AppImage, no Flatpak, no PPA, and no COPR
So, what is general concesus about Proton, is it safe or not? I dont use it because you need to pay for Bridge to use it in Thunderbird. Maybe I would use if it has a dedicated app.
It’s pretty great. Especially considering that you get a full ecosystem with Mail, Calendar, Drive, VPN and Pass.
I would also like to take this opportunity to shout out murena.io. They host open source cloud solutions. You get a Nextcloud with OnlyOffice and lots of other goodies and their pricing is pretty good
So how would you sync your Proton Passwords with NextCloud, or with VaultWarden? Or actively sync them locally to be used with an open source app?
Oh, that’s right… you can’t. Proton will say… “Just trust our payloads bro! There is no way we’d ever deliver a modified payload to get your password. Sorry you can’t sync your calendar & contacts, just use our Windows apps.”
I wouldn’t? I suggested Murena as a Proton alternative. I don’t know if they have a password manager right know but you can always throw a KeePass database into your Nextcloud.
My sincerest apologies. I misread the thread and thought you were advocating for Proton, which IMO is a questionable company. Thanks for the clarification.
I use both. Proton fits most of my needs, Murena does the rest. I’m not attached to any of them though, if I’m given good enough a reason, I’ll drop Proton immediately
At least you’re open to moving on. I think keeping an open attitude in any scenario is prob the best option. For most people, I’d recommend they keep using whatever works for them. If you’re happy with Proton then switching may just cause frustration. However, if you’re very much security focused and also care about things like being able to access your calendars/contacts in the apps you want, then I’d prob suggest just using SimpleLogin for email with their GPG feature, vaultwarden for passwords (you can still use the BitWarden phone apps), and Nextcloud for Calendar/Contacts which also supports DAVx for mobile.
It is about as safe as trusting Apple at their word to protect your privacy.
So whats more privacy friendly, using a browser to check email, og using the official Proton app?
Neither. The single app that Proton has done somewhat right with is their VPN and only because they haven’t eliminated port forwarding. Everything else they’ve utilized non-standard protocols and failed to provide source code or API docs. They basically said that users are too stupid to protect themselves, and that you should just trust them to do it for you.
They failed to provide CalDav & CardDav syncing for things like calendars & contacts, IMAPS for mail, and prioritized things like their cloud-only password store. They had no valid reason not to use standardized protocols other than to prevent their users from actively syncing local copies of their data to integrate with privacy-friendly open source software. They act like Apple & a lot of their users prob. are Apple fan bois who will trust a company no questions asked. I have no reason to trust them whatsoever.
deleted by creator
Gmail requires that you use proprietary software. Anyway just because email is insecure doesn’t mean you should jump into the pot
No it doesn’t. You can use free Gmail with IMAPS & GPG-encrypt all your messages if you want to. I don’t know why you’re spreading lies, other than you’re just too oblivious to know better.
It in fact does. You can’t sign in with Google without non-free JavaScript
This is the dumbest argument. You can’t create a Proton account without non-free JS either. Once you enable IMAP in Gmail, you don’t have to sign in using the browser. Are you really going to argue this? I mean, you can just admit you don’t know enough about security and that you trust Proton just cause they make you feel warm & fuzzy or whatever.
Finally? Why does it need an app all of a sudden…
Making email secure and good is very hard and it involves either making it inconvenient or getting rid of interoperability with existing systems. As long as I’ve been tracking it your choices for client when using Proton were webmail or mobile apps. The news here is that a new option has opened up not that an old option is being taken away
This is just patently false. GPG is not inconvenient & there are a plethora of apps that has made it much more user friendly. The fact that Proton has decided to take away freedom & tell you it is more secure is just bologna. There is no reason to trust Proton at all.
I also prefer gpg but it is not super beginner friendly. I generally recommend people away from proton and tuta unless they really want encrypted email and gpg isn’t something they can figure out
GPG isn’t beginner friendly if you’re only using the CLI. However, even then there are tons of documentations and even Gemini/ChatGPT would prob be good at helping users create/manage their keys. However, I can provide a list of user-friendly GUI apps to create/manage/encrypt/etc. using GPG if you’d like that make it as easy. I mean, you can pay a company that says they’ll protect your privacy but history has shown paying for privacy is unreliable.
@timewarp @Quill7513 The only real alternative IMHO is hosting your own mail server and *that* is no alternative at all, because big-tech will blacklist your server immediately… so Proton/Tuta are the lesser of all evils. If you have a true alternative I am listening.
You can use PGP with just about any email service. I personally just use SimpleLogin, where you can add your public key to have all your messages encrypted. But Thunderbird, KMail, Evolution, FairMail, etc all support email encryption too with IMAP.
@timewarp ok, PGP … remember EFAIL… and all kinds of usability issues which inevitably lead to security issues by ‘wrong use’ at some point. And another *centralized* ‘web of trust’ (benign as it may be) is also not something I look forward to. O well, some genius will emerge at some point and deliver us 🥳 may he/she/it/them be FOSS-minded
GPG is a huge pain in the ass to manage. Everyone knows this, because it’s the case. The web of trust also doesn’t scale and has many problems, handling key securely is hard, making GPG work on all devices is something which is completely impossible for people without solid technical skills.
If you think otherwise, you are just in a bubble.
You’re a serial killer. Everyone knows this, because it’s the case.
Do you see how that works? You can say whatever you want, but unless you can provide some proof then you’re just parroting whatever you’ve heard. If you want to learn how to use GPG then let me know and I’d be happy to show you several open source tools that make it very easy so you can stop parroting BS. Otherwise, you’re entitled to your opinion and I’ll continue to believe you’re a serial killer.
The bubble you’re referring to is your own ignorance.
I never really understood the need for such apps when mail clients such as Thunderbird exist.
The ProtonBridge used to be garbage so people have wanted a dedicated app for awhile now. Over the past year or two, the Bridge finally works fairly reliably so …a little too late.
So the bridge now syncs your calendars, contacts, files & passwords? 😛 Their bridge still sucks like it always has.
Proton forces you to pay for a bridge to use Thunderbird.
Tutanota doesn’t even provide that.
These “privacy respecting” email services don’t respect the user enough to let them use third party email clients easily if the user chooses to.
They cannot decrypt your data while sitting, so IMAP cannot work.
Go ahead and explain what you mean. I don’t believe you & think you’re just parroting their corpo speak.
It’s actually fairly simple: if the server never has access to the keys or the plaintext of messages (or calendar events, etc.), then you need a client tool to handle decryption and encryption operations.
They use PGP, and they have implemented this feature in a way that it’s completely transparent to the user to make it mainstream. So they chose building dedicated tools (bridge, web client), rather than letting users use their own tools, because the PGP tooling sucks hard and it’s extremely inaccessible for the general population.
This means that you need a fat client, whatever you do, or otherwise the server will have access to the data and there is no e2ee. Instead of using enigmail or other PGP plugins/tools, they built the bridge.
if the server never has access to the keys or the plaintext of messages (or calendar events, etc.), then you need a client tool to handle decryption and encryption operations.
Proton stores your keys, and you have the decryption password. How do you think they handle password-based logins? Only the user should ever generate and store the private key. All they need now is your decryption password & they can read your messages. This is reason #1 not to trust Proton.
They use PGP, and they have implemented this feature in a way that it’s completely transparent to the user to make it mainstream.
It isn’t transparent, because most users aren’t running their own frontend locally and tracking all the source code changes. They’ve already violated the first rule of PGP privacy by having your private key. Now you’re merely trusting them to not send you a custom JS payload to have your decryption password sent to the server. How many users are actually utilizing their hidden API to ensure that decryption/encryption is only done client-side? If they have your private key, how many users do you think are using long enough passwords to make cracking their password more challenging? This is reason #2 to not trust Proton.
PGP tooling sucks hard and it’s extremely inaccessible for the general population.
This is just entirely inaccurate and you’ve failed to provide any "proof’ for your generalizations here.
This means that you need a fat client, whatever you do, or otherwise the server will have access to the data and there is no e2ee.
If you actually understood PGP you’d know you can generate and use local-only keys with IMAPS and have support to use any IMAP client. Furthermore, the other apps by Proton like Proton Pass, Calendar, etc… all use undocumented APIs that they have yet to implement in their bridge using standard protocols like CalDav/CardDav/JSON or whatever else in order to be able to integrate with local tools. There is no security benefit in their implementation other than to lock you into a walled garden and give you a false sense of security.
Proton stores your keys
Proton stores an encrypted blob.
All they need now is your decryption password & they can read your messages
“All they need now is your private key”. It’s literally a secret, they use
bcryptand then encrypt it. Also, “they” are not generally in the threat model. “They” can serve you JS that simply exfiltrates your email, because the emails are displayed in their web-app, they have no need to steal your password to decrypt your key and read your email…It isn’t transparent, because most users aren’t running their own frontend locally and tracking all the source code changes.
Probably we misunderstand what “transparent” means in this context. What I mean is that the average user will not do any PGP operation, in general. Encryption happens transparently for them, which is the whole thing about Proton: make encryption easy and default.
Now you’re merely trusting them to not send you a custom JS payload to have your decryption password sent to the server.
Again, as I said before, they control the JS, they can get the decrypted data without getting the password…? You always trust your client tooling. There is always a point where I trust someone, be it the “enigmail” maintainers, Thunderbird maintainers (it has access to messages post-decryption!), the CLI tool of choice etc.
How many users are actually utilizing their hidden API to ensure that decryption/encryption is only done client-side?
I mean, their clients are open-source and have also been audited?
If they have your private key, how many users do you think are using long enough passwords to make cracking their password more challenging?
I don’t know. But here we are talking about a different risk: someone compromising Proton, getting your encrypted private key, and starting bruteforcing
bcrypt-hashed-and-salted passwords. I find that risk acceptable.This is just entirely inaccurate and you’ve failed to provide any "proof’ for your generalizations here.
See other post.
If you actually understood PGP you’d know you can generate and use local-only keys with IMAPS and have support to use any IMAP client.
Care to share any practical example/link, and how exactly this means not having a fat client that does the encryption/decryption for you?
There is no security benefit in their implementation other than to lock you into a walled garden and give you a false sense of security.
Right, because *DAV protocol are so secure. They all support e2ee, right…? There is a security benefit, and the benefit is trusting the client software more than a server, especially if shared. You can export data and migrate when you want easily, so it’s really a matter of preference.
Proton stores an encrypted blob.
It doesn’t matter that your private key is stored on their servers encrypted/hased or whatever. If you were simply storing it there, that would not be an issue. The problem is that you’re also logging in and relying on whatever JS is sent to you to only happen client-side.
Probably we misunderstand what “transparent” means in this context. What I mean is that the average user will not do any PGP operation, in general. Encryption happens transparently for them, which is the whole thing about Proton: make encryption easy and default.
Most users aren’t sending emails from their Proton to other Proton users either. Furthermore, the users that want encryption seek it out. They don’t need to use Proton for encryption, especially when it would be easy for them to get an unknowing users decryption password.
Again, as I said before, they control the JS, they can get the decrypted data without getting the password…? You always trust your client tooling. There is always a point where I trust someone, be it the “enigmail” maintainers, Thunderbird maintainers (it has access to messages post-decryption!), the CLI tool of choice etc.
Yes, you have to trust source code somewhere, but with Thunderbird or other mail clients that is open source and their apps are signed or you can reproducibily build from source. However, once that is built it doesn’t change. With Proton, everytime you visit their site you don’t know for sure that it hasn’t changed unless you’re monitoring the traffic. A government is much more likely to convince Proton to send a single user a custom JS payload, than to modify the source code of Thunderbird in a way that would create an exploit that bypasses firewalls, system sandboxing, etc.
I mean, their clients are open-source and have also been audited?
You mean their PWA/WebView clients that can still send custom JS at anytime, or their bridge?
Care to share any practical example/link, and how exactly this means not having a fat client that does the encryption/decryption for you?
First, explain what you mean by a fat client? GnuPG is not a fat client.
Right, because *DAV protocol are so secure. They all support e2ee, right…? There is a security benefit, and the benefit is trusting the client software more than a server, especially if shared. You can export data and migrate when you want easily, so it’s really a matter of preference.
Being able to export things is a lot different than being able to use Thunderbird for Calendars, or a different Contacts app on your phone. DAV is as secure as the server you run it on and the certificate you use for transport.
Proton mail has some extra (security?) feature, or they just lack smtp support, and you cannot directly use it on thunderbird. They offer a “bridge” app which allows you to do it, I just use that.
Proton’s whole thing is it’s meant to be secure, private, encrypted, etc. To achieve that, it requires the Proton app or website as an endpoint, so your email never leaves Proton’s environment. As long as your reading your email in the Proton app/site, they can guarantee its privacy and security.
Once it sends your emails to Thunderbird or another client, it’s leaving the Proton environment, and they can no longer control it. You’re sacrificing the inherent privacy/security of Proton when you use Thunderbird (they claim).
All of that being said, it’s an absolutely bullshit excuse. Tutanota does this same shit, only they don’t even provide the bridge like Proton does.
It’s true it’s technically more secure for those emails to stay in the Proton environment, but they’re still your god damn emails, and they should operate like every other email service by giving the user the option to export those emails in whatever way they damn well please, for free.
It’s just more platform lock-in garbage. Your emails are trapped on their server, so they’ll be no moving away to a different provider easily.
Corps have used that BS excuse for ages. The whole “your phone is more secure when we control it” is a garbage BS line. Make it open source, give developers the tools & they’ll make any app more secure than some bureaucracy that is constantly influenced by the national security agencies.
None of those actually document their API nor provide source for the backend server code. Other than building hydroxide from PRs for CalDav, are there even any other open source implementations of CardDav/CalDav for Proton? I can’t find a single implementation of Proton Pass that allows you to sync your passwords locally and be used in a different app. There is no shortage of people complaining about this:
https://protonmail.uservoice.com/forums/932842-proton-calendar/suggestions/8985673-cardav-caldav-support https://brainbaking.com/post/2023/01/goodbye-protonmail/ https://minutestomidnight.co.uk/blog/email-migration-from-proton-to-mailbox/
Why would anyone be interested in efforts on a platform with a closed-source backend and that is not developer focused? Not to mention, entirely unnecessary why you should have to use a bridge gateway in the first place with IMAPS & PGP/GPG, CalDav & CardDav. Like I said, Proton is engaged in some questionable practices.
Why would anyone be interested in efforts on a platform with a closed-source backend and that is not developer focused?
Because most people don’t care about those particular things. Almost all the world uses completely proprietary tools (Gmail) that also violate your privacy.
Not to mention, entirely unnecessary why you should have to use a bridge gateway in the first place with IMAPS & PGP/GPG, CalDav & CardDav. Like I said, Proton is engaged in some questionable practices.
It’s not unnecessary, it’s the result of a technical choice. A winning technical choice actually. PGP has a negligible user-base, while Proton has already 100 million accounts. I would be surprised if there were 10 million people actually using PGP. They sacrificed the flexibility and composability of tools (which results almost always in complexity) and made an opinionated solution that works well enough for the mainstream population, who has no interest in picking their tools and simply expects a Gmail-like experience.
And if you really have stringent requirements, they anyway provided the bridge, so that you can have that flexibility if it’s really important for you.
IMAPS & PGP/GPG, CalDav & CardDav
- IMAPs is just IMAP on TLS, so it does not have anything to do with e2ee in this context.
- PGP/GPG is what they use. They just made a tool that is opinionated and just works, rather than one which is more flexible but also more complex. Good choice? Bad choice? It’s a choice.
- *DAV clients expect cleartext data on the server. If you encrypt the data, you need to build all this logic into the clients, and you are not following the standard anymore, which means you will anyway be bound to your client only (and those which implement compatibility). Proton decided that they want to implement e2ee calendar, and they decided to roll their own thing. It’s up to everyone to decide whether e2ee is a more important feature than interoperability with other tools. I don’t care about interoperability, for example, and I’d take e2ee over that.
IMAPs is just IMAP on TLS, so it does not have anything to do with e2ee in this context.
If you use GnuPG or one of the GUI implementations it does.
You do realize e2ee merely means that two users share public keys when they communicate in order to decrypt the messages they receive, right?
*DAV clients expect cleartext data on the server. If you encrypt the data, you need to build all this logic into the clients, and you are not following the standard anymore, which means you will anyway be bound to your client only (and those which implement compatibility).
You’re talking about people paying for cloud services that manage everything for them. Nothing to stop you from hosting your own on an encrypted drive. EteSync does E2E already, and there is already a plethora of apps supporting PGP on Android and Desktop to encrypt/decrypt messages.
