Add the possibility to write/encrypt outside of webmail

[karelbilek]

(this is a feature request, but judging by reddit discussion a very frequent one)

I want to be able to write "outside" of webmail, but "inside" the webmail tab

what I mean by this... I want to be able to write the message in a window in gmail somehow, but without google sniffing my mail with javascript and saving it as draft.

[karelbilek]

(I would implement this myself if I could but I can't speak jQuery)

[Wikinaut]

+1

[Wikinaut]

@Runn1ng jQuery is very easy to learn. Web is full of sniplets if you need help.

[toberndo]

I currently see two possibilities how to isolate the mail composition from the webmail provider:

1. separate tab solution like it is in GPG4Browers. This offers the best separation but is not optimal from a usability perspective.
2. integrated solutions as the decrypt process of Mailvelope: an overlay could be injected that contains an iframe with rich text editor. After encryption the armored text is pasted in the webmail text editor. I would prefer this solution, but it is also vulnerable against certain attacks (how to distinguish if text editor overlay comes from Mailvelope or website? Btw. same for decrypt process). This needs more review.

[karelbilek]

Thinking about it, there is no easy solution that is both 100% usable and 100% secure :)

[karelbilek]

for example, for a separate tab, we can say that even the "evil" webmail can open a separate tab, and so on.

What is probably the only solution that would work is something that extensions can do, but webpages can't. I am thinking about a browser pop-up. Nobody except an extension can display a browser pop-up, right?

By pop-up I don't mean a window/tab, but that small thing that gets displayed if you click on icon.

That one is not interceptable by anyone from outside, yet it's easy to write into for the user.

Yes, it's kind of weird to write a mail to browser pop-up, but it should work correctly, AFAIK

[thedod]

I agree with runn1ng.

The reason why FireGPG no longer ships with tails is that the DOM of a web app is not a safe place for plaintext
https://tails.boum.org/doc/encryption_and_privacy/FireGPG_susceptible_to_devastating_attacks/
Any architecture where plaintext is stored inside a web app's DOM is dangerous. Especially a webmail app that can be expected to save drafts, but not only. Web apps can be MITMed, XSSed, etc. If it came via the web, it's a suspect.

This means that instead of the feature request "Add the possibility to write/encrypt outside of webmail", this should be a "never write plaintext inside the DOM" critical bug.

I'd expect a crypto add-on to only accept plaintext (and other sensitiv) information) via separate GUI that can only be launched manually (not via javascript in an app's DOM) and has a hard-to-imitate look-and-feel (to discourage phishing, as runn1ng points out). The only communication between the add-on and the rest of the browser should be via the clipboard.

This would change the app's definition from "secure mail" to "secure anything", and would require the user to understand how to paste, but it's a relatively small price for privacy IMHO

[karelbilek]

I just implemented what you said, basically.

"hard to immitate look and feel" is what chrome already has, it's called "pop-up" and it's that thing that appears if you click on the icon. It's the small window, it's impossible to mimic by javascript by application, it's it's own thing, it communicates just with the extension.

I added a small thing - when you click on the icon that mailvelope already has, a small textarea appears and you can write the mail there and copy-paste it to the webmail tab.

It's pretty ugly since I am too lazy to do webdesign :), I will polish it a bit and then make it a pull request.

edit: oh, my implementation will work only in chrome I guess, I don'ŧ have FF even installed.

[MeanderingCode]

