
Mailvelope – OpenPGP Encryption for Webmail - galapago
https://www.mailvelope.com/
======
markild
I really wish I wouldn't have to store the private key together with a browser
extension I don't trust (no offense to the author(s)).

It would be amazing if Windows, Mac and Linux all would support some sort of
"safe" gpg/pgp storage. I don't remember if I'm making this up, but i believe
the OS X keyring can do this. There really should be no reason why every
application should roll their own storage and interaction of the private key.

~~~
malka
I do not see more reasons to trust the OSX Keyring, than to trust a browser
extension.

~~~
phn
Do you not trust the OSX Keyring because of apple? Or outside attackers?

If it is apple you don't trust in this regard, keychain is the least of your
problems.

If it is outside attackers. At least they should need physical access to the
machine to crack it, right? (If you don't back up that specific keychain to
iCloud)

~~~
malka
Both, actually. I Think encryption should involve specialized hardware, such
as a smart card. That way, it would NEVER ever be exposed to a network.

~~~
jpollock
In order to be used, it has to be exposed to the network.

~~~
malka
not really. You could imagine a smart card with a software (the smart card
itself runs the software)that would take bytes[] as an input and would output
the encrypted bytes. The only 'network' communication would be between the
card and the computer, and the computer would be unable to access the private
key stored on the card.

~~~
crdoconnor
Losing one of those things would not be fun.

~~~
jtheory
Not quite the same thing, but I have a little (physical) keypad that HSBC
provided to generate codes to sign in online. It's small, and flimsy, and my
almost-2-year-old is fascinated with it -- when she manages to get her hands
on it, she presses buttons and talks on it like it's a tiny phone... it's
adorable, but one of these days it's going to decide she has "failed" my
passcode too many times and it'll brick itself.

And when I'm spending a month or two in Asia, for example, I have no illusions
that I could possibly get another mailed to me, if it broke or was lost.

These are great in terms of security, and should be an option for people who
need it, but shouldn't be obligatory (I wouldn't use this for my bank if I had
a better option).

------
edent
I've been using this. It's pretty good but - like all PGP implementations -
it's really hard to use _casually_.

You really need to make an effort to ensure you've got the right keys, that
you can remember your password, that you know how to generate a keypair and
which part of it you upload to the app.

But, once done, it works pretty well. The main downsides for me were....

\- Doesn't encrypt the subject line. You don't want to say "Top Secret Docs"
in there, sure, but it does make looking through mail pretty hard. Which leads
to...

\- No search. I pretty much rely on search to find emails. I just hadn't
anticipated how much of a drag it would be to only search via sender.

~~~
SkyMarshal
Same and /second. I'd add that I've trouble encrypting emails with
attachments, as Javascript encryption performance in web-based email in a
browser that's being abused with lots of other tabs open is not always so
reliable. Surprise surprise.

The Stanford Javascript Crypto Library whitepaper provides probably the best
performance baseline for all of Javascript crypto [1], and the best they can
do is roughly 10x faster than the next fastest JS crypto implementation, but
still over 40x slower than native crypto.

