8 ms·

Show HN: Easy Email Encryption inside Gmail (Alpha, Open-Source)

170 points by alooPotato 13y ago

alooPotato 13y ago
We built this extension to see if it was possible to prevent webmail providers from handing over your email data to other parties. We encrypt the email message on the local machine and also prevent gmail from saving a draft of the email to their servers so they never have a record of the raw email text. We think the user experience is pretty great - works inside gmail, users need to know nothing about security or keys and you can send to any other gmail user (you don't have to worry if they have the correct software installed). With any attempt at security and encryption, you usually trade off ease of use with how secure it is. We decided to use symmetric encryption because it made the user experience better. The only downside of course is that the security is only as good as the password the user chooses to encrypt the message with. - we're using the Stanford javascript crypto library here: http://crypto.stanford.edu/sjcl/ - we open sourced our extension here: https://github.com/StreakYC/StreakSecureGmail There have been a few other attempts at this, but they usually require users to understand how encryption works and require that all the users you send emails to have signed up for something (or have a public key somewhere). We think our attempt is ridiculously easy to use. This is a super early experiment/alpha/whatever so we see this as a starting point. Would love to get feedback!
- h34t 13y ago
  Looks slick. Would it be a good idea to link this with a service like https://onetimesecret.com/ https://onetimesecret.com/ for transferring passwords?
- anemitz 13y ago
  What's the suggested method to securely exchange the key? It feels a bit like this is a step backwards in many ways. Being a non-webmail user, how can I benefit from this? If this were an implementation of SMIME/GPG it would be more widely adoptable since anyone with a compatible GMail plugin, desktop, or mobile client could use this. Edit: Good read about JS encryption and its downsides: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/
  - StavrosK 13y ago
    I also couldn't find a link to the source to sort-of audit it, so, caveat user.
    - joebadmo 13y ago
      You mean this? https://github.com/StreakYC/StreakSecureGmail https://github.com/StreakYC/StreakSecureGmail It's right there under "Open Source"
      - StavrosK 13y ago
        Contextual blindness, thanks. EDIT: Audit results: It just uses the SJCL, looks good to me.
  - OmarIsmail 13y ago
    The intention of this isn't to be the most secure solution on the planet - you're not going to be using Gmail if that's the case. Instead we wanted to build a starting point that was A) easy to use, and B) easy to extend. Our initial plan was to use a GPG solution, but that introduced a lot of complexity to the UX and also had other security holes. But the main thing is that if something is too complicated, it's not going to be used by the broader masses - kind of like GPG right now. With this solution only the sender has to have the extension installed to send an encrypted email.
    - gholap 13y ago
      "With this solution only the sender has to have the extension installed to send an encrypted email." Hmm... but to read the mail, even the receiver needs to have the extension. I don't see much point in advertising "only sender needs the extension" bit.
      - alooPotato 13y ago
        I think the distinction is that the receiver need not have signed up or installed anything at the time the message is sent. That is, the sender need not worry if the receiver is currently using SecureGmail, they can send the message now and the receiver can install the extension later.
- CPAhem 13y ago
  This is a good idea, and looks promising. Running it going on other browsers than Chrome would be nice. Is there any way of getting it compatible with the Syncdocs program which does local machine encryption of Google Drive files? It looks like Syncdocs does AES256 http://www.syncdocs.com/encryption-settings-help/ http://www.syncdocs.com/encryption-settings-help/
shravan 13y ago
Heads up - I can't click any of the links in the header to learn about what Streak does.
- Hilyin 13y ago
  Their slideshow div is blocking it, here are the links: https://www.streak.com/about https://www.streak.com/about https://www.streak.com/privacy https://www.streak.com/privacy http://support.streak.com/ http://support.streak.com/ http://blog.streak.com/ http://blog.streak.com/ https://www.streak.com/api/ https://www.streak.com/api/
- OmarIsmail 13y ago
  whoops. fixed.
  - baal80spam 13y ago
    Doesn't look fixed for me?
    - hackmiester 13y ago
      Not fixed for me. user-agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
pcwalton 13y ago
NB: This is Chrome-only.
lmgftp 13y ago
Just curious, but how can we be sure that GMail doesn't continue to do voodoo like uploading a copy of draft without complete transparency? i.e. will this also disable any scripts that would send data to GMail while drafting is in progress, because if not I could see that as a potential hole for a future breach. Something like "while typing a draft, block all upward data triggered by this page" seems appropriate, rather than targeted draft-saving
- anemitz 13y ago
  Yeah, was thinking the same. At the end of the day any type of client-side javascript encryption is insecure since you'd need to prove the browser + runtime + js + algo are all kosher. It's also sort of ironic that this extension is trying to protect your privacy against the same company making both the browser and the email service:)
