2 ms·

<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 necess

<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.
- drdaeman 12y ago
  Whatever, this part doesn't really matter. Just something that works within the browser and is completely isolated from any websites except for well-defined, narrow, simple and secure communication channels. However it's implemented - as a plugin or as a module within the browser's codebase or somehow else - this part is mostly irrelevant. And IIRC, Flash is still a browser plugin. It's just that it's more commonly shipped with browsers. Or maybe I had missed something.
  - toyg 12y ago
    Yeah sorry, I meant that Flash, like Java plugins, is basically dying.
    - drdaeman 12y ago
      It is, but I believe it's not because of its plugin nature, but for another reasons. It's just that Flash had served its role but got replaced with better solutions and is mostly unnecessary anymore. I think I'd be very pleased, if, in a same manner as it happened with Flash, Enigmail would become obsolete and GPG support would be provided by Thunderbird itself.

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.

drdaeman 12y ago
Whatever, this part doesn't really matter. Just something that works within the browser and is completely isolated from any websites except for well-defined, narrow, simple and secure communication channels. However it's implemented - as a plugin or as a module within the browser's codebase or somehow else - this part is mostly irrelevant. And IIRC, Flash is still a browser plugin. It's just that it's more commonly shipped with browsers. Or maybe I had missed something.
- toyg 12y ago
  Yeah sorry, I meant that Flash, like Java plugins, is basically dying.
  - drdaeman 12y ago
    It is, but I believe it's not because of its plugin nature, but for another reasons. It's just that Flash had served its role but got replaced with better solutions and is mostly unnecessary anymore. I think I'd be very pleased, if, in a same manner as it happened with Flash, Enigmail would become obsolete and GPG support would be provided by Thunderbird itself.