Developers at Google have released an experimental tool—for Gmail and other Web-based services—that's designed to streamline the highly cumbersome task of sending and receiving strongly encrypted e-mail.

On Tuesday, the company unveiled highly unstable "alpha" code that in theory allows people to use the Google Chrome browser to generate encryption keys, encrypt e-mails sent to others, and decrypt received e-mails. Dubbed End-to-End, the Chrome extension also allows Chrome users to digitally sign and verify digital signatures of e-mails sent through Gmail and other services. The code implements a fully compliant version of the OpenPGP standard, which is widely regarded as providing virtually uncrackable encryption when carried out correctly.

Further Reading

As Ars documented last year, the problem with just about every e-mail encryption software available today is they require much more time and effort than sending plain-text mail. Microsoft's Outlook application, for instance, frequently crashes when working with the open-source GnuPG encryption suite. Some Outlook users, including this reporter, also experience problems when receiving encrypted e-mail from Mac users, since the encrypted messages are included in an attachment, rather in the body. End-to-End is intended to ease such burdens.

"While end-to-end encryption tools like PGP and GnuPG have been around for a long time, they require a great deal of technical know-how and manual effort to use," Stephan Somogyi, a Google product manager for security and privacy, wrote in a blog post published Tuesday. "To help make this kind of encryption a bit easier, we're releasing code for a new Chrome extension that uses OpenPGP, an open standard supported by many existing encryption tools."

The blog post and the accompany code release were quick to point out that End-to-End is not yet ready for general use. That's because it's extremely hard to create reliable encryption ciphers and it's even harder to securely implement them in software. Security experts are rightly extremely cautious of new algorithms and implementations until they have been vigorously tested by a large number of users over an extended period of time. Google has expanded the scope of its bug bounty programs to offer cash rewards for reports of exploitable security bugs in End-to-End.

"The End-to-End team takes its responsibility to provide solid crypto very seriously, and we don't want at-risk groups that may not be technically sophisticated—journalists, human-rights workers, et al.—to rely on End-to-End until we feel it's ready," a note included with the code release stated. "Prematurely making End-to-End available could have very serious real world ramifications."

At the moment, there's good reason to suspect End-to-End may have extremely serious flaws that could completely compromise an end user's security. Private keys are stored in memory unencrypted and are controlled with code based on JavaScript, a programming language that has suffered its share of vulnerabilities in the past. JavaScript crypto is also subject to so-called side-channel attacks, which ferret out private keys by measuring power consumption, electromagnetic emanations, timing differences, or other indirect channels of a crypto engine. Some of the risk may be minimized by a design in End-to-End that wraps in-memory private keys inside the Chrome security sandbox, but until that protection has been thoroughly tested, it shouldn't be relied on to prevent other apps from being able to pluck out and compromise these crown jewels. Even still, Tuesday's alpha release has already sparked interest among cryptographers and privacy advocates. End-to-End holds great promise.

Separately on Tuesday, Google issued a transparency report that estimated as much as 50 percent of e-mails sent between Gmail and other e-mail providers aren’t encrypted by the transport layer security (TLS) protocol as they travel over the Internet. Google servers have supported such SMTP-TLS encryption for years, but the offering is meaningful only if both services provide it.

According to American Civil Liberties Union technologist Chris Soghoian, ISP Comcast is weeks away from deploying server-to-server e-mail encryption on its network.

Promoted Comments

At the moment, there's good reason to suspect End-to-End may have extremely serious flaws that could completely compromise an end user's security. Private keys are stored in memory unencrypted and are controlled with code based on JavaScript, a programming language that has suffered its share of vulnerabilities in the past. JavaScript crypto is also subject to so-called side-channel attacks, which ferret out private keys by measuring power consumption, electromagnetic emanations, timing differences, or other indirect channels of a crypto engine. Some of the risk may be minimized by a design in End-to-End that wraps in-memory private keys inside the Chrome security sandbox, but until that protection has been thoroughly tested, it shouldn't be relied on to prevent other apps from being able to pluck out and compromise these crown jewels.