[1]:[http://crypto.stanford.edu/sjcl/](http://crypto.stanford.edu/sjcl/)

------
riquito
Google is developing a PGP extension too

[https://code.google.com/p/end-to-end/](https://code.google.com/p/end-to-end/)

and Yahoo plans to use that code to fork his own

[https://twitter.com/bcrypt/status/497444399715192832](https://twitter.com/bcrypt/status/497444399715192832)

~~~
steelframe
Another thing to point out, the Google developers respect the difficulty in
securely implementing a Chrome extension that performs encryption. They are
going through an extensive period of public review, and they're asking people
to not build and deploy as a Chrome extension until after it's been thoroughly
vetted.

In contrast, the Mailvelope guys seem to have just flung something over the
wall with little regard to the actual security of their implementation. Seems
irresponsible at best.

------
chrissnell
Correct me if I'm wrong, but you're encrypting the message _after_ you type in
into the webmail client but before you send it? We all know that GMail
constantly saves auto-drafts to server-side as you type. If your GMail is
being monitored by a government (and we should assume that it is), this type
of encryption client isn't going to do much for you. You'd be better off
typing it in a text editor and encrypting that and pasting in.

~~~
mncolinlee
Never mind all the other obvious problems that could occur at any stage. The
webmail server could change a single setting and record every keystroke. An
intelligence agency could push an updated version of the extension which
records keystrokes or quietly caches plaintext. A browser update could detect
the extension and start recording everything.

Any time you try to make encryption simple and easy for a mass audience you
still have to educate the user about risks. Most solutions are not bulletproof
enough to keep out intelligence agencies.

~~~
oh_sigh
With a chrome plugin, a window can be created with the running page does not
have access to. I'm pretty sure that is what this plugin is using

------
kitd
This may be a noob question, but how would you send securely to multiple
recipients?

~~~
augustl
PGP uses the pubkey to encrypt a randomly generated symmetric key, because
it's much faster to asymmetrically decrypt a small key and then symmetrically
decrypt the entire message. For multiple recipients, this symmetric key is
simply encrypted once for each recipient pubkey.

~~~
kitd
Thank you, and to Anderkent. It seems pretty obvious now when you think about
it.

------
blueking
Only useful if it supports tokens such as the openpgp smartcard to store the
private key. Otherwise its just security theatre.

Try gpgtools with a openpgp smartcard. Its easily the most user friendly
experience going for token based PGP, and supports 4096 bit RSA keys.

------
javanix
The "postcard -> unencrypted email as letter-in-envelope -> encrypted email"
seems to be a very good analogy for explaining the need for encryption to
laypeople.

The technicals are trickier (and outside my scope of expertise), but the "why
do I need to use this" answer is one of the trickiest and most important
questions to answer for any security application.

------
BillFranklin
Mailvelope is awesome - been around for a while, works as well as it should
but isn't really solving many problems inherent in PGP.. Guess everyone saw
this article: [http://blog.cryptographyengineering.com/2014/08/whats-
matter...](http://blog.cryptographyengineering.com/2014/08/whats-matter-with-
pgp.html)

------
indeyets
last release was in April and it doesn't look like anything newsworthy
happened since then

~~~
galapago
Firefox version was released 13 days ago:

[https://github.com/toberndo/mailvelope/releases/tag/v0.10.0b...](https://github.com/toberndo/mailvelope/releases/tag/v0.10.0b1)

~~~
CalRobert
I'm on the most recent firefox version after previously building it myself.
It's not bad; I find it to be better than messing around with enigmail. I
wonder what the pros/cons are to this as opposed to Mailpile, which I haven't
used yet.

~~~
higherpurpose
Well for one, Mailpile is a local client. Mailvelope can be updated/accessed
by the developer at any time.

~~~
rakoo
"local client" and "updated/accessed by the developer at any time" are not
mutually exclusive: the most common example is Chrome, and AFAIK applications
on Android can be updated at the developer's will (I'd guess it's the same for
iOs and WP, too).

The model we have for traditional PCs is actually a remnant of the
disconnected era in which applications were first conceived: manual update
when the user knows they have a connection.

~~~
deong
For iOS and Android at least, automatic and relatively transparent updates are
a user-preference, so you can't as a developer _force_ users to update,
although I'm sure most have automatic updates enabled. You could I suppose
version your API calls and disable all but the newest version from working,
provided you have a server component, but that's about it I think.

~~~
higherpurpose
On Android it's off by default, and you can easily enable/disable it. On
Chrome it's on by default, and I don't even know how to disable that (I assume
it's somewhere in flags, which is of course terrible UX for something like
this)

------
bigbigsauron
Someone in this thread made a very good point - it is hard (I'd say
impossible) to create usable, mainstream E-mail encryption system based on PGP
and derivatives. PGP and Web Of Trust models have fundamental limitations that
prevented any meaningful adoption during the years since it was invented.

It is possible to do better with NameCoin, which promises and somewhat
delivered a solution to key management and practically working robust PKI.

There is another E-mail encryption Chrome extension, called SecureDolphin
([http://www.securedolphin.com](http://www.securedolphin.com)) that uses
NameCoin for public key delivery. Check it out in the Crome Store
([https://chrome.google.com/webstore/detail/securedolphin/nefm...](https://chrome.google.com/webstore/detail/securedolphin/nefmgfdecbbhneankolhhlmfodelmoad))
if anyone is interested.

------
drvortex
I am still waiting for a proper browser based mail client that will let me
read email from a variety of IMAP servers, rather than email 'clients' that
are actually not clients, but just interfaces to a particular email service.

~~~
Steuard
What is the advantage of "browser based" in this case? It sounds like you're
asking for a mail client that's not tied to a particular mail provider's
website, and that's what native clients have provided ever since IMAP was
developed.

~~~
fluidcruft
I think the difference is a browser extension would be portable (and work on
locked-down thin clients such as chromebooks where "native" clients are
"browser based").

Relatedly, I really, really, wish ChromeOS would support smartcards but
reading the frustration of the government/military types that have been
begging for this feature for years with no real interest by Google is very
disappointing. I really like the form factor of YubiKey Neo that simply hangs
on your keychain and just sticks into a USB port to become a smartcard. We're
also never going to have gpg-agent on ChromeOS so smartcards is pretty much
the only way to keep the private keys off the machine.

------
ams6110
It's a nice effort, but effectively no easier than simply composing my message
in nodepad/emacs/vi, PGP encrypting it, and pasting that into gmail. And
that's far too difficult for 95% of the email using public.

------
buro9
Years ago I would've loved this, but I'm just too productive with a native
mobile app. I may only be in this app 20% of the time, but I wouldn't trade
that 20% for encryption.

~~~
lnanek2
Native apps already have good support for encryption in general. The default
Mail app in OS X has a button for it, for example. The only thing new here is
bringing it to the big webmail clients via browser add-ons.

~~~
tnorthcutt
buro9 mentioned native _mobile_ apps. Does e.g. iOS Mail have similar support?

~~~
giovannibajo1
Mail on both OSX and iOS have native support for S/MIME, which I've been using
daily for many years. You can use it to sign and/or encrypt emails.

Keys are stored in the keychain. S/MIME uses a CA-based system for
authentication, so the pro is that you don't even need to do key management
(it is sufficient that one user sends you a signed message - and you use the
CAs to validate the signature), and the key is automatically imported into the
keychain. The con of the CA-based system are the same of SSL/TLS.

The only non-user-friendly pass is acquiring the certificate, which is as hard
as getting a server SSL certificate; not complicated for an IT professional,
but impossible for a casual user (plus, you have to pay them, unless you use
StartSSL). Once the certificates are installed, the whole experience is mostly
dumb-user proof.

For enterprises, OSX & iOS supports pulling the certificate from a specific
ActiveDomain/LDAP record, so that you can automatically send encrypted mails
to anybody in the company, even if you haven't communicated to them before;
moreover, they support deployment through configuration profiles, so that it
gets auto-installed and auto-configured for the end user.

------
4k
Its mildly frustrating that I have to click a link to know whether it's
something I would have wanted to click or not.

Why not, "Mailvelope - OpenPGP encryption for webmail"?

~~~
lnanek2
Even if you put a good title the HN mods tend to strip it to be more bland
anyway. I'd much rather they just allow duplicate story submissions with
different titles and let the crowd pick the best title with voting. They
aren't doing a good job with staff enforced titles.

~~~
MBCook
They make it match the title of the destination page, and that's where the
problem is. The destination page should have a better name.

~~~
jtheory
Another item for the endless startup checklist -- "is my landing page title
informative enough to serve as an HN link?"

~~~
saturdayplace
Which is really just a more specific form of "Does my landing page actually
tell newcomers what's actually going on here?"

~~~
surye
Except the title is barely visible in most browsers these days, where it has
to fit in a tab.