- OmarIsmail 13y ago
  We do a combination. We add a marker to the secure compose body (only compatible with new Gmail compose) and intercept the draft savings to prevent the drafts of the secure compose from going through to Gmail's servers. You'll see that in the secured compose when it tries to save a draft it says "Draft saving..." "Save failed". And un-secure composes and replies don't get blocked.
zobzu 13y ago
If someone modifies the server side of gmail they can still snoop the email before it gets encrypted. That and being non-standard, so basically forces users to use the same service and gmail
- OmarIsmail 13y ago
  We block the draft from going up to Gmail's servers. Gmail only sees the encrypted version of the body.
  - anemitz 13y ago
    If Google decides to change how they save drafts you're compromised. They also have complete control of the page so any key press or mouse movement you do they can catch.
    - OmarIsmail 13y ago
      Yup, you're right. I tried to inspect and intercept every XHR call that gmail was making to ensure we weren't missing any holes. But it's entirely possible that there's analytics/tracking data that got passed. Like we said, this is a starting point. It's open source. As with any type of security product that has a hope of being good, try and break it and let's fix it together :)
      - tmzt 13y ago
        You could hash the code delivered by Google and throw up a big warning if it has changed. I believe that Google does releases of the entire application at once so this method should detect when a roll-out has occured.
  - ryan-c 13y ago
    Gmail can just edit your code if they want. In a comment on encrypting gtalk, I explained how this can be done: https://news.ycombinator.com/item?id=5858375 https://news.ycombinator.com/item?id=5858375