Right, but this plugin isn't designed to prevent client-side attacks. It's primary purpose is to encrypt emails in transit. If someone has access to conduct side-channel attacks like power consumption, key-logging, timing differences, etc then no amount of crypto is going to save you.

At the moment, there's good reason to suspect End-to-End may have extremely serious flaws that could completely compromise an end user's security. Private keys are stored in memory unencrypted and are controlled with code based on JavaScript, a programming language that has suffered its share of vulnerabilities in the past. JavaScript crypto is also subject to so-called side-channel attacks, which ferret out private keys by measuring power consumption, electromagnetic emanations, timing differences, or other indirect channels of a crypto engine. Some of the risk may be minimized by a design in End-to-End that wraps in-memory private keys inside the Chrome security sandbox, but until that protection has been thoroughly tested, it shouldn't be relied on to prevent other apps from being able to pluck out and compromise these crown jewels.

Right, but this plugin isn't designed to prevent client-side attacks. It's primary purpose is to encrypt emails in transit. If someone has access to conduct side-channel attacks like power consumption, key-logging, timing differences, etc then no amount of crypto is going to save you.

You still need to secure your client device before using it.

To counter that, the software and the environment that it runs in is part of the client that needs to be secured. It is much harder to secure javascript code running in a browser than code running in some other environments, because of all the potential for cross-site exploits, and such, even with the improvements to sand-boxing. When using alpha client software like this, you should pretty much assume that you don't have a secure client and that any crypto provides is not trustworthy.

66 Reader Comments

Kudos to Google for doing something. I guess they really meant it when they said "Fuck the NSA". Obviously they're an American company, and have to follow the unconscionable NSL things and other warrents, but at least they're working towards something. So yeah, good job, Google.

At the moment, there's good reason to suspect End-to-End may have extremely serious flaws that could completely compromise an end user's security. Private keys are stored in memory unencrypted and are controlled with code based on JavaScript, a programming language that has suffered its share of vulnerabilities in the past. JavaScript crypto is also subject to so-called side-channel attacks, which ferret out private keys by measuring power consumption, electromagnetic emanations, timing differences, or other indirect channels of a crypto engine. Some of the risk may be minimized by a design in End-to-End that wraps in-memory private keys inside the Chrome security sandbox, but until that protection has been thoroughly tested, it shouldn't be relied on to prevent other apps from being able to pluck out and compromise these crown jewels.

Right, but this plugin isn't designed to prevent client-side attacks. It's primary purpose is to encrypt emails in transit. If someone has access to conduct side-channel attacks like power consumption, key-logging, timing differences, etc then no amount of crypto is going to save you.

At the moment, there's good reason to suspect End-to-End may have extremely serious flaws that could completely compromise an end user's security. Private keys are stored in memory unencrypted and are controlled with code based on JavaScript, a programming language that has suffered its share of vulnerabilities in the past. JavaScript crypto is also subject to so-called side-channel attacks, which ferret out private keys by measuring power consumption, electromagnetic emanations, timing differences, or other indirect channels of a crypto engine. Some of the risk may be minimized by a design in End-to-End that wraps in-memory private keys inside the Chrome security sandbox, but until that protection has been thoroughly tested, it shouldn't be relied on to prevent other apps from being able to pluck out and compromise these crown jewels.

Right, but this plugin isn't designed to prevent client-side attacks. It's primary purpose is to encrypt emails in transit. If someone has access to conduct side-channel attacks like power consumption, key-logging, timing differences, etc then no amount of crypto is going to save you.

You still need to secure your client device before using it.

Good point. Still, if you read the FAQ that accompanies the code, you'll see Google developers paid close attention to the issue of side-channel attacks.

At the moment, there's good reason to suspect End-to-End may have extremely serious flaws that could completely compromise an end user's security. Private keys are stored in memory unencrypted and are controlled with code based on JavaScript, a programming language that has suffered its share of vulnerabilities in the past. JavaScript crypto is also subject to so-called side-channel attacks, which ferret out private keys by measuring power consumption, electromagnetic emanations, timing differences, or other indirect channels of a crypto engine. Some of the risk may be minimized by a design in End-to-End that wraps in-memory private keys inside the Chrome security sandbox, but until that protection has been thoroughly tested, it shouldn't be relied on to prevent other apps from being able to pluck out and compromise these crown jewels.

