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.
(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
“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.
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 🤣🤣
Capitalism is weird? Ok, but this is what we have.
And that they decided to go with RPM and DEB instead of just doing a Flatpak
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.
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.
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 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
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.
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
