bartbutler
bartbutler on Hacker News
That's not a bad idea, I'll see what people think. Note that clicking on the unsubscribe link will unsubscribe you to whatever comms preference was specified in the sending and tell you what it was.
Hey, Proton CTO here. There was a bug, and we fucked up. Support should have reported it up the chain and acknowledged this. Things happen, especially at scale, but we take comms consent seriously and will fix it.
We (Proton) have had our own CAPTCHA for a year or more now.
We aren't physically located in the US.
We do support automatic forwarding, have since last fall.
The author mentioned WKD but was mistaken. The culprit was keys.openpgp.org, not WKD.
There aren't any links between Proton and Crypto AG, none at all.
This is Bart, Proton CTO here. For clarity, the issue mentioned here only impacts Proton Mail Bridge, our desktop IMAP/SMTP gateway to Proton Mail encrypted email.
The fact that Bridge and its client can become desynchronized sporadically for some users is a high priority issue we have been working on. Bridge is open source, and as a result relies upon open-source components, and the root cause is an architectural issue in a library that Bridge uses to implement IMAP. When there are network issues, this library returns errors to email clients.
Unfortunately, there are hundreds of email clients, and some email clients don’t handle errors properly, and this leads to desynchronization.
Our error tracking shows this does not happen often (1-2% of Bridge users) and the symptom is usually incorrect display of messages or read/unread status which is fixed with an inbox resynchronization. There are cases where a combination of a desynchronized mailbox and a specific series of user actions can lead to accidental email deletion, but this is far rarer than desynchronization. Our implementation tries as hard as possible to avoid this. If you find you are missing an email, our implementation works around the issue by placing it in a users’ All Mail folder.
As Bridge is open source, updates on this issue have always been publicly posted on GitHub. Addressing this issue at the source requires replacing the core IMAP library. Unfortunately, there are no FOSS IMAP libraries that are sufficiently well maintained. Therefore, the solution is to build our own IMAP library called Gluon, which we have been focusing on since this issue was reported to us. You can follow the progress of this open-source project here: https://github.com/ProtonMail/gluon
We are not refusing to fix the problem. The only possible solution is writing a new open-source IMAP library which we can maintain ourselves to ensure this class of errors cannot occur again. We have doubled the size of the team working on this this year so it is a priority for us.
We’re confident that this addresses the main sources of desynchronization and will be available in the beta version of Bridge by the end of the year.
As of a month or two ago, it does not redirect to the cleartext site and stays on .onion.
UI refresh, SSO/persistent sessions, and because this crowd might care, the whole app was rewritten from scratch to transition from Angular v1 to React, which simply had to be done and retired an enormous amount of technical debt.
Hi there, I'll ask someone to reach out. In the future, please file a support ticket at: protonmail.com/support-form
It's not a small use case for corporate users where the internal mail is all encrypted. We also have full PGP support and the bridge is fully integrated with this, so we hope the garden aspect will decrease with time, though we expect PGP volume to remain small. You are also heavily discounting the overhead of having users manage their own keys locally in your preferred solution.
We (ProtonMail) don't provide a server-side IMAP/SMTP interface because we don't want to see your cleartext mail. And if you are doing the encryption and key management yourself locally, then you can literally use any email provider you want. The Bridge sidesteps this issue by exposing a local IMAP/SMTP interface and handling the encryption/decryption locally, but there are very good reasons we built it the way we did.
We sent out an update about security features.
It is something we'd like to do, but it's still a little experimental and it hasn't gotten to the top of our priority list yet.
1. ProtonMail implements the OpenPGP standard and is fully interoperable with other OpenPGP email systems.
2. The web app is a single page application so it does not reload on every request.
That said, you are correct that the web app is not appropriate when the threat model includes ProtonMail itself (though you can run the web app locally and thus sidestep the problem). The native clients are better suited in that case.
I also think exploiting it would be extremely difficult. IIRC, it was NIST ECC curves which are hard to make constant time and do not have WebCrypto primitives. We are still going to see what we can do to address this.
You are confusing crypto primitives with a high-level spec like OpenPGP. OpenPGPjs used WebCrypto and node crypto libraries when available for primitives. You still need a library for the OpenPGP stuff.
You are confusing crypto primitives with a high-level spec like OpenPGP. OpenPGPjs used WebCrypto and node crypto libraries when available for primitives. You still need a library for the OpenPGP stuff.
Import/export tool is in beta now and will be available for all users on launch. Export is available now via the web interface but it's a little clunky. The reason this stuff is complex and taking a while is not nefarious, it's because most people don't want just ciphertext when they export their mail.
These are good points, though at this point I think it does make sense to wait a bit to clean up the deprecated stuff, given that a lot was waiting on this release and we'll probably drop the old stuff in a month or so.
Re: API access control, sure they do, but given that export is essentially calling 'GET message X' it's not as if we can restrict that to a subset of users.
1. Mobile apps are native, not web views
2. That's not what the TLS key was subpoenaed for--it was a very different system with a set of vulnerabilities we don't have, including a server-side encrypt mode and non-PFS TLS ciphers.
3. Again, if we are part of your threat model, you can run the web client locally and audit it yourself if this is a concern.
> You're expecting us to believe nobody on your team would take a payout from or be coerced by US LEO's or spooks. That's crazy.
No, we're saying that we don't store the data partly so that such a scenario isn't available because historical data simply doesn't exist.
> It's better to not put you in that position of us having to trust you like that.
Look, we freely admit that you can't verify that we do this. If we are part of your threat model, you probably shouldn't rely on us doing it. If we aren't, then it's an additional layer of security relative to other providers who explicitly don't. If you receive unencrypted email, which is virtually everyone, those are your two options. Regardless of whether you believe us, we're still going to do it, because it's better for us and its better for users. There is no 'third way' that allows us or anyone else to receive unencrypted mail on your behalf and verifiably not save a copy. The only solution is to not have unencrypted mail, which is part of the reason we spent a year developing easy-to-use PGP interoperability.
The API docs are available on request mostly because we are phasing out some old APIs we don't want people to use and don't have bandwidth to provide support for them.
The bridge and the import/export tool are not yet open source for similar reasons 1) They are both bandwidth intensive, so we'd like to release access to them gradually 2) Part of running a freemium service is giving paid users perks, and one of those is access to closed betas before general release.
Because running PGP software and handling key management locally is way easier than double-clicking on an installer? I don't concede that for a second. Remember that the alternative you want is ciphertext directly via IMAP, which is not at all user-friendly, which is exactly why we didn't do it.
As for the bridge, that is exactly what we'd like to do, as I've said before.
And customer support time and developer time devoted to this would cost money and represents an opportunity cost as well and that's a fact, not a point to be conceded.
I'm not exactly sure where that is in the copy but it is referring to emails between ProtonMail users, not unencrypted mails from outside. It should probably be clarified, but it's tough to tell without context.
We actually have this and have provided it on request. Also, we plan to open-source the bridge, which should alleviate your other concerns.
A bit of both, though the API restriction will be relaxed soon. We'd much prefer to open-source the bridge and have the community contribute there though. Hopefully we can get there soon.