Right, but this plugin isn't designed to prevent client-side attacks. It's primary purpose is to encrypt emails in transit. If someone has access to conduct side-channel attacks like power consumption, key-logging, timing differences, etc then no amount of crypto is going to save you.

You still need to secure your client device before using it.

To counter that, the software and the environment that it runs in is part of the client that needs to be secured. It is much harder to secure javascript code running in a browser than code running in some other environments, because of all the potential for cross-site exploits, and such, even with the improvements to sand-boxing. When using alpha client software like this, you should pretty much assume that you don't have a secure client and that any crypto provides is not trustworthy.

So this is to encrypt email in transit only, so the NSA cannot read them... but does this also mean that once they reach the gmail server they're no longer immediately parsed to better serve adverts to you?

Hmm. Interesting. I appreciate that Google takes a step in this direction. But I suppose they aren't expecting the common user to adopt this. If this is actual end-to-end encryption, Google won't be able to scan the mails for targeted advertising. On a greater scale, this would hurt their current business model.

So this is to encrypt email in transit only, so the NSA cannot read them... but does this also mean that once they reach the gmail server they're no longer immediately parsed to better serve adverts to you?

If so, I'm amazed!

You'll probably get a lot of ads about "Lost your key? Get locksmith services"...

...if the email has the usual signed message with the keyword, "key"

Or you just get generic ads, who knows They get their money either way.

So this is to encrypt email in transit only, so the NSA cannot read them... but does this also mean that once they reach the gmail server they're no longer immediately parsed to better serve adverts to you?

If so, I'm amazed!

I'm kind of amazed too. This means that neither Google nor the NSA nor the FBI can read email at rest on gmail servers. That's especially relevant because the US legal protections for email at rest on a server are currently laughable. This approach can't even be Lavabitted -- getting server keys doesn't let you read mail encrypted with private client keys. That raises the interesting question of whether in the future courts will try to force Google to serve malicious javascript to targets in order to intercept message bodies post-decryption.

Does Google assume that adoption will still be low enough that gmail advertising will be basically unaffected? Are they so pissed off at wanton spying that they're willing to risk foregoing the benefits of mining email bodies? The engineers seemed genuinely angry at NSA tapping private lines connecting data centers; I wouldn't be surprised if there is some technical pride/anger behind this initiative.

Doesn't work on phones, and requires both parties to download the plugin. So if I start using this I can no longer read my email on the phone, and no one can read my emails on their phones either... This pretty much guarantees it won't be widely adopted. Both Google email scanning project and the NSA's are very safe.

Google's point about no extensions for phone browsers is misleading. They have their own email apps they could integrate it into. Besides that they write Chrome and could integrate it into the mobile browser itself if they felt like it.

Having pretty good privacy on GMail will be great. Is there a roadmap, as to how long this will stay in Alpha?

I've been using Syncdocs http://syncdocs.com as a standalone app to encrypt our Google Drive folders. It also does End-to-End encryption, but it uses AES256, not PGP, which means the key exchange is file based, not user based.

It is interesting they chose to do this in the browser - I wonder where drafts are saved?

Are they so pissed off at wanton spying that they're willing to risk foregoing the benefits of mining email bodies? The engineers seemed genuinely angry at NSA tapping private lines connecting data centers; I wouldn't be surprised if there is some technical pride/anger behind this initiative.

That would be my guess. The "Fuck the NSA" sentiment is genuine and widespread inside the company, from engineers up to the very top. It's basically, "You're using the systems we built to spy on people? Fuck that!". Not that different than the way people felt after the Chinese hacking incident a few years ago, compounded by the fact that it's our own damn government this time.

It could be fun to play with, however, don't use a key set that you have used or will use for anything serious. The current version is putting your private key, not just the message at risk. If your private key is compromised, the bad guys can read every encrypted message that has been sent to you. They can also spoof fake messages that are signed by you.

If you play with the alpha, use a test email address and a test key set you assume has been compromised. Pretend that you have emailed the keys directly to the NSA.