rdl 13y ago
Seems like it would be better to go with S/MIME or OpenPGP for this. S/MIME would potentially be able to re-use some of the browser's own code for handling certs. Symmetric crypto (like this) is relatively easy to implement, but a usability nightmare. A browser extension is still a lot better than a general webapp for security. I wish someone issued "mail-from" auth personal certs for ~free to end users, integrated into apps for cert request/signing/etc. StartCom's StartSSL sort of does (for "level 1" personal certs), but their cert issuance UI is a huge pain. It really needs to work with the "I have no cert, I'm going to use an app for a specific purpose, I get a cert incidental to signing up for the service, I then can use the cert for other purposes", which none of the x509 crowd really support. WoT on the certs would be cool too (which startcom is trying, but since it's a pain to use, there aren't enough people, so it doesn't work.)
- anemitz 13y ago
  StartSSL is also not a widely accepted CA which means Apple Mail (and others) will likely complain the certificate is not issued by a trusted party. It's an easy fix, but one that shouldn't have to be done. @rdl who is your go-to CA?
  - jbraithwaite 13y ago
    Not rdl but I use Comodo[1] which is free for personal use. - [1] http://www.comodo.com/home/email-security/free-email-certificate.php http://www.comodo.com/home/email-security/free-email-certifi...
  - rdl 13y ago
    StartSSL's roots are in a lot of things, they just don't have the class1 intermediate cert in places like Apple, and as a result it doesn't work by default. Which is pretty annoying, but easily fixed (provide the intermediate cert along with the end-user cert; since the root is already trusted, it does not bring up a warning.)
- alooPotato 13y ago
  Actually we went down the gpg public/private key path first, and realized that was way worse in terms of usability. Even though with symmetric you have to enter the password, at least average users know what that means. Try to get an an average user to do a key exchange, backup their private key or even know what a key is as some other solutions require.....
alooPotato 13y ago
FYI - we thought about this extension for a while but it only took a few hours to actually implement. Mostly because we had a lot of the core platform already built for streak.com - anyone hear have any interest in us opening up a Gmail platform to outside devs? i.e. you could write apps that live inside Gmail using a clean API?
- tmzt 13y ago
  I think this is the major thing that Google is lacking, an true application development platform that anyone can build an application, host it inside of Google, and use internal data sources. App engine feels like it's close to that, but it doesn't confer any special properties onto applications developed on that platform. Why can't I register a widget inside of Gmail or Google Calendar? Why can't I integrate a workflow form or something else into apps without developing a standalone application that only integrates through an API? I'm hoping this is where they're going with Dart, creating a language that can be compiled into Javascript and share the backend connection with official Google apps. SPDY and WebSocket will enable these types of applications, as they won't need independent connections for each API request channel. I can see how Google is cautious about this type of solution, given that it opens a huge XSS footprint, but I think it's the future of the "cloud" applications. For these platforms to become substitutes to native platforms they need to support applications that integrate as deeply as the first-party offerings.
  - lukeschlather 13y ago
    Bigger than XSS, I think that would create API rot (though I think Google is going in that direction already.) The only thing worse than having a proprietary API to interact with your application is to have a proprietary API that can only be run from a proprietary sandbox. On the other hand, Google could make APIs publicly available so someone running on whatever platform could easily call them. This doesn't solve the security problems, but if Google can't trust external people with the API a sandbox isn't going to do a lot of good.
  - arkem 13y ago
    Google App Script might be what you're looking for it's an app development platform that can use internal resources (like GMail) https://developers.google.com/apps-script/ https://developers.google.com/apps-script/
IgorPartola 13y ago
From the Stanford JS Crypto library's page: > (Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks.) The browser is not a secure environment and cannot be. You cannot guarantee security in the browser even if you control the server-side of the application, let alone when someone else does. In other words, Google can still read every bit of email you send/receive in cleartext. The only way I see how one could make something like this work is by creating a browser plugin where the cleartext runs outside the context of the browser process (perhaps in Java?). If cleartext ever exists inside a JavaScript interface, it's game over. I upvoted this post because we do need more discussion of security and especially usability of security. However, unfortunately, this provides no real security.
- benregenspan 13y ago
  While the security granted by this may be imperfect, "no real security" seems like a bit of a stretch. This eliminates the main pathways by which governments obtain access to email (subpoena of the service provider and straightforward interception of the mail as it is transmitted). Combine that with a webmail service like Gmail where the company providing it has a very real incentive to prevent code injection, and with browser vendors being exceptionally fast at finding and patching exploits, and it's hard to say that this isn't far better than nothing at all.
  - IgorPartola 13y ago
    GMail has a very real incentive to read all your mail. As soon as this plugin gets any real traction Google will trivially circumvent it.
    - grimtrigger 13y ago
      Seems unnecessarily pessimistic. AdBlock has been on the chrome store without much issue despite being directly opposed to Google's business model.
dbpatterson 13y ago
Browsers just need to actually get on the security bandwagon and build support for public key crypotagraphy into an api. Then you could generate keys, export them to back them up / use them on different machines, and these solutions would actually be usable. As in, I could type in someone's email address, and it would find their public key and encrypt the message to them. People have known since the 70s that symmetric encryption is just not easy enough to use for normal people (key exchange is hard). We have local storage - why can't be have local keys? Realistically, I bet the way this will mostly be used is that people will exchange keys through an unsecure medium (like, a non-encrypted GMail message, or if people are being clever, GTalk...), and the whole thing will feel good but be nothing that a little bit of work on Googles end couldn't undo.
- LoganCale 13y ago
  It doesn't matter if public keys are exchanged through an insecure medium as long as there is a way to verify them. Someone else seeing the key is not a problem, so Google being able to find them after the fact would be fine. The problem comes from being able to MITM them and swap it out with a fake key controlled by the attacker. Verifying the key fingerprint (using GPG terminology here, don't know how it applies elsewhere) after via another means (ideally voice or video) would confirm it's a legitimate key.
  - ams6110 13y ago
    A cool idea I saw a while back, http://robohash.org http://robohash.org Generating an easy-to-recognize image from the key fingerprint would be a lot more approachable to the casual user than trying to verify a long hexadecimal number. I guess you're then trusting whatever 3rd party handles the image generation.... but at some point you have to trust software that you didn't write yourself.
    - IgorPartola 13y ago
      Collisions and subtle differences that make the two robots look close enough would make this a vector of attack.
