Why is that a fault in logic? The features are orthogonal. One doesn’t restrict the other. All other, normal, email providers allow client side gpg use.
You went to a custom shoe maker and said “make me a custom shoe” then you went back to them and said “I wanted to do it myself! Why won’t you let me change out the insoles in these shoes!”
That mentality is part of the problem. More options is not inherently better, it’s more to maintain, more complexity, more feature requests in that direction (“well can I store a PGP key in the browser that isn’t uploaded to your servers so I can read my non-synced PGP mail”, “can I write mail using that”, “oh I changed my mind, can I convert mail to your PGP key from my PGP key”, “oh I changed my mind again, I’d actually like all my emails changed to my PGP key”, “oh could you sync my PGP key for me”, etc).
It happens all the time, bending over backwards as a company for niche customers that want to use your toaster as a waffle iron rarely works out well.
It’s a simple ask, not bending over backwards. I bet they haven’t touched the email encryption part of code in years, so it doesn’t add any maintenance burden either. I’ve looked at what they do - the only thing they’d need to change is their handling of email headers!
Internally, yes. So, they only allow it if it’s under their control. This wouldn’t be a customer servie nightmare because only people who know how to use it would use it. Plus, their version of PGP doesn’t encrypt the subject.
Why is that a fault in logic? The features are orthogonal. One doesn’t restrict the other. All other, normal, email providers allow client side gpg use.
Put another way…
You went to a custom shoe maker and said “make me a custom shoe” then you went back to them and said “I wanted to do it myself! Why won’t you let me change out the insoles in these shoes!”
Yes, what’s the problem with that? Services should provide as much flexibility as possible.
That mentality is part of the problem. More options is not inherently better, it’s more to maintain, more complexity, more feature requests in that direction (“well can I store a PGP key in the browser that isn’t uploaded to your servers so I can read my non-synced PGP mail”, “can I write mail using that”, “oh I changed my mind, can I convert mail to your PGP key from my PGP key”, “oh I changed my mind again, I’d actually like all my emails changed to my PGP key”, “oh could you sync my PGP key for me”, etc).
It happens all the time, bending over backwards as a company for niche customers that want to use your toaster as a waffle iron rarely works out well.
It’s a simple ask, not bending over backwards. I bet they haven’t touched the email encryption part of code in years, so it doesn’t add any maintenance burden either. I’ve looked at what they do - the only thing they’d need to change is their handling of email headers!
https://github.com/ProtonMail/proton-bridge/issues/320#issuecomment-1350901372
Sounds more like an attempt to kill off gpg to win the market.
Jesus, they literally use GPG and integrate with 3rd party GPG. How did you make that leap?
Internally, yes. So, they only allow it if it’s under their control. This wouldn’t be a customer servie nightmare because only people who know how to use it would use it. Plus, their version of PGP doesn’t encrypt the subject.
What is the benefit to using your own key on top of protons encryption? Why not just use your own encryption with any other provider?
One less email to have? Wdym???