I hate to sounds ultra-paranoid or defeatist, but given the extent of the NSA's efforts that have been revealed so far -- including things on the order of intercepting router hardware to install backdoors, auditing closed source software to provide "suggestions", etc -- and given that they have been active since, and in fact were big players in, the inception of modern computing since WWII; do you think it is possible to actually have a secure client?

The question is, can you have a client that you KNOW is secure. The answer is, no. Your computer may not have been compromised, however, you have no way to prove that. If the OS you use is fundamentally hacked, there is nothing you can do. If the hardware you run has built in low level exploits, you are compromised before the first time you hit the power button.

Doesn't work on phones, and requires both parties to download the plugin. So if I start using this I can no longer read my email on the phone, and no one can read my emails on their phones either... This pretty much guarantees it won't be widely adopted. Both Google email scanning project and the NSA's are very safe.

Google's point about no extensions for phone browsers is misleading. They have their own email apps they could integrate it into. Besides that they write Chrome and could integrate it into the mobile browser itself if they felt like it.

I hate to sounds ultra-paranoid or defeatist, but given the extent of the NSA's efforts that have been revealed so far -- including things on the order of intercepting router hardware to install backdoors, auditing closed source software to provide "suggestions", etc -- and given that they have been active since, and in fact were big players in, the inception of modern computing since WWII; do you think it is possible to actually have a secure client?

I doubt that it's possible to maintain a secure client if you are already personally in the crosshairs of the NSA or another major nation state adversary. At least I wouldn't want to try to take on that challenge. But it's still an excellent measure to further hinder dragnet "collect it all" approaches used by NSA and GCHQ. It's also a good protection against the warrantless but currently legal collection of email from servers under the outdated US Stored Communications Act: https://en.wikipedia.org/wiki/Stored_Communications_Act

Nice to see Google doing this. This is to give the NSA the finger for their vacuuming all Google's data being passed between Google's servers (which was unencrypted).

Should be pointed out, this isn't Google saying they won't analyze your e-mail prior to encrypting and keep a lifelong record of those emails (including contents) that they mine (as well as a lifetime record of your searches as well) - which of course has to be turned over to the FBI/NSA etc. when they come to Google and demand it with a warrant (issued by a secret court etc.).

I like Google doing this, but its important to think about what we're providing (via Google or other providers) that could be subverted by political bad actors if they come into power in the future (and after what we've seen with the last 10 years, unfortunately that's not outrageously implausible anymore here in the U.S.) - its important to give it some thought before you continue giving your privacy over to these companies for the future. JMHO...

At the moment, there's good reason to suspect End-to-End may have extremely serious flaws that could completely compromise an end user's security. Private keys are stored in memory unencrypted and are controlled with code based on JavaScript, a programming language that has suffered its share of vulnerabilities in the past. JavaScript crypto is also subject to so-called side-channel attacks, which ferret out private keys by measuring power consumption, electromagnetic emanations, timing differences, or other indirect channels of a crypto engine. Some of the risk may be minimized by a design in End-to-End that wraps in-memory private keys inside the Chrome security sandbox, but until that protection has been thoroughly tested, it shouldn't be relied on to prevent other apps from being able to pluck out and compromise these crown jewels.

Right, but this plugin isn't designed to prevent client-side attacks. It's primary purpose is to encrypt emails in transit. If someone has access to conduct side-channel attacks like power consumption, key-logging, timing differences, etc then no amount of crypto is going to save you.

You still need to secure your client device before using it.

To counter that, the software and the environment that it runs in is part of the client that needs to be secured. It is much harder to secure javascript code running in a browser than code running in some other environments, because of all the potential for cross-site exploits, and such, even with the improvements to sand-boxing. When using alpha client software like this, you should pretty much assume that you don't have a secure client and that any crypto provides is not trustworthy.

S/MIME is supported natively by Outlook, Apple Mail, and the native mail clients of every major smartphone platform. Why try to kludge OpenPGP on there when S/MIME is already built in?

I may be wrong, however, S/MIME requires trusted keys be generated by a Certificate Authority. (You can self sign, however, you loose quite a bit in doing so.) With PGP, you can generate your own key, post the public portion on the MIT Key server, use your private key to encrypt as little as an empty document or as much as a large RAID. In general, PGP is more flexible and open. It is also, by far, the more established, longer lasting option. It has been in heavy public use, dating back to 1991.