smarterat 13y ago
My thanks to you and your team for having developed this. The cost of crypto is, at present, far too high for mainstream use - or so it seems. Undoubtedly, the challenges inherent with its correct implementation are a part of the reason for that high cost, but the media's depiction of the field is certainly no help either. How technical is your audience? It's been posed elsewhere in these comments, but one area that I'm particularly interested in is your proposal for key exchange. For example, your site warns the user to never email or IM their password: that's great advice, but I don't see any suggestion of a suitable alternative. Granted, I would consider your primary audience to be proxy: that is, the recipients of encrypted messages compelled to install your extension on their machine. Your take may be different, and of course these individuals may simply use-it-and-forget-it, but I'm sure that some of them would want to become your users as well. In those cases, the copy for this section may be confusing or thought incomplete. What happens to my plaintext once its recipient has decrypted it? From the source, after passing the encrypted data to sjcl, it looks as though the plaintext is simply appended to the DOM in place of the encrypted message. Are we certain that Google is not performing any kind of DOM analysis? I don't know how Google behaves in this regard; what assurances do I have that my decrypted messages are still secure? With a lack of deeper technical details regarding your implementation (understandable considering your proposed audience), should I assume that you're using the sjcl default of 128 bit AES in CCM mode? Would you consider publishing these details on your website? My apologies if I've overlooked them. I'd like to echo IgorPartola's sentiments and upvote, however little that may be worth. Usability is crypto's silver bullet and any reasoned discussion which furthers our attention to this problem certainly has value in my opinion.
igmor 13y ago
how would you do attachments and search? Big stopper for me for using something like this.
- mtgx 13y ago
  Well you can't do search without at least having the metadata and the title. If you use other PGP methods, you can have that - but then the NSA can still get your metadata and e-mails title.
sldjfwsiojf 13y ago
What is the legality of this? I'm concerned that in general cryptography web products are potentially illegal http://stackoverflow.com/questions/5308601/export-compliance-and-aes256-in-iphone http://stackoverflow.com/questions/5308601/export-compliance... Also, how secure is AES 256 really? My understanding is that something encrypted with AES256 could be decrypted in my lifetime with a few million dollars worth of hardware and dedicated decryption workloads. It is a bit paranoid, but to me somewhat unsatisfactory that in theory someone with a large enough botnet could decrypt 'securely' encrypted data.
Sami_Lehtinen 13y ago
How is key reuse is avoided? It's even harder for users to maintain (separate random) key for every message. All the classical OTP key issues are here. Aka different message, same key, or same message different key (multirecipient). Using passwords is also guaranteed to produce weak keys. For AES128 you'll need at least 20 char completely random key and for AES256 you can double that.
- alooPotato 13y ago
  Agreed - quality of a password is the key. We wanted to start with something that regular people would actually use. Its current;y not the most secure solution - but we were hoping the community could help us with that while preserving a good user experience.
mtgx 13y ago
Why can't Google implement something like this that is very easy to use, themselves - since they "care" about their users' privacy so much?
- phreeza 13y ago
  It breaks email search and context sensitive ads.
- bhashkarsharma 13y ago
  A whiff of those advertising dollars and the "care" flies out of the window. Also, search would not be possible.
drmr 13y ago
It's too bad that firepgp couldn't keep up with the gmail api changes and eventually was aborted. The few times I used it felt pretty good. This chrome-only alpha software obviously is useless for me. Hopefully something more cross-platform comes along at some point.
- alyandon 13y ago
  Same here. I'd pay money for something like FireGPG that worked with gmail.
- unhammer 13y ago
  http://www.mailvelope.com/ http://www.mailvelope.com/ is chrome-release, firefox-alpha – slightly less useless?
jmvidal 13y ago
Mailvelope http://www.mailvelope.com/ http://www.mailvelope.com/ uses OpenPGP and is nicely integrated with gmail.
- hackmiester 13y ago
  Can't wait for it to support signing of mail.
  - unhammer 13y ago
    Can't wait for a Firefox release!
- znq 13y ago
  Mailvelope is excellent. It was the first time that I'm able to convince my non-geek friends to use PGP encrypted emails.
drdaeman 13y ago
Yup, totally secure. Unless Google's secretly forced to add something along the lines of $(document).on("change", "input.streak__password", function () { $.post(...); }); Somewhere inside ton of JavaScript code. Or some three letter agency gets a private part of certificate for mail.google.com and MITMs it all the way they want.
gholap 13y ago
How about adding an "Encrypted reply" option along with the built-in "Reply" and "Reply to all"?

