I'm obviously not happy for users who can't use TB now, but this external GPG-client stuff has to die. It never was userfriendly, and is only safe because the target audience is so small nobody bother. Passing around secrets on stdout?
And how is stdout not secure? We're talking about pipes here, not terminals.
Your first sentence was great, but the whole JS rant didn't land. I can't see how side-channels are relevant unless an attacker is already in the system, at which point they could just grab the plaintext.
So with evidence to the fact that TB does indeed execute attacker-supplied JS I would like to ask for a reference for your claim.
I initially tried to fix this by messing with my GPG keychain, because my underlying assumption was that they shared keychains. Imagine my shock when I realised my assumption was wrong! Fortunately I didn't lose anything important. Either way, having to maintain separate keychains is already enough of a deal-breaker for me... Maybe it will improve over time. I guess I'll have to wait and see, as I didn't back up my TB68 profile, so I can't downgrade :(
It's a small team, and this was announced I think nearly a year ago. It's a pity that apparently the import isn't without issue, but I can see how they expect expert users to be able to fix any problems they encounter.
The whole multiple keychain-thing is or was not communicated clearly anywhere ever, I've stumbled on this before. That's part of the bad design though, a keychain file would have made so much more sense and be easier to reason about than configuring it through arcane gpg incantations. I steered clear of it, but I'm surprised that Enigmail supported it (did it?).
Anyway, one 'internal' ring is a very good idea, and I'm happy TB went that way. That was a very conscious decision, as Openpgp.js development is much more active and open, so don't count on this changing.
The new UI could use some polishing (one or zero click encryption please!) but generally I am happy, and happy that I don't need Enigmail anymore.
- The main issue is that your private key is supposed to be secret – not uploaded to a server you don't control. Of course Protonmail encrypts it, but passphrases are supposed to be an additional layer of security, not the only one. If Protonmail has a data breach, is compelled to surrender your keys or turns out to be untrustworthy, your messages are only as secure as your password.
- You cannot control when a web app is updated or verify that everyone else got the same update. So Protonmail – or an attacker that took control of their systems – could give you an update that gives them your unencrypted keys. That may be mostly a theoretical issue because few people do that with their local software either. Still, I'd trust the Debian/Ubuntu repositories more.
- Web apps have additional attack surfaces compared to local software. Malicious browser extensions can't access the data of local software, nor is local software suspectible to things like XHR attacks.