I hate to sounds ultra-paranoid or defeatist, but given the extent of the NSA's efforts that have been revealed so far -- including things on the order of intercepting router hardware to install backdoors, auditing closed source software to provide "suggestions", etc -- and given that they have been active since, and in fact were big players in, the inception of modern computing since WWII; do you think it is possible to actually have a secure client?

It's always worthwhile to make things more secure, even if absolute safety cannot be achieved. It's like installing a stronger lock in your front door; criminals (or an oppressive government) could still use a crowbar to break into your house, but that's much less likely so the lock is a big improvement.

I have been using Mailvelope for a while now, which is amazing since it can work pretty much on any website (I can embed an encrypted message here if I chose to and had keys to deliver it to someone). That, and I've communicated with the Dev on that project before, a nice guy who writes good code.

This is a nice option, but I'll stick with Mailvelope for the time being, if nothing more than "if it ain't broke, don't fix it".

Unfortunately, that's the same story as with Hushmail premium in the past. This time backed by much bigger money and based in USA, not in Canada, what I honestly saying see as the greatest disadvantage because of Patriot Act.

Once more step by step.

1. You've got PGP/GPG-encrypted mail in your Gmail Inbox.2. You download a browser applet (closed-souce precompiled bytecode, similar to Java binaries)3. You allow the applet to manage your keypair(s) including your private key(s)4. End of security. Having proprietary browser-based app, made by USA Internet giant, one of those which are in bed with intelligence, meddling with your PGP keys? After Eric Schmidt statements about privacy? After all the lobbying efforts of Google and FB in Europe to undermine EU Privacy Laws?

Good way to attract attention to your correspondence and let Google decide much more precisely which of your messages should be forwarded to 'the good guys'

Unfortunately, that's the same story as with Hushmail premium in the past. This time backed by much bigger money and based in USA, not in Canada, what I honestly saying see as the greatest disadvantage because of Patriot Act.

Once more step by step.

1. You've got PGP/GPG-encrypted mail in your Gmail Inbox.2. You download a browser applet (closed-souce precompiled bytecode, similar to Java binaries)3. You allow the applet to manage your keypair(s) including your private key(s)4. End of security. Having proprietary browser-based app, made by USA Internet giant, one of those which are in bed with intelligence, meddling with your PGP keys? After Eric Schmidt statements about privacy? After all the lobbying efforts of Google and FB in Europe to undermine EU Privacy Laws?

Good way to attract attention to your correspondence and let Google decide much more precisely which of your messages should be forwarded to 'the good guys'

No, the code for the extension is open source. It's built on un-obfuscated Javascript, CSS, and HTML. If you browse to your local Chrome extensions directory you can see the JS, CSS, and HTML that go in to each of your installed extensions. If you think you've been slipped a compromised version, compare hashes with an install on someone else's computer or the published source*.

"Encryption just makes your communications more suspicious" is the worst reason ever not to encrypt. Making life harder for the surveillance state is the civic duty of engaged citizens, like recycling your aluminum cans and voting. If governments can directly break encryption at all, as opposed to using tricks to bypass it, it is certainly rare and difficult. The more people use high-grade encryption to share vacation pictures and plan work schedules, the less practical it becomes to flag mail as suspicious just on the basis of encryption. Also the less practical it becomes to decrypt it all, if brute force decryption were even an option in the first place. Then one day if you have a real secret to share you don't need to worry that encryption will raise any flags, because you and millions of others will have been using it for everything for years.

*OK, this is an inconvenient procedure not practical for many users, but still a lot easier than trying to pick apart opaque bytecode or machine instructions.

No, the code for the extension is open source. It's built on un-obfuscated Javascript, CSS, and HTML. If you browse to your local Chrome extensions directory you can see the JS, CSS, and HTML that go in to each of your installed extensions. If you think you've been slipped a compromised version, compare hashes with an install on someone else's computer or the published source*.

