
End-to-End Encryption Plugin for Yahoo Mail - danielweber
http://yahoo.tumblr.com/post/113708033335/user-focused-security-end-to-end-encryption
======
mrb
Little known fact: Google's End-to-end encryption extension already works on
_any_ site. It is not limited to Gmail. In fact it's not limited to webmail
either. If a PGP blob is present in a web page, End-to-end can decrypt it. If
a text input area is present in a web page, End-to-end can encrypt it.

~~~
SilasX
Littler-known fact: if you are serious about protecting that message, then web
based email can't really do it.

So long as the server has access to your plaintext as you compose it, the
security is compromised and a third party has it. And then if the recipient
views the plaintext from a browser...

If you want the email to be secret, it must be in it's encrypted form before
the browser even knows about it ... but at that point, why not just use a
different, well vetted client program for email?

~~~
EC1
> but at that point, why not just use a different, well vetted client program
> for email?

Anyone have any names?

~~~
moe
Mutt and Thunderbird come to mind.

~~~
jvehent
GPG in Mutt is fantastically well integrated.

Now, of course, you have to get used to Mutt first :)

~~~
middleclick
Thunderbird with Enigmial also works quite well. I use it everyday.

------
zobzu
Rather to compare E2E with Mac GpgTools, I'd try to compare it with
[https://www.mailvelope.com/](https://www.mailvelope.com/) which is a much
better comparison since both are addons for browsers.

Mailvelope works both on Firefox and Chrome (ironically, the Yahoo plugin
seems to only have Chrome support at the moment) and is actually even nicer to
use (read: seamless) than E2E IMO.

~~~
barnaby
Yeah, I use mailvelope with my close friends and family. It's not yet easy
enough for my parents generation to "get it" but if it's set up for them they
can muster through it.

The problem with plugins though is that very few people go out of their way to
install browser plugins. Having an integrated option is way more useful. So
some people have to encrypt/decrypt in-browser using Javascript (like, how
tutanota and protonmail do it, or like whiteout.io does, or like anybody can
do now using the keynote.io API). I know it's not ideal, but it is way better
than nothing. It won't stop the NSA, but it will stop hackers, email leakers,
doxxers, and big-data email-mining algorithms.

------
nullspace
Can someone give an explanation of how this works?

In order to get this to be seamless, I would guess that this only works when
you are sending from one yahoo account to another one correct? Unless they
have found a clever way to share the public keys.

~~~
happyfuncube
Yahoo Paranoids Engineering Director for end-to-end here.

Today our extension works as a developer only demo, and no Yahoo keyserver
service is online yet. If our toy keyserver code didn't make it into this
release, you will see it very soon and will be able to experiment.

We released the source so we can solicit security feedback early, and can keep
all security and privacy critical parts of this product in the open. No "just
trust us" now or in the future.

Along those lines, we will work with industry peers to build public key
registry software that interoperates with other federated providers, is open
source, and is transparent in the cryptographic sense. I.e. Yahoo and Google
users should be able to send encrypted email to one another with ease, and if
either company was forced to lie about the public keys of our respective users
we would be caught because math.

There's a lot more in the works, and we have many challenges to overcome to
make this generally usable. In addition to the key server, there's not
unnecessarily breaking existing mail features, multi-device issues, search
over encrypted content w/o providers being able to read it, and mobile support
to start.

If you know anyone with the skills and motivation to make strong, usable
encryption available at internet scale we'd love to listen, collaborate, or
hire. :)

~~~
deanclatworthy
Except that we cannot verify that you actually deploy the "open" code. It's
obviously commendable that you do development in the open, and have people
review the work you do. But there is no way for us to know that you don't run
/addNSAbackdoor.sh in your deploy script for key parts of your infrastructure.

There is already published docs that show Yahoo is/was part of Prism since
2008: [http://www.wired.com/2014/09/feds-yahoo-fine-
prism/](http://www.wired.com/2014/09/feds-yahoo-fine-prism/)

~~~
magicalist
All encryption runs clientside. The whole point of end-to-end is that you
don't have to care about who the message passes through.

Your actual worries at this point are the key exchange (impersonation) and
extension distribution.

The first is very hard to get right without alienating a large number of
potential users, the second seems perfectly possible to have verified but
seems like it's going to require some kind of changes in the Chrome extension
system.

~~~
m-app
It doesn't have to pass through anything but if the '/addNSAbackdoor.sh'
script just adds a routine to the code that adds the Public Key of an NSA
owned key-pair before the encryption process, then the NSA can pick it up from
any Internet-tap they have and decrypt it.

~~~
pionar
Except that this runs locally, so if you're worried about that, you can build
it yourself.

------
snassar
It is worth noting that the Yahoo! devs do not promise OpenPGP (RFC 4880)
compatibility in the future.

------
asdz
now take my public and private key Yahoo!

