No single point at which to apply judicial- and/or rubber-hose cryptography is the big one.
I do agree that the problem-space of attempting to make a reasonable UI for GPG has been explored for a long time with no useful results. I'd love someone to prove me wrong, but it seems like that's a hopeless endeavor.
It is worth asking why, though. I'm not a UI person, so apply appropriate weighting to my opinion. I think this is one area - application of the Unix philosophy to task-driven security software - results in software that only the really invested will use. A combination email encryption/key distribution system with most nonessential options stripped out, targeting one mail client (at least at first) might be simple enough to achieve something closer to Signal-level usability. And the rounding-errors can continue to use the full GPG for our weird open-source rituals.
But who knows. Maybe the entire model is just too complicated for mere mortals.
> the problem-space of attempting to make a reasonable UI for GPG has been explored for a long time with no useful results
Has it? Have we ever had even e.g. 2 reasonably skilled design professionals spend a year trying? That would, I suspect, be much less effort than has gone into Signal et al. But still beyond the resources of volunteer-only FOSS, unfortunately.
I don't think the real problem with OpenPGP is the UI issues. OpenKeychain and K9-Mail together provide a not terrible UI for OpenPGP, and if someone wanted to more tightly integrate them with each other,the UI could probably be improved further.
But PGP-over-SMTP would still leak important metadata, and you would still have problems with forward secrecy and key revocation.
Matrix looks like a much better decentralized solution to build a new email infrastructure on. But there are still metadata leakage issues with federation, and there need to be some standards and an example implementation for email-over-matrix.
> But PGP-over-SMTP would still leak important metadata, and you would still have problems with forward secrecy and key revocation.
I don't think a well-integrated PGP-over-SMTP client would leak any more metadata than the likes of Signal does? Build in a good subkey rotation config and you'd solve most of the forward secrecy issues, and good defaults for how to treat revocation (including better expiry defaults) would resolve that issue. No?
You would still leak unencrypted headers, which in SMTP are numerous and interesting. A client could minimize the useful content of the message headers, but you're always going to have at least the envelope headers available to every intermediate mail host.
I do not know enough to be sure about your point about forward secrecy. You may be right.
”But that's the case with Signal et al as well isn’t it?”
No.
”Because your phone will be connecting to Signal’s servers, your cellular carrier can determine whether or not you are using the service. However, your carrier cannot gather any information about the individuals or groups with whom you are communicating.”
No single point at which to apply judicial- and/or rubber-hose cryptography is the big one.
I do agree that the problem-space of attempting to make a reasonable UI for GPG has been explored for a long time with no useful results. I'd love someone to prove me wrong, but it seems like that's a hopeless endeavor.
It is worth asking why, though. I'm not a UI person, so apply appropriate weighting to my opinion. I think this is one area - application of the Unix philosophy to task-driven security software - results in software that only the really invested will use. A combination email encryption/key distribution system with most nonessential options stripped out, targeting one mail client (at least at first) might be simple enough to achieve something closer to Signal-level usability. And the rounding-errors can continue to use the full GPG for our weird open-source rituals.
But who knows. Maybe the entire model is just too complicated for mere mortals.