3 ms·

Sorry, but I honestly believe that "oh PGP is so hard for non techies, but those evil technical people ignore this important issue" is a myth. Unless we're talk

Sorry, but I honestly believe that "oh PGP is so hard for non techies, but those evil technical people ignore this important issue" is a myth. Unless we're talking about command-line gpg application, hah. Take Enigmail for example. It's nearly as non-technical as possible, with key IDs being the only "technical" thing that's visible in the key list. Key generation just asks you for account to use and expiry date. Encryption is a single checkbox. And the rest of the features are mostly behind "Advanced..." buttons and aren't necessary for the most basic operation. If you insist on the contrary, please do some concrete examples where it's a "highly technical interface". There are a lot of issues with PGP adoption, yet most important are two: 1) popular MUA developers just don't give a fuck about crypto 2) too many users use webmail where PGP support is generally a kludge at best 3) "noone does that anyway so why bother" attitude. The other issues are too minor compared to those three.

toyg 12y ago
Item 2 I think is the real killer. Nobody "normal" even uses MUAs anymore; GMail effectively killed that world. They use Outlook at work, where the configuration is up to their system administrator so they don't have to know anything, and then they go home and use GMail and again it's literally zero config. Back in the 90s, when people were actually setting up MUAs at home, they had to know about options etc; at that time, crypto was a bit difficult to implement and servers didn't really support it anyway, but still there was a slim chance that users would actually have to bother looking at "email preferences". That window is over. Now nobody knows anything about email and they are not expected to, so there is no chance they'll ever get to that finally-mature Enigmail screen.
- drdaeman 12y ago
  <rant> 2 boils down to issue 1 and is blocked by issue 3. Web-based MUAs are still software. They could support PGP and/or S/MIME just fine. All what's necessary is to provide an API and browser plugin (so the website won't have _any_ access to plaintexts and keys) implementation. Like some sort of secure <textarea> that's completely out of website's control (except for basic visual styling and some hinting like what's to show as recipient selection) and only sends an event when writing's done and encrypted message is ready. Not trivial, but well possible. Given that Google is also a browser vendor and it's not unusual to them to push for features based on their product demands - certainly possible. But, nope. No big player on the market seem to care about providing user with proper cryptographic protection. The one with user in actual control instead of "oh, crypto's scary and we won't allow you to be scared - we'll manage everything for you, trust us, we'll handle your data good". Just look at the state of X.509 certificate management in any browser or email client - contrary to most PGP plugins, it's real obscure highly technical UI hidden beneath 4-6 mouse clicks, that hadn't any significant changes since '90s. So, we're still stuck with passwords instead of certificates. And S/MIME failed. And that's because most don't care any much (if at any) about the issue and even if they do they seem to be perfectly satisfied with "your communications are secure with bank-grade encryption blah blah blah"-type marketing speak. </rant>
  - rakoo 12y ago
    Continuing in your rant: technically, you still expect the server to behave correctly and ask your browser for the encrypted text through a special <textarea>. If the server doesn't want to send the it, it won't. What I see is going the other way around: have the browser detect a standard <textarea> and provide control to automatically encrypt what you typed. Something ala https://www.mailvelope.com/ https://www.mailvelope.com/. No changes in the websites. You can do it today (well, if you have the good plugin/browser). Now I think the real hard problem is not encryption itself but key distribution. You need to find a way to reliably tell other people "This is my key", but you need some interactive way so that I don't need to wait for you manually sending me your key in order for me to send you something encrypted... I believe XMPP is much better suited for that (there are ways to exchange content between people, even when they are not connected, for instance through services), so maybe Gmail could build something on top of SMTP+XMPP to exchange keys. And that still wouldn't be truly authenticated, only optimistically, because in the end trust is something only users can set.
    - drdaeman 12y ago
      Sure. The site shouldn't be able to imitate your textarea. First, it should have no access to your keyring and whatever, so it won't be able to crudely imitate the UI. Then, browser should have some sort of indication outside of site's control, that shows whenever you're editing text in a secure area or not. As for key distribution - if it would work opportunistically, it would be still a great achievement. Like, all emails I send are signed, and recipient MUA can figure out my key ID from those and retrieve it automatically. Then proceed to suggesting encrypting the correspondence. If so, the UI should clearly indicate that communications are encrypted but noticeably warn that identity's not verified. That is, solving one problem at a time, I guess. Maybe I'm wrong, though.
  - toyg 12y ago
    > All what's necessary is to provide an API and browser plugin As soon as you say browser plugin, you've failed. Plugins mean deployment headaches, sandbox trust etc etc. It's what Java used to do, it's what Flash used to do, we know it just doesn't work in the long run. Even extensions are troublesome, what with browsers constantly breaking compatibility every other day. There is a reason big brands don't even develop simple extensions these days.

toyg 12y ago

Item 2 I think is the real killer. Nobody "normal" even uses MUAs anymore; GMail effectively killed that world. They use Outlook at work, where the configuration is up to their system administrator so they don't have to know anything, and then they go home and use GMail and again it's literally zero config. Back in the 90s, when people were actually setting up MUAs at home, they had to know about options etc; at that time, crypto was a bit difficult to implement and servers didn't really support it anyway, but still there was a slim chance that users would actually have to bother looking at "email preferences". That window is over. Now nobody knows anything about email and they are not expected to, so there is no chance they'll ever get to that finally-mature Enigmail screen.

drdaeman 12y ago
<rant> 2 boils down to issue 1 and is blocked by issue 3. Web-based MUAs are still software. They could support PGP and/or S/MIME just fine. All what's necessary is to provide an API and browser plugin (so the website won't have _any_ access to plaintexts and keys) implementation. Like some sort of secure <textarea> that's completely out of website's control (except for basic visual styling and some hinting like what's to show as recipient selection) and only sends an event when writing's done and encrypted message is ready. Not trivial, but well possible. Given that Google is also a browser vendor and it's not unusual to them to push for features based on their product demands - certainly possible. But, nope. No big player on the market seem to care about providing user with proper cryptographic protection. The one with user in actual control instead of "oh, crypto's scary and we won't allow you to be scared - we'll manage everything for you, trust us, we'll handle your data good". Just look at the state of X.509 certificate management in any browser or email client - contrary to most PGP plugins, it's real obscure highly technical UI hidden beneath 4-6 mouse clicks, that hadn't any significant changes since '90s. So, we're still stuck with passwords instead of certificates. And S/MIME failed. And that's because most don't care any much (if at any) about the issue and even if they do they seem to be perfectly satisfied with "your communications are secure with bank-grade encryption blah blah blah"-type marketing speak. </rant>
- rakoo 12y ago
  Continuing in your rant: technically, you still expect the server to behave correctly and ask your browser for the encrypted text through a special <textarea>. If the server doesn't want to send the it, it won't. What I see is going the other way around: have the browser detect a standard <textarea> and provide control to automatically encrypt what you typed. Something ala https://www.mailvelope.com/ https://www.mailvelope.com/. No changes in the websites. You can do it today (well, if you have the good plugin/browser). Now I think the real hard problem is not encryption itself but key distribution. You need to find a way to reliably tell other people "This is my key", but you need some interactive way so that I don't need to wait for you manually sending me your key in order for me to send you something encrypted... I believe XMPP is much better suited for that (there are ways to exchange content between people, even when they are not connected, for instance through services), so maybe Gmail could build something on top of SMTP+XMPP to exchange keys. And that still wouldn't be truly authenticated, only optimistically, because in the end trust is something only users can set.
  - drdaeman 12y ago
    Sure. The site shouldn't be able to imitate your textarea. First, it should have no access to your keyring and whatever, so it won't be able to crudely imitate the UI. Then, browser should have some sort of indication outside of site's control, that shows whenever you're editing text in a secure area or not. As for key distribution - if it would work opportunistically, it would be still a great achievement. Like, all emails I send are signed, and recipient MUA can figure out my key ID from those and retrieve it automatically. Then proceed to suggesting encrypting the correspondence. If so, the UI should clearly indicate that communications are encrypted but noticeably warn that identity's not verified. That is, solving one problem at a time, I guess. Maybe I'm wrong, though.
- toyg 12y ago
  > All what's necessary is to provide an API and browser plugin As soon as you say browser plugin, you've failed. Plugins mean deployment headaches, sandbox trust etc etc. It's what Java used to do, it's what Flash used to do, we know it just doesn't work in the long run. Even extensions are troublesome, what with browsers constantly breaking compatibility every other day. There is a reason big brands don't even develop simple extensions these days.