Yes and no... Don't forget about the same origin of Chrome browser AND the extension. There are possibility to create a sort of sandwich-backdoor, when visibly safe JSON/AJAX/CSS-code could trigger 'hidden reserves' of the browser which is despite being based n Open Source Chromium, has closed-source proprietary parts. And, as you mentioned, only geeks will actually check the code. But geeks won't use gmail, will they?

Quote:

"Encryption just makes your communications more suspicious" is the worst reason ever not to encrypt. Making life harder for the surveillance state is the civic duty of engaged citizens, like recycling your aluminum cans and voting. If governments can directly break encryption at all, as opposed to using tricks to bypass it, it is certainly rare and difficult. The more people use high-grade encryption to share vacation pictures and plan work schedules, the less practical it becomes to flag mail as suspicious just on the basis of encryption. Also the less practical it becomes to decrypt it all, if brute force decryption were even an option in the first place. Then one day if you have a real secret to share you don't need to worry that encryption will raise any flags, because you and millions of others will have been using it for everything for years.

*OK, this is an inconvenient procedure not practical for many users, but still a lot easier than trying to pick apart opaque bytecode or machine instructions.

I never discourage anyone from using encryption, rather exactly the opposite. But thumb rule is 'better privacy always comes at costs of less convenience'. And it's not always about technical means only, much more about habits and behaviors. Average users are so lazy and ignorant (sorry about that, but we have to admit this bitter fact) that they're ready to exchange their 'digital souls' for comfort of 'better user experience'. If you put your private PGP key in Dropbox (to share with all your very secure mail-clients), whom to blame?

Again, cheated once, always cheats... Google lost their credibility, as well as FB, all their subsequent tries to make a good face, are nothing but hypocrisy 'en essence', pure whitewashing as well as their 'Reform Government Surveillance' bullshit, check their activities in EU Parliament.

Unfortunately, that's the same story as with Hushmail premium in the past. This time backed by much bigger money and based in USA, not in Canada, what I honestly saying see as the greatest disadvantage because of Patriot Act.

Once more step by step.

1. You've got PGP/GPG-encrypted mail in your Gmail Inbox.2. You download a browser applet (closed-souce precompiled bytecode, similar to Java binaries)3. You allow the applet to manage your keypair(s) including your private key(s)4. End of security. Having proprietary browser-based app, made by USA Internet giant, one of those which are in bed with intelligence, meddling with your PGP keys? After Eric Schmidt statements about privacy? After all the lobbying efforts of Google and FB in Europe to undermine EU Privacy Laws?

Good way to attract attention to your correspondence and let Google decide much more precisely which of your messages should be forwarded to 'the good guys'

It's an open-source extension implementing a open source asymmetric encryption standard as a web browser extension. It's not proprietary in any sense.

No, the code for the extension is open source. It's built on un-obfuscated Javascript, CSS, and HTML. If you browse to your local Chrome extensions directory you can see the JS, CSS, and HTML that go in to each of your installed extensions. If you think you've been slipped a compromised version, compare hashes with an install on someone else's computer or the published source*.

Yes and no... Don't forget about the same origin of Chrome browser AND the extension. There are possibility to create a sort of sandwich-backdoor, when visibly safe JSON/AJAX/CSS-code could trigger 'hidden reserves' of the browser which is despite being based n Open Source Chromium, has closed-source proprietary parts. And, as you mentioned, only geeks will actually check the code. But geeks won't use gmail, will they?

Quote:

"Encryption just makes your communications more suspicious" is the worst reason ever not to encrypt. Making life harder for the surveillance state is the civic duty of engaged citizens, like recycling your aluminum cans and voting. If governments can directly break encryption at all, as opposed to using tricks to bypass it, it is certainly rare and difficult. The more people use high-grade encryption to share vacation pictures and plan work schedules, the less practical it becomes to flag mail as suspicious just on the basis of encryption. Also the less practical it becomes to decrypt it all, if brute force decryption were even an option in the first place. Then one day if you have a real secret to share you don't need to worry that encryption will raise any flags, because you and millions of others will have been using it for everything for years.

*OK, this is an inconvenient procedure not practical for many users, but still a lot easier than trying to pick apart opaque bytecode or machine instructions.