I am interested to see what runn1ng implements (though i live in FF and don't use Chrome much).

Before i learned about Mailvelope i had started using Pentadactyl's (http://5digits.org/pentadactyl/ ) facility to launch Gvim for text fields and use http://github.com/jamessan/vim-gnupg for encryption (when Gvim is quit, whatever is written to the temporary file is copied into the text field).

Perhaps the approach of some "external" element editor (such as runn1ng's work or my Gvim example) when the user clicks the UI element to encrypt, while defaulting to editing in the webmail interface and merely signing on send [#2] makes the most sense. Drafts of encrypted messages would be encrypted, and on editing a draft that is encrypted, Mailvelope would detect this and launch the editor.

I don't have any time this month, but i would like to dig out Pentadactyl's code for launching the external editor (configurable) and refactor for this instance. Of course, this solution would need a hook in Mailvelope to read the file, encrypt it, and then paste the encrypted contents.

[karelbilek]

See

#18

(with the image).

[thedod]

As far as spoof-resistance goes - #18 does the job well. However, using localStorage is dangerous because your hard disk can still be taken from you (with a warrant or a big stick).
I believe the flow should be (inside a #18-like non-DOM GUI):

1. User types into "plaintext" textarea and enters other settings (recepient[s], signing key+passphrase, etc.)
2. When user clicks "encrypt", add-on encrypts in RAM (if possible, lock memory from swapping. Can add-ons do that?)
3. Add-on copies cyphertext to clipboard and notifies the user

If the user closes the GUI (whether before or after encryption), the add-on should [assume someone with a big stick has just entered the room and] forget everything. No need to erase the clipboard, though :) It's encrypted.

[karelbilek]

I don't see the problem. localStorage is used only because you don't want to lose your message if the chrome popup closes (it closes whenever you click somewhere outside the popup, so basically all the time).

Once you encrypt, it's deleted from localstorage.

PGP.js (or what is the name exactly) encrypts in ram by default.

Also, I think that JavaScript can't copy to clipboard. (But maybe it has changed from last time I checked.)

[thedod]

Once you encrypt, it's deleted from localstorage.

In that case, it would take a big stick and a forensics expert to retrieve the plaintext ;)

Also, I think that JavaScript can't copy to clipboard. (But maybe it has changed from last time I checked.)

I know that JS inside the DOM (<script/> tags) can't access clipboard, but I thought add-ons could at least copy to clipboard (not as dangerous as allowing paste).
Anyway, you can always create a small "cyphertext" textarea, focus() and select() it, and tell the user to copy it.
It's even more intuitive for the user this way.

[toberndo]

Thanks for the comments so far.

I added a section to the documentation to make the current limitations transparent to the user:
http://mailvelope.com/help#security

Let me explain why I don't see the current solution as a critical bug:
Mailvelope has a strong focus on usability. It wants to lower the barriers of entry to email encryption for people with previously no experience in this field. The target group cannot be compared to systems like tails: if your life or physical security depends on secure communication, then Mailvelope is for sure not the right tool.

But there are enough high secure encryption systems out there that nobody uses and as far as I'm concerned I don't want to spend my time on another copy&paste solution that is used for some time and then neglected because it is too complicated.

I think currently Mailvelope makes sense for the following people:

• You are new to email encryption and want an easy solution to get started but still be compliant with the standard (OpenPGP)
• You are a Google Apps customer. You trust Google with your business data. You want a solution that integrates with Gmail.

From a wider perspective: even low secure encryption mechanisms (take the envelope as an example) make mass surveillance more difficult if they are used by a lot of people.

But of course best is to have the choice. Therefore I would like to see two different modes in Mailvelope: the current one (as default) that is integrated in webmail with all the risk and all the comfort. And a second one that offers strong isolation but maybe less usability. The mode is then configurable in the settings.

runn1ng's prototype is a surprisingly easy solution for strong isolation. If we could somehow find a solution without copy&paste this would be perfect. Problem is that browser action popups in chrome as far as I know cannot be opened programmatically (in Firefox this should be possible with panels). Otherwise we could trigger the action from the webmail site (e.g. current encrypt buttons), thereby also identifying the DOM element where the encrypted text will be pasted into.

@MeanderingCode Didn't have a look at this in detail. Does it use a native binary? I hoped we could keep this door closed. Lots of JavaScript rich text editors out there.

[MeanderingCode]

Yes, the Pentadactyl method launches an external binary, configurable to
whatever your preferred editor on your system is. I understand why you
want to avoid this, based on what you're saying about usability and low
barrier to entry.

If runn1ng's solution could be achieved similarly in FF (I'm not familiar
with FF programming or panels), it would obviate the need for using an
external binary.

On Sun, Dec 16, 2012 at 10:00 AM, Thomas Oberndörfer <
notifications@github.com> wrote:

Thanks for the comments so far.

I added a section to the documentation to make the current limitations
transparent to the user:
http://mailvelope.com/help#security

Let me explain why I don't see the current solution as a critical bug:
Mailvelope has a strong focus on usability. It wants to lower the barriers
of entry to email encryption for people with previously no experience in
this field. The target group cannot be compared to systems like tails: if
your life or physical security depends on secure communication, then
Mailvelope is for sure not the right tool.

But there are enough high secure encryption systems out there that nobody
uses and as far as I'm concerned I don't want to spend my time on another
copy&paste solution that is used for some time and then neglected because
it is too complicated.

I think currently Mailvelope makes sense for the following people:

• You are new to email encryption and want an easy solution to get
  started but still be compliant with the standard (OpenPGP)
• You are a Google Apps customer. You trust Google with your business
  data. You want a solution that integrates with Gmail.

From a wider perspective: even low secure encryption mechanisms (take the
envelope as an example) make mass surveillance more difficult if they are
used by a lot of people.

But of course best is to have the choice. Therefore I would like to see
two different modes in Mailvelope: the current one (as default) that is
integrated in webmail with all the risk and all the comfort. And a second
one that offers strong isolation but maybe less usability. The mode is then
configurable in the settings.

runn1ng's prototype is a surprisingly easy solution for strong isolation.
If we could somehow find a solution without copy&paste this would be
perfect. Problem is that browser action popups in chrome as far as I know
cannot be opened programmatically (in Firefox this should be possible with
panels). Otherwise we could trigger the action from the webmail site (e.g.
current encrypt buttons), thereby also identifying the DOM element where
the encrypted text will be pasted into.

@MeanderingCode https://github.com/MeanderingCode Didn't have a look at
this in detail. Does it use a native binary? I hoped we could keep this
door closed. Lot's of JavaScript rich text editors out there.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-11419791.

[karelbilek]

@toberndo : we will have to agree to disagree :)

I hope you don't really mind, but since your code is AGPL, I created a fork of mailvelope where the key generation, management and the encryption UI is same as in your software (because I really like the way how you did that), but the watchlist is removed and the encryption and decryption happen in the pop-up window.

I will push it to github/put in on web soon, I think I will call it "ChromeGP".

[karelbilek]

done, here

https://github.com/runn1ng/ChromeGP

[toberndo]

Mailvelope v0.6 is released which has the external editor option for writing emails as default.

Please see announcement: http://www.mailvelope.com/blog/security-audit-and-v0.6-release
Result of security audit: http://cure53.de/pentest-report_mailvelope.pdf
Security section of documentation: http://www.mailvelope.com/help#security