170 points by alooPotato 13y ago

We built this extension to see if it was possible to prevent webmail providers from handing over your email data to other parties. We encrypt the email message on the local machine and also prevent gmail from saving a draft of the email to their servers so they never have a record of the raw email text. We think the user experience is pretty great - works inside gmail, users need to know nothing about security or keys and you can send to any other gmail user (you don't have to worry if they have the correct software installed). With any attempt at security and encryption, you usually trade off ease of use with how secure it is. We decided to use symmetric encryption because it made the user experience better. The only downside of course is that the security is only as good as the password the user chooses to encrypt the message with. - we're using the Stanford javascript crypto library here: http://crypto.stanford.edu/sjcl/ - we open sourced our extension here: https://github.com/StreakYC/StreakSecureGmail There have been a few other attempts at this, but they usually require users to understand how encryption works and require that all the users you send emails to have signed up for something (or have a public key somewhere). We think our attempt is ridiculously easy to use. This is a super early experiment/alpha/whatever so we see this as a starting point. Would love to get feedback!

h34t 13y ago
Looks slick. Would it be a good idea to link this with a service like https://onetimesecret.com/ https://onetimesecret.com/ for transferring passwords?
anemitz 13y ago
What's the suggested method to securely exchange the key? It feels a bit like this is a step backwards in many ways. Being a non-webmail user, how can I benefit from this? If this were an implementation of SMIME/GPG it would be more widely adoptable since anyone with a compatible GMail plugin, desktop, or mobile client could use this. Edit: Good read about JS encryption and its downsides: http://www.matasano.com/articles/javascript-cryptography/ http://www.matasano.com/articles/javascript-cryptography/
- StavrosK 13y ago
  I also couldn't find a link to the source to sort-of audit it, so, caveat user.
  - joebadmo 13y ago
    You mean this? https://github.com/StreakYC/StreakSecureGmail https://github.com/StreakYC/StreakSecureGmail It's right there under "Open Source"
    - StavrosK 13y ago
      Contextual blindness, thanks. EDIT: Audit results: It just uses the SJCL, looks good to me.
- OmarIsmail 13y ago
  The intention of this isn't to be the most secure solution on the planet - you're not going to be using Gmail if that's the case. Instead we wanted to build a starting point that was A) easy to use, and B) easy to extend. Our initial plan was to use a GPG solution, but that introduced a lot of complexity to the UX and also had other security holes. But the main thing is that if something is too complicated, it's not going to be used by the broader masses - kind of like GPG right now. With this solution only the sender has to have the extension installed to send an encrypted email.
  - gholap 13y ago
    "With this solution only the sender has to have the extension installed to send an encrypted email." Hmm... but to read the mail, even the receiver needs to have the extension. I don't see much point in advertising "only sender needs the extension" bit.
    - alooPotato 13y ago
      I think the distinction is that the receiver need not have signed up or installed anything at the time the message is sent. That is, the sender need not worry if the receiver is currently using SecureGmail, they can send the message now and the receiver can install the extension later.
CPAhem 13y ago
This is a good idea, and looks promising. Running it going on other browsers than Chrome would be nice. Is there any way of getting it compatible with the Syncdocs program which does local machine encryption of Google Drive files? It looks like Syncdocs does AES256 http://www.syncdocs.com/encryption-settings-help/ http://www.syncdocs.com/encryption-settings-help/

shravan 13y ago

Heads up - I can't click any of the links in the header to learn about what Streak does.

Hilyin 13y ago
Their slideshow div is blocking it, here are the links: https://www.streak.com/about https://www.streak.com/about https://www.streak.com/privacy https://www.streak.com/privacy http://support.streak.com/ http://support.streak.com/ http://blog.streak.com/ http://blog.streak.com/ https://www.streak.com/api/ https://www.streak.com/api/
OmarIsmail 13y ago
whoops. fixed.
- baal80spam 13y ago
  Doesn't look fixed for me?
  - hackmiester 13y ago
    Not fixed for me. user-agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36

pcwalton 13y ago

NB: This is Chrome-only.

lmgftp 13y ago

Just curious, but how can we be sure that GMail doesn't continue to do voodoo like uploading a copy of draft without complete transparency? i.e. will this also disable any scripts that would send data to GMail while drafting is in progress, because if not I could see that as a potential hole for a future breach. Something like "while typing a draft, block all upward data triggered by this page" seems appropriate, rather than targeted draft-saving

anemitz 13y ago
Yeah, was thinking the same. At the end of the day any type of client-side javascript encryption is insecure since you'd need to prove the browser + runtime + js + algo are all kosher. It's also sort of ironic that this extension is trying to protect your privacy against the same company making both the browser and the email service:)
OmarIsmail 13y ago
We do a combination. We add a marker to the secure compose body (only compatible with new Gmail compose) and intercept the draft savings to prevent the drafts of the secure compose from going through to Gmail's servers. You'll see that in the secured compose when it tries to save a draft it says "Draft saving..." "Save failed". And un-secure composes and replies don't get blocked.

