but you can check 'Old behavior for decryption' in option, to have the decryption result in a new windows and not in the dom
That seems to be a good alternative. Thanks for the hint!
1 2009-03-25 07:31:58
Re: GMail - new interface - security question (4 replies, posted in Bugs & problems)
2 2009-03-24 16:56:13
Re: GMail - new interface - security question (4 replies, posted in Bugs & problems)
Thanks for clarification!
there is thing impossible to do inside an iframe (mail's composition, auto decryption, etc..), so it's kind of 'necessary'
What's the technical limitation p.e. with auto decryption? On other sites FireGPG replaces the encrypted block with an iframe. If you click on the decrypt link, FireGPG shows the clear message. Instead of waiting for user confirmation FireGPG could automatically decrypt the encrypted message, I think.
3 2009-03-24 14:16:26
Topic: GMail - new interface - security question (4 replies, posted in Bugs & problems)
On arbitrary websites FireGPG injects a chrome iframe to secure the decrypted text if it detects an encrypted block. Therefore it shouldn't be possible for JavaScript code on the page to read the decrypted message (content code isn't allowed to read chrome content).
As for GMail with the new interface FireGPG interacts directly with the page content. The decrypted message is injected into the existing DOM without the securing chrome iframe. Therefore it should be possible for JavaScript code to read the decrypted message.
It's debatable if Google would do such evil things, but this seems to be a general problem, which is already solved for inline encrypted messages in arbitrary websites.
Is this behavior of FireGPG intended or even necessary to interact with the GMail interface?
Please correct me if I've made incorrect assumptions.
I'm using current Fx 3.0.7 and FireGPG 0.7.5