I never discourage anyone from using encryption, rather exactly the opposite. But thumb rule is 'better privacy always comes at costs of less convenience'. And it's not always about technical means only, much more about habits and behaviors. Average users are so lazy and ignorant (sorry about that, but we have to admit this bitter fact) that they're ready to exchange their 'digital souls' for comfort of 'better user experience'. If you put your private PGP key in Dropbox (to share with all your very secure mail-clients), whom to blame?

Chrome is a closed-source build of the Chromium project with a different logo / theme and installation source tracking. This extension (and every other Chrome extension) works fine in Chromium. The only significant user-facing difference between the open-source project and closed source build is that Chromium doesn't come with the proprietary Pepper Flash plugin, although it does work with it.

Chrome is a closed-source build of the Chromium project with a different logo / theme and installation source tracking. This extension (and every other Chrome extension) works fine in Chromium. The only significant user-facing difference between the open-source project and closed source build is that Chromium doesn't come with the proprietary Pepper Flash plugin, although it does work with it.

You're talking about spherical cow in vacuum. Reality is following: under gunpoint, if Google's ass will burn, they will do a lot to save their asses and little to nothing to save yours. Watch Marissa Mayer interview, don't be surprised that she don't give an f.. about user's privacy... they much more afraid of being accused of a treason.

There are ways to inject ANY code in Chrome if they need to. Unlike Ladar Levison (Lavabit), they won't close the company if 'good guys' will politely convince them to collaborate They're too big to fail...

S/MIME is supported natively by Outlook, Apple Mail, and the native mail clients of every major smartphone platform. Why try to kludge OpenPGP on there when S/MIME is already built in?

I may be wrong, however, S/MIME requires trusted keys be generated by a Certificate Authority. (You can self sign, however, you loose quite a bit in doing so.) With PGP, you can generate your own key, post the public portion on the MIT Key server, use your private key to encrypt as little as an empty document or as much as a large RAID. In general, PGP is more flexible and open. It is also, by far, the more established, longer lasting option. It has been in heavy public use, dating back to 1991.

There is NOTHING wrong with Javascript. Case in point, Lastpass has proven, you can do encryption and use Javascript and do it the correct way. There is an advantage to using Javascript, there is no secret sauce, you can verify what sauce is actually being used yourself.

To be honest I am not even sure what vulnerabilities the author is even talking about. Would you rather have the Chrome client which is compiled by Google do the encryption and decryption itself? What makes that more secure then a Javascript based solution?

Google did a good job here, I don't agree with the author that this option might have extremely serious, flaws to be honest. There is no evidence to support Google's approach is flawed, or what flaws that are known, are "extremely serious" they might be minor and acceptable compromises. One thing is for certain OpenPGP was the wrong solution, while Android's mail client will likely be updated to support this feature, it doesn't help anyone on Windows Phone, iOS, or anyone that uses a desktop client.

Unfortunately, that's the same story as with Hushmail premium in the past. This time backed by much bigger money and based in USA, not in Canada, what I honestly saying see as the greatest disadvantage because of Patriot Act.

Once more step by step.

1. You've got PGP/GPG-encrypted mail in your Gmail Inbox.2. You download a browser applet (closed-souce precompiled bytecode, similar to Java binaries)3. You allow the applet to manage your keypair(s) including your private key(s)4. End of security. Having proprietary browser-based app, made by USA Internet giant, one of those which are in bed with intelligence, meddling with your PGP keys? After Eric Schmidt statements about privacy? After all the lobbying efforts of Google and FB in Europe to undermine EU Privacy Laws?

Good way to attract attention to your correspondence and let Google decide much more precisely which of your messages should be forwarded to 'the good guys'

It's an open-source extension implementing a open source asymmetric encryption standard as a web browser extension. It's not proprietary in any sense.

As you point out, Google is doing everything the correct way, using a solution anyone and everyone can verify what the extension is doing exactly. I wish they were using a solution that could be used by any client, this extension of Google Mail only works, if all browsers can use it ( including IE11 ). It could in theory be extended to Outlook, new mail iOS clients could be developed ( and/or Apple could adpot their mail client to support it ), but all are problems that shouldn't exist because OpenPGP isn't the correct solution.