zobzu 13y ago

If someone modifies the server side of gmail they can still snoop the email before it gets encrypted. That and being non-standard, so basically forces users to use the same service and gmail

OmarIsmail 13y ago
We block the draft from going up to Gmail's servers. Gmail only sees the encrypted version of the body.
- anemitz 13y ago
  If Google decides to change how they save drafts you're compromised. They also have complete control of the page so any key press or mouse movement you do they can catch.
  - OmarIsmail 13y ago
    Yup, you're right. I tried to inspect and intercept every XHR call that gmail was making to ensure we weren't missing any holes. But it's entirely possible that there's analytics/tracking data that got passed. Like we said, this is a starting point. It's open source. As with any type of security product that has a hope of being good, try and break it and let's fix it together :)
    - tmzt 13y ago
      You could hash the code delivered by Google and throw up a big warning if it has changed. I believe that Google does releases of the entire application at once so this method should detect when a roll-out has occured.
- ryan-c 13y ago
  Gmail can just edit your code if they want. In a comment on encrypting gtalk, I explained how this can be done: https://news.ycombinator.com/item?id=5858375 https://news.ycombinator.com/item?id=5858375

rdl 13y ago

Seems like it would be better to go with S/MIME or OpenPGP for this. S/MIME would potentially be able to re-use some of the browser's own code for handling certs. Symmetric crypto (like this) is relatively easy to implement, but a usability nightmare. A browser extension is still a lot better than a general webapp for security. I wish someone issued "mail-from" auth personal certs for ~free to end users, integrated into apps for cert request/signing/etc. StartCom's StartSSL sort of does (for "level 1" personal certs), but their cert issuance UI is a huge pain. It really needs to work with the "I have no cert, I'm going to use an app for a specific purpose, I get a cert incidental to signing up for the service, I then can use the cert for other purposes", which none of the x509 crowd really support. WoT on the certs would be cool too (which startcom is trying, but since it's a pain to use, there aren't enough people, so it doesn't work.)

anemitz 13y ago
StartSSL is also not a widely accepted CA which means Apple Mail (and others) will likely complain the certificate is not issued by a trusted party. It's an easy fix, but one that shouldn't have to be done. @rdl who is your go-to CA?
- jbraithwaite 13y ago
  Not rdl but I use Comodo[1] which is free for personal use. - [1] http://www.comodo.com/home/email-security/free-email-certificate.php http://www.comodo.com/home/email-security/free-email-certifi...
- rdl 13y ago
  StartSSL's roots are in a lot of things, they just don't have the class1 intermediate cert in places like Apple, and as a result it doesn't work by default. Which is pretty annoying, but easily fixed (provide the intermediate cert along with the end-user cert; since the root is already trusted, it does not bring up a warning.)
alooPotato 13y ago
Actually we went down the gpg public/private key path first, and realized that was way worse in terms of usability. Even though with symmetric you have to enter the password, at least average users know what that means. Try to get an an average user to do a key exchange, backup their private key or even know what a key is as some other solutions require.....

alooPotato 13y ago

FYI - we thought about this extension for a while but it only took a few hours to actually implement. Mostly because we had a lot of the core platform already built for streak.com - anyone hear have any interest in us opening up a Gmail platform to outside devs? i.e. you could write apps that live inside Gmail using a clean API?

tmzt 13y ago
I think this is the major thing that Google is lacking, an true application development platform that anyone can build an application, host it inside of Google, and use internal data sources. App engine feels like it's close to that, but it doesn't confer any special properties onto applications developed on that platform. Why can't I register a widget inside of Gmail or Google Calendar? Why can't I integrate a workflow form or something else into apps without developing a standalone application that only integrates through an API? I'm hoping this is where they're going with Dart, creating a language that can be compiled into Javascript and share the backend connection with official Google apps. SPDY and WebSocket will enable these types of applications, as they won't need independent connections for each API request channel. I can see how Google is cautious about this type of solution, given that it opens a huge XSS footprint, but I think it's the future of the "cloud" applications. For these platforms to become substitutes to native platforms they need to support applications that integrate as deeply as the first-party offerings.
- lukeschlather 13y ago
  Bigger than XSS, I think that would create API rot (though I think Google is going in that direction already.) The only thing worse than having a proprietary API to interact with your application is to have a proprietary API that can only be run from a proprietary sandbox. On the other hand, Google could make APIs publicly available so someone running on whatever platform could easily call them. This doesn't solve the security problems, but if Google can't trust external people with the API a sandbox isn't going to do a lot of good.
- arkem 13y ago
  Google App Script might be what you're looking for it's an app development platform that can use internal resources (like GMail) https://developers.google.com/apps-script/ https://developers.google.com/apps-script/

IgorPartola 13y ago

From the Stanford JS Crypto library's page: > (Unfortunately, this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks.) The browser is not a secure environment and cannot be. You cannot guarantee security in the browser even if you control the server-side of the application, let alone when someone else does. In other words, Google can still read every bit of email you send/receive in cleartext. The only way I see how one could make something like this work is by creating a browser plugin where the cleartext runs outside the context of the browser process (perhaps in Java?). If cleartext ever exists inside a JavaScript interface, it's game over. I upvoted this post because we do need more discussion of security and especially usability of security. However, unfortunately, this provides no real security.

benregenspan 13y ago
While the security granted by this may be imperfect, "no real security" seems like a bit of a stretch. This eliminates the main pathways by which governments obtain access to email (subpoena of the service provider and straightforward interception of the mail as it is transmitted). Combine that with a webmail service like Gmail where the company providing it has a very real incentive to prevent code injection, and with browser vendors being exceptionally fast at finding and patching exploits, and it's hard to say that this isn't far better than nothing at all.
- IgorPartola 13y ago
  GMail has a very real incentive to read all your mail. As soon as this plugin gets any real traction Google will trivially circumvent it.
  - grimtrigger 13y ago
    Seems unnecessarily pessimistic. AdBlock has been on the chrome store without much issue despite being directly opposed to Google's business model.

dbpatterson 13y ago

Browsers just need to actually get on the security bandwagon and build support for public key crypotagraphy into an api. Then you could generate keys, export them to back them up / use them on different machines, and these solutions would actually be usable. As in, I could type in someone's email address, and it would find their public key and encrypt the message to them. People have known since the 70s that symmetric encryption is just not easy enough to use for normal people (key exchange is hard). We have local storage - why can't be have local keys? Realistically, I bet the way this will mostly be used is that people will exchange keys through an unsecure medium (like, a non-encrypted GMail message, or if people are being clever, GTalk...), and the whole thing will feel good but be nothing that a little bit of work on Googles end couldn't undo.

LoganCale 13y ago
It doesn't matter if public keys are exchanged through an insecure medium as long as there is a way to verify them. Someone else seeing the key is not a problem, so Google being able to find them after the fact would be fine. The problem comes from being able to MITM them and swap it out with a fake key controlled by the attacker. Verifying the key fingerprint (using GPG terminology here, don't know how it applies elsewhere) after via another means (ideally voice or video) would confirm it's a legitimate key.
- ams6110 13y ago
  A cool idea I saw a while back, http://robohash.org http://robohash.org Generating an easy-to-recognize image from the key fingerprint would be a lot more approachable to the casual user than trying to verify a long hexadecimal number. I guess you're then trusting whatever 3rd party handles the image generation.... but at some point you have to trust software that you didn't write yourself.
  - IgorPartola 13y ago
    Collisions and subtle differences that make the two robots look close enough would make this a vector of attack.

