That all makes sense. You described yourself as a non-techie, so I misunderstood and thought you had assumed that all emails had to go through their portal.
You're correct that Tuta doesn't support PGP or S/MIME, which I didn't realize. I assumed that any email service that has the word "privacy" on their website would support both. I don't use personal email for sensitive communications, so I'm not in the habit of using PGP or S/MIME, but still... come on.
Their reasoning seems a bit silly. They say they don't support PGP because it doesn't encrypt the subject line, and it doesn't support post-quantum algorithms or forward secrecy. That's, at most, a warning line in the GUI, not something you just don't implement.
They say they don't implement S/MIME because of EFail, a seven year old vulnerability. They can't confirm that all external services have a mitigation in place for it. But again, just put a warning on the UI. Could even build a list of external providers that mitigate it and only show the warning if the user is sending to a system not on the list.
There are a lot of places on Tuta's website where they say they're working on features but don't specify a timeline, and a quick scan through their github issues finds some conversations where they indicate developer resources are low and they're focused on post quantum encryption first, but they said that for years. Seems they didn't implement basic features because they wanted the one big QC feature. They stated in 2020 that they intend to support PGP and Autocrypt, but they removed those from their roadmap. They're not a current priority.
"Once our PQ-encryption is in place we can consider how to best interop with others keeping benefits of perfect secrecy and post-quantum encryption." So it looks like they're letting Perfect be the enemy of Good.
Yep, I can totally see the walled garden aspect. If you want PGP, Autocrypt, or S/MIME, find another provider until Tuta gets around to implementing them. A lot of their communications read as though they don't have enough development staff to chew what they're biting off.
ETA: I don't see any scaling option in their desktop app, but you can launch it with GDK_DPI_SCALE=1.25 (or some other number) to embiggen it.
It's me, I do it. But only when I need something to do to stay awake in hour five of today's meetings to address the "quick turnaround" patch that I finished coding three weeks ago, but now they want a label to change and no one on the six teams that have somehow become involved seems to know who owns the package that the field the label represents belongs to, but they're absolutely certain we need to programmatically retrieve the text in case the package owner changes it at some point, and someone remembers that the original developer wrote code to get the label text 16 years ago, but it was removed from the program two years before the project started using source control, and they have an old installer around here somewhere that we can decompile or trace with Wireshark to get the right RPC name (sharing their screen while they have a rummage for it, natch), and someone else volunteers that they might know how to get a version of the server application from around that time since the client and server versions have to match, but it's technically the intellectual property of a different subcontractor who was just a guy in Alaska who passed away five years ago, but they're sure they can convince his estate to burn it to a disk and mail it to me if they can just find the contact information...