I am developing a Google Chrome extension which encrypts/decrypts emails for Gmail users. So, I detect encrypted emails when the user opens an email on using tags. Once an encrypted email has been detected, the user is asked for a password and the plain text is displayed in a pop-up.

I want to use Jquery UI dialog to display the plain text. If you know a bit of Jquery UI dialog, you know that you have to inject a div tag in the web page (gmail here) in which you put the stuff you want to display in the pop-up. And then call dialog on this div.

So my questions are :

1.) Does it raise security problems to inject the plain text in the web page ?

2.) Does the web page (so Gmail) can detect such injection ?

3.)Is it vulnerable to a Man in the middle attack ?

Ideally, I would not want Gmail to be able to detect it and get the plain text, especially when we are now aware of PRISM program, but if it can only be detected by Gmail and nobody else it is still good for a start.

  • I wonder why the downvote?
    – schroeder
    Jul 2, 2013 at 23:25
  • I guess it was because the message was not properly formatted at first. It's my first post here, and I didn't notice there was actually a good text-editor. But a member came and fixed it. Thanks to him.
    – Kheil
    Jul 3, 2013 at 1:49

2 Answers 2


1.) Does it raise security problems to inject the plain text in the web page ?

Plain text is just text... there are no security impacts unless you start injecting code wich actually gets executed server side.Besides, what you are describing is client-side encryption/decryption. As a result, you'll end up with either plain text (=decrypted) or an block of "random" chars (=encrypted, guess base64-encoding after encryption and bas64-decoding before decryption will be safest when thinking email transfers)

2.) Does the web page (so Gmail) can detect such injection ?

As Google changes/updates it's code on a rather frequent base, that's hard to tell. Currently it would not... yet that might change any second (depending on when Google pushes a next minor update online). Theoretically, it is possible for Google to implement a rather simple javascript routine that looks for modifications of the page itself, or of child elements of the document (like the textarea). Practically, it isn't currently done... but as I said: when Google changes it's code, you could be in trouble and your extension void before it's really live.

3.)Is it vulnerable to a Man in the middle attack ?

If with "it", you mean your client-side encryption/decryption... no, as it happens CLIENT-side before sending any data anywhere.

If with "it" you mean "email traffic" when sending the data after encryption, you should know that — generally — email traffic "can" be vulnerable to MITM attacks. But as Google mail tends to enforce the use of SSL, I personally regard it to be safe from MITM attacks when users indeed keep SSL enabled at all times.

Talking about vulnerabilities, I would like to point you to two other things you should consider:

  1. Depending on the crypto you are going to use, the way you are going to implement things can and will have an important impact on potential (crypto-related) vulnerabilities to consider.

  2. Client machines of sender and/or receiver may be compromised — intercepting and transferring the decrypted data using malware like trojans.

  3. Sending blocks of encrypted data via email can and most probably will put you on the radar of whatever governmental agency might be interested in the contents of such "encoded messages". It's been known for years, but recent news related to #prism reminded us all that "they" are actively parsing traffic like emails when something looks suspicious. I guess I don't have to explain that using cryptography isn't saying "I've got nothing to hide", but rather the opposite.

Last but not least, remember that - when it comes to software development in general - there are restrictions on the import of cryptography and there are even more restrictions related to the export of cryptography and export of cryptography in the United States) related to cryptographic implementations. Depending on your residence, these might have an impact on the product you are planning to create. Currently, many countries, notably those participating in the Wassenaar Arrangement, have similar restrictions. So, be sure to read the docs that come with the cryptographic algorithm(s) you are planning to use or you might face other kinds of trouble later on.

  • Thanks for your reply. 1.) I meant does it raise security problems for the confidential data I inject in the gmail page. Sorry for the confusion. 2.) Yes indeed, my extension is really dependant of gmail changes, but I have tried to make it flexible to avoid that kind of problems. 3.) Yeah I meant client-side encryption/decryption.
    – Kheil
    Jul 3, 2013 at 1:58
  • 1
    I am using the Stanford JS Crypto library to encrypt/decrypt messages using AES with 128-bit symmetric key. Every encryption/decryption is done at client-side in scripts. To prevent attackers to get access to the symmetric key, it is also encrypted using a passphrase that only the user knows. I cannot do better in term of security I guess. I am actually doing this in the UK as part of a final project at Oxford university. I'll check the restrictions on cryptography thanks for the links. Finally I have found that I am not forced to inject the div tag in the web page I can do something else.
    – Kheil
    Jul 3, 2013 at 2:05
  1. Gmail does some serious filtering on the contents of the displayed e-mails in order to avoid XSS attacks. As you start to send encrypted e-mails you should take care of these things if you inject user-supplied data in the context of Gmail. This task is far from trivial, I suggest to take a look at whitelisting solutions like HTML Purifier.
  2. If we are talking about the injection part only, Gmail would need some special client-side code to be generated in order to detect you injected code. However, Gmail will theoretically be able to detect that you are sending encrypted data at server side (based on the metadata you generate for your solution or simply by measuring entropy), and use this information to signal that code injection will most probably take place. Maybe you can use some kind of steganography but keep in mind that intelligence services are really smart.
  3. Based on the second point Gmail (NSA, Big Brother, the hacker who took over Gmail, etc.) will have ways to detect the fact of encryption and as long as you put the plaintext back to their origin, they will have ways to read it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.