If you are concerned about someone hijacking the gmail session you have lost anyway, as the decrypted (or not-yet-encrypted) text surely has to hit the dom at some point.
If you are concerned about someone hijacking the gmail session you have lost anyway, as the decrypted (or not-yet-encrypted) text surely has to hit the dom at some point.
http://news.cnet.com/Will-security-firms-detect-police-spywa... "In theory, government agencies could even seek a court order requiring security companies to deliver spyware to their customers as part of an auto-update feature. Most modern security companies, including operating system makers such as Microsoft and Apple, offer regular patches and bug fixes. Although it would be technically tricky, it would be possible to send an infected update to a customer if the vendor were ordered to do so."
Countermeasures to autoupdates include: (a) disabling them; (b) verifying that the checksum you receive is the same as posted on a number of different sites unlikely to be coerced into delivering FedGov malware; (c) only downloading autoupdates from a non-U.S. repository unlikely to be coerced into delivering malware. And probably many others I'm not thinking of offhand.
But in reality if your threat model is that the NSA/FedGov/FBI/GCHQ/CIA are already targeting YOU SPECIFICALLY, you probably already have a few dozen physical bugs that were concealed in your home placed via a sneak and peak Scarfoesque black bag job the last time you went out for pizza. A hypothetical court order to force FedGov malware on you specifically via autoupdates can be contested by the provider (I was the first to report last May that Google was litigating two non-malware NSL cases pre-Snowden) and in any case is not bulk surveillance.
So the threat model for this project is autoupdates. Extension autoupdate, chrome autoupdate and OS autoupdate could all compromise this, but that's still worlds better than just sending some different obfuscated javascript in a browser session.