smarterat 13y ago

My thanks to you and your team for having developed this. The cost of crypto is, at present, far too high for mainstream use - or so it seems. Undoubtedly, the challenges inherent with its correct implementation are a part of the reason for that high cost, but the media's depiction of the field is certainly no help either. How technical is your audience? It's been posed elsewhere in these comments, but one area that I'm particularly interested in is your proposal for key exchange. For example, your site warns the user to never email or IM their password: that's great advice, but I don't see any suggestion of a suitable alternative. Granted, I would consider your primary audience to be proxy: that is, the recipients of encrypted messages compelled to install your extension on their machine. Your take may be different, and of course these individuals may simply use-it-and-forget-it, but I'm sure that some of them would want to become your users as well. In those cases, the copy for this section may be confusing or thought incomplete. What happens to my plaintext once its recipient has decrypted it? From the source, after passing the encrypted data to sjcl, it looks as though the plaintext is simply appended to the DOM in place of the encrypted message. Are we certain that Google is not performing any kind of DOM analysis? I don't know how Google behaves in this regard; what assurances do I have that my decrypted messages are still secure? With a lack of deeper technical details regarding your implementation (understandable considering your proposed audience), should I assume that you're using the sjcl default of 128 bit AES in CCM mode? Would you consider publishing these details on your website? My apologies if I've overlooked them. I'd like to echo IgorPartola's sentiments and upvote, however little that may be worth. Usability is crypto's silver bullet and any reasoned discussion which furthers our attention to this problem certainly has value in my opinion.

igmor 13y ago

how would you do attachments and search? Big stopper for me for using something like this.

mtgx 13y ago
Well you can't do search without at least having the metadata and the title. If you use other PGP methods, you can have that - but then the NSA can still get your metadata and e-mails title.

sldjfwsiojf 13y ago

What is the legality of this? I'm concerned that in general cryptography web products are potentially illegal http://stackoverflow.com/questions/5308601/export-compliance-and-aes256-in-iphone http://stackoverflow.com/questions/5308601/export-compliance... Also, how secure is AES 256 really? My understanding is that something encrypted with AES256 could be decrypted in my lifetime with a few million dollars worth of hardware and dedicated decryption workloads. It is a bit paranoid, but to me somewhat unsatisfactory that in theory someone with a large enough botnet could decrypt 'securely' encrypted data.

Sami_Lehtinen 13y ago

How is key reuse is avoided? It's even harder for users to maintain (separate random) key for every message. All the classical OTP key issues are here. Aka different message, same key, or same message different key (multirecipient). Using passwords is also guaranteed to produce weak keys. For AES128 you'll need at least 20 char completely random key and for AES256 you can double that.

alooPotato 13y ago
Agreed - quality of a password is the key. We wanted to start with something that regular people would actually use. Its current;y not the most secure solution - but we were hoping the community could help us with that while preserving a good user experience.

mtgx 13y ago

Why can't Google implement something like this that is very easy to use, themselves - since they "care" about their users' privacy so much?

phreeza 13y ago
It breaks email search and context sensitive ads.
bhashkarsharma 13y ago
A whiff of those advertising dollars and the "care" flies out of the window. Also, search would not be possible.

drmr 13y ago

It's too bad that firepgp couldn't keep up with the gmail api changes and eventually was aborted. The few times I used it felt pretty good. This chrome-only alpha software obviously is useless for me. Hopefully something more cross-platform comes along at some point.

alyandon 13y ago
Same here. I'd pay money for something like FireGPG that worked with gmail.
unhammer 13y ago
http://www.mailvelope.com/ http://www.mailvelope.com/ is chrome-release, firefox-alpha – slightly less useless?

jmvidal 13y ago

Mailvelope http://www.mailvelope.com/ http://www.mailvelope.com/ uses OpenPGP and is nicely integrated with gmail.

hackmiester 13y ago
Can't wait for it to support signing of mail.
- unhammer 13y ago
  Can't wait for a Firefox release!
znq 13y ago
Mailvelope is excellent. It was the first time that I'm able to convince my non-geek friends to use PGP encrypted emails.

drdaeman 13y ago

Yup, totally secure. Unless Google's secretly forced to add something along the lines of $(document).on("change", "input.streak__password", function () { $.post(...); }); Somewhere inside ton of JavaScript code. Or some three letter agency gets a private part of certificate for mail.google.com and MITMs it all the way they want.

gholap 13y ago

How about adding an "Encrypted reply" option along with the built-in "Reply" and "Reply to all"?