
ProtonMail's encrypted email is now available to all - rdl
http://www.engadget.com/2016/03/17/protonmails-encrypted-email-is-now-available-to-all/
======
moxie
Some bad signs:

1\. Hosted in Switzerland is advertised as a security feature. The point of
e2e is that the servers are untrusted. If you need a "good jurisdiction" for
your servers, it means they must be trusted. That's a problem, because sadly
there are no good jurisdictions in today's world, and your jurisdiction
doesn't help you if your servers are hacked.

2\. It's webmail. That means the security of whatever e2e they're doing is
based on the security of SSL. If you break SSL, you can break whatever e2e
they're doing, and that means your e2e security is only as secure as the CA
system.

3\. Their 'threat model' documentation leads with: "From a high level, our
premise is that a service like the now-defunct Lavabit does add value, despite
some inherent weaknesses. We designed ProtonMail around many of the same
principles..." Given what happened with Lavabit (the eventual compromise of
everyone's email despite shutting down the service), considering it to have
been "valuable" should really be off the table at this point:
[http://www.thoughtcrime.org/blog/lavabit-
critique/](http://www.thoughtcrime.org/blog/lavabit-critique/)

I can't find much in the way of technical documentation for ProtonMail, but
from what little is available, it does seem that (much like Lavabit), the
service is built on the premise of "won't" read your mail rather than "can't"
read your mail.

~~~
vabmit
Disclosure Note: I'm with ProtonMail. Please note that I don't officially
speak for the company. But, I'm a crypto guy and this is Hackernews so...

1\. While historically advertising a hosting location was a bit of a red flag
for snake oil, the Snowden disclosures changed things for SaaS providers.
Jurisdictional arbitrage is indeed a security feature of the service. I think
you're missing the point a bit in that it goes much beyond the physical
servers. Simply locating servers in Switzerland doesn't provide much
protection for users if you're an American company with US bank accounts. For
example, choosing to run on German or Irish AWS servers doesn't really buy you
much. But, ProtonMail not only has all of its servers located in Swiss
datacenters, it also: 1) Is a Swiss corporation fully under the jurisdiction
of Swiss law (which also means it operates under strict customer data anti-
retention requirements) 2) Holds its funds in a Swiss bank 3) Has corporate
officers that reside in Switzerland 4) Offers .ch e-mail addresses and a .ch
web interface that cannot be taken control of through US courts and that are
resolved through Swiss DNS servers 5) Is using a non-US (Swiss) Certificate
Authority (QuoVadis) for its certificates.

2\. This is true. However, it's true about every web service. It is also true
about any software that is either distributed over the web/TLS or has security
updates distributed over the web/TLS. It also includes any software that runs
on platforms that have patches distributed over TLS. That is nearly
everything. It's no more difficult to insert malicious code into web apps than
it is to insert it into mobile phone apps, desktop apps, or operating system
patches when working with a compromised trusted TLS connection. While some may
say that non-web apps have code signing or application signing keys, the fact
is that most of either the signing or verification keys for those application
code signature schemes are distributed over TLS. There are devices out there
with trusted hardware and embedded keys and some groups are starting to make
use of proper TPMs. But, high quality trusted platforms are beyond the reach
of most consumers and developers. I know of no platform that would catch the
insertion of malicious code by a determined third party with the ability
compromise a TLS session in the release and/or development cycle. If webapps
are faulted and everyone is using a webapp (github) to develop, well then,
everyone is essentially equally compromised. The same goes for distributing
updates or public keys for validation of code signatures.

3\. The company did, in the early days, see Lavabit as a inspiration. But, our
systems are very different. Our systems are "can't read your mail" not
"promise not to read your mail". Proton has no need to avert its eyes. There
is no "plaintext in and plaintext out". There is no transmission of the
private key decryption passwords back to the server. I don't think your
comparison holds. The way Proton works is that the encryption is done in the
browser. A non-encrypted private key is not stored, or ever sent to, the
Proton servers. An openPGP keypair is generated in the browser by the user.
The public key is sent to servers and stored in a database. The private key is
encrypted in the client's browser, with a passphrase the client enters, using
the opensource openpgpjs library. That encrypted (with a password that is
never sent back to the Proton servers) private key is sent to the Proton
servers and stored in a database. When a user logs in, their encrypted openPGP
key is sent down to their browser with their public key encrypted e-mail.
Their web browser then decrypts their private key and uses it to decrypt their
email on the local computer. We never have to avert our eyes from their
passphrase because it never transverses our systems. The decryption is done
locally. Obviously, it would be better for us not to store the private key
(even though it's strongly encrypted). But, that's just not practical for a
webmail application.

So, I'm sure everyone is wondering: What would a TLS based ProtonMail
compromise look like? Well, modified code (nefarious javascript) would be
injected into the TLS stream that would send the user's decrypted private key
and/or private key pass phrase to a third party or otherwise expose it (as
invalid packets, etc) in the stream. Or, carefully selected cryptographic
primitives would be inserted into the software. I contend that these are the
same vulnerabilities someone faces downloading GnuPG from it's distribution
sites, downloading Firefox/Chrome/IE, or even applying Windows/Linux updates.

And, I'm also sure people are wondering: What would a US Government compromise
of the ProtonMail servers look like? Well, I'll leave the details out on how
the US Government might get their hands on Swiss domiciled servers... maybe
something like the time they cut through a datacenter wall at MIT in the
middle of the night to get the early PGP code. Let's just assume they have the
servers. They'd first have to break the disk encryption. Once they broke the
disk encryption, they'd have to break into the database. Once they did that,
they'd basically have a bunch of AES encrypted keys that they'd have to run
password guessing attacks on.

ProtonMail is trying to bring cryptography to the general population to
protect the basic human right of privacy. We are doing webmail the best
possible way webmail can be done because webmail is the primary method of
communicating for the vast majority of people today. We are not going to get
our grandmas to sit in Faraday cages and work on trusted platforms with one
time pads that they exchanged at their church groups and yoga classes.

There is no security through obscurity in what we're doing. Honestly, I'd be
honored if you took a look. We use Signal internally. I've read through the
code and was very impressed. I couldn't find a single flaw that I could
exploit. Perhaps, you'd even be willing to do a consulting engagement to audit
us?

~~~
zimbatm
> 2\. This is true. However, it's true about every web service. It is also
> true about any software that is either distributed over the web/TLS or has
> security updates distributed over the web/TLS. While some may say that non-
> web apps have code signing or application signing keys, the fact is that
> most of either the signing or verification keys for those application code
> signature schemes are distributed over TLS.

If you install Debian you have to make sure that the ISO was not compromised.
You can do that by calling a third-party and compare the published checksums
or any out-of-band solution. Once this base of trust is established you are
good to go. In fact updates are fetched over plain HTTP because all the
updates are signed using GPG.

Now compare with any "web crypto": every time the user loads the page he
starts back from zero. An attacker can MITM at any time and inject a trivial
`form.onsubmit=sendCredentials` and your user is compromised. There is no way
to verify out-of-band that the distributed JavaScript is coming from
ProtonMail and even if there was, it would have to be done on every page load.

~~~
forgotpwtomain
> If you install Debian you have to make sure that the ISO was not
> compromised. You can do that by calling a third-party and compare the
> published checksums or any out-of-band solution. Once this base of trust is
> established you are good to go. In fact updates are fetched over plain HTTP
> because all the updates are signed using GPG.

It's hard to take this seriously - do you really call a third-party every-time
you rebuild a Dockerfile and run update with your package manager? 99.9% of
developers deploying to production do not. If anything the best guard we have
is for Debian (as in your example) to realize their keys have been compromised
(probably by someone else suffering from such an attack) and alert their
users, this has an inherent delay.

> Now compare with any "web crypto": every time the user loads the page he
> starts back from zero. An attacker can MITM at any time and inject a trivial
> `form.onsubmit=sendCredentials` and your user is compromised. There is no
> way to verify out-of-band that the distributed JavaScript is coming from
> ProtonMail and even if there was, it would have to be done on every page
> load.

As I wrote above, your concept of verification is quite unrealistic - but even
with that I would say it's fair to say the danger of a SSL cert for "web
crypto" being compromised is definitely greater than for the desktop since
even Dockerfiles are rebuilt far-less than web-pages get reloaded, so a much
greater number of users would be affected before they became aware.

I tend to think protonmail is a good thing -- it's obviously not the best
choice if you need as many security guarantees as possible, but for general
population this is a strong improvement over sell-all-your-data to advertisers
google mail.

~~~
cornholio
There's really no comparison between the two scenarios. Hacking the MIT server
or distros to replace the GPG code is an incredibly noisy attack, which will
leave an evidence trail the size of Utah, home state of NSA. It's a risky
attack because you don't have selectors (don't know to whom to provide the
trojanized code) so you will necessarily infect more targets than necessary.
There are also multiple manual and automatic tripwires, MD5 hashes, code
signatures etc. that must be circumvented, and triggering any of them will
blow the whole thing open and lead to public outcry. It's also currently
illegal and leaves binary forensic traces in the infected machines. On the
other hand, forcing an email provider to colaborate is standard legal practice
(Lavabit), you have a perfect selector (the email address of the target),
there is no tripwire, and getting the key will permit you to decrypt al past
and future communication. Once the user closes the browser, the evidence is
gone. Easy as pie.

So while in principle the threat model is similar, the practicalities of the
two situations are vastly different, questioning the whole "we want to provide
practical security" mantra.

~~~
forgotpwtomain
> There's really no comparison between the two scenarios. Hacking the MIT
> server or distros to replace the GPG code is an incredibly noisy attack..

What percentage of the packages you use in a production deployment are GPG
signed? I think the minority.

> On the other hand, forcing an email provider to colaborate is standard legal
> practice (Lavabit), you have a perfect selector (the email address of the
> target), there is no tripwire, and getting the key will permit you to
> decrypt al past and future communication. Once the user closes the browser,
> the evidence is gone. Easy as pie.

This is totally irrelevant to the current conversation. As it was discussed
protonmail uses client-side crypto with PGP signed messages -- meaning the
only thing they store is your encrypted keys.

Yes, if Protonmail could be forced to serve passphrase stealing javascript
then your encrypted keys would be vulnerable - but so would you if Debian was
forced to serve a keylogger as a kernel module. btw I do agree that SSL is a
much higher-risk factor than a linux-system with a local mail-server using PGP
- but I don't see a better alternative than something like protonmail for the
majority of consumers.

~~~
cornholio
>Yes, if Protonmail could be forced to serve passphrase stealing javascript
then your encrypted keys would be vulnerable - but so would you if Debian was
forced to serve a keylogger as a kernel module.

That's exactly what I'm saying, the situations are not remotely comparable,
reasons as stated.

------
DavideNL
It's really nice to have this kind of privacy, but I don't understand how
people can use a service like this while they don't provide the ability to
make local (encrypted) backups.

If their servers disappear for whatever reason (legal issues or hardware
problems), you end up with 0 e-mails. Nothing.

Tutanota.de has the same problem, no backup feature.

------
denova
If you care enough about privacy to sign up for protonmail, why not just learn
how to use pgp? It's not perfect, but it works. And... oh goodness, I'm
looking at this [support page][1]; If you send encrypted mail to non-
protonmail addresses, the recipients have to open the message in a web browser
and enter in a password to read it. So instead of exchanging public keys, you
have to send them a password, probably over an unencrypted channel. I guess
it's easier than asking them to generate a keypair. But if your recipient is
too lazy to set up pgp, they're probably going to be just as annoyed at having
to open your message in a browser and enter in a password, right? It seems
like an awkward compromise.

[1]: [https://protonmail.com/support/knowledge-base/encrypt-for-
ou...](https://protonmail.com/support/knowledge-base/encrypt-for-outside-
users/)

~~~
modernerd
Even Phil Zimmermann, PGP's creator, says it's too hard to use:

“I hardly ever run PGP. When people send me PGP encrypted mail I have to go
through a lot of trouble to decrypt it. If it’s coming from a stranger, I’ll
say please re-send this in plain text, which probably raises their eyebrows.“

[http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-
bi...](http://www.forbes.com/sites/parmyolson/2013/08/09/e-mails-big-privacy-
problem-qa-with-silent-circle-co-founder-phil-zimmermann/)

I tried the ProtonMail password protection feature today (which is optional;
you can just send plain text email to non ProtonMail accounts if you wish –
this is the default, but you can click a lock to password-protect any outgoing
message).

The feature is well done, and I can see people using it to exchange secure
mail, particularly if the recipient does not have a ProtonMail account. It has
a built-in 'send secure reply' feature once you've entered the password as the
recipient. This allows you to read the message and reply in-browser without
returning to your email client, and without having a ProtonMail account, so
both the outgoing message and the reply stay more secure than regular email
throughout your conversation.

This could be helpful for a wide range of uses, including support email that
involves transferring login info and logs.

The read and reply flow looks like this to the logged-out recipient:

\- Email with “view secure message” prompt:
[http://d.pr/i/1cwZ8](http://d.pr/i/1cwZ8)

\- Click “View secure message”: [http://d.pr/i/13GlI](http://d.pr/i/13GlI)

\- Enter password to view message: [http://d.pr/i/11Gg9](http://d.pr/i/11Gg9)

\- Click to reply in same tab: [http://d.pr/i/WWWB](http://d.pr/i/WWWB)

You still have to communicate the password securely somehow, but it's a much
more user-friendly approach than PGP.

I'm not saying it's a replacement for
[https://securedrop.org/](https://securedrop.org/), but it still has value.

~~~
tptacek
"PGP is hard to use" is more memetic than accurate. What makes PGP hard is
that it has a million options, and its vocal users (and detractors) seem
insistent on availing themselves of as many of them as possible.

In reality, 80% of PGP's value (which is more value than you'll get out of any
webmail system), you can get with three command lines:

    
    
        gpg -sear recipient@addr document.txt
    

_Encrypt and sign a document, ASCII armored for inclusion in a 7-bit email, to
a specific person or persons_

    
    
        gpg -a --export my@addr
    

_Dump your public key for out-of-band transmission to the peer you 're
exchanging messages with_

    
    
        gpg document.txt.asc
    

_Decrypt a message sent to you by someone else_.

No keyservers. No subkeys. No crazy formatting. No exotic key types. Send a
message to someone, read a message back from them.

You don't get forward secrecy (unless you manually rotate keys). You don't get
peer validation unless you do it manually. You don't get real time chat. You
can't encrypt a videoconference. On the other hand: you won't be the subject
of someone's amusing blog post a year from now, either, because PGP used this
way has been reliable for something like 15 years running.

Everyone I know who actually uses PGP, like for real, more than a couple times
a year, uses it pretty much this way.

~~~
duaneb
If those commands are so simple, why are they not built into chrome? Honest
question. It's where I actually write my emails.

~~~
Freak_NL
If a browser provides an OpenPGP API, than how would I know whether or not a
website uses it properly? What is to stop a compromised webmail provider from
serving me a web page that claims to use this API to encrypt my message before
sending it, but also simply sends the plain text message captured from the
mail composition page along?

You are typing your sensitive message right there in the browser, in the web
page provided by them, with JavaScript provided by them, which can simply send
whatever you type directly to their (compromised) server.

This means OpenPGP in the browser is technically feasible, but very insecure
because a third party can access the data before it is encrypted. To make a
browser provided OpenPGP API work, it would have to provide the input area
where you type your confidential message in a way that makes it clear it is
the browser that provides it, and the web page JavaScript cannot access it
before encryption. This is of course exactly what stand-alone e-mail clients
do, so why implement it in the browser?

~~~
duaneb
Welp, you successfully dissuaded me from ever looking into pgp.

~~~
tptacek
Hopefully, then, they've dissuaded you from all browser-based crypto.

------
waffl
Apart from the discussion surrounding the crypto side of all this, one thing
that ProtonMail has really succeeded in doing is making encrypted mail finally
an accessible thing to a non-technically inclined user.

I've spent well over a year trying to get my team to properly gpg encrypt
sensitive files only to constantly find them sending plain unencrypted files
over slack, dropbox and even simply gmail.

At least now, finally, they've found ProtonMail easy to use and are choosing
to send files this way.

I think the key, unfortunate reality is that until the end user doesn't have
to think about encryption, they aren't going to bother using it. Bringing
usability to encryption is another huge part of the problem that needs to be
considered as it is basically a guarantee that the typical user will take the
path of least resistance.

~~~
e12e
I'll say this, a service like this _is_ great from the network effect alone.
While I might not think it's secure, it'll allow me to set up a traditional
email-client+gpg and send encrypted email to people. And it'll provide a way
for people to migrate to secure email, at a later point.

Much like I could for a brief moment actually talk to people over XMPP until
Facebook and Google cut off the limited support they had for it. Most of those
I talked to used the horrible web interface of Facebook/Google talk -- but _I_
could use something that made sense. And I could even talk securely to some
people on Facebook, as OTR worked fine over Facebook XMPP chat (while
obviously breaking the web interface).

------
m0xy
These guys got attacked recently by a DD4BC outfit and paid the ransom. I
wouldn't trust them with a shopping list, let alone my email.

~~~
saganus
Do you have any sources for this?

I haven't heard about this before and would like to know more if possible.

~~~
wsha
It's mentioned in the article linked here.

------
zokier
> The app is a good example that even if they government forces US companies
> like Apple to create backdoors, users will still have communication options
> that the government can't crack. If you're interested, it's now available
> for Android, iOS or the web.

That is immensely misleading. If some adversary has a backdoor in the
OS/platform, then in many cases no amount of encryption will save you.

~~~
bisby
If you input your encryption passphrase on a keylogged device, your entire
encryption userspace falls apart.

~~~
TheDong
not if you do your crypto on a dongle (such as a yubikey), at which point they
also need physical access to get the private key.

It's perfectly viable for services like protonmail to allow 2FA via a dongle
which would _not_ be compromised permanently by a totally pwned userspace.

~~~
e12e
If you input your emails on a keylogging device, your emails are compromised.

------
jakeogh
Folks interested in rolling their own, checkout
[http://github.com/jakeogh/gpgmda](http://github.com/jakeogh/gpgmda)

It's rough around the edges (and elsewhere) but works for me.

------
runn1ng
I remember when people used to flick to HushMail as the preferred encrypted
e-mail provider. Where are they now?

~~~
zokier
HushMail... wow, that's some history right there. Anyways, they got in bed
with feds, and that was pretty much the end of that..

[http://www.wired.com/2007/11/encrypted-e-
mai](http://www.wired.com/2007/11/encrypted-e-mai)

~~~
runn1ng
"Even we cannot read your e-mails!"

Exactly what those guys said 10 years ago, and exactly what Proton is saying
now.

What is different?

~~~
LeoPanthera
The difference is that they are lying. Hushmail encryption is not end-to-end.
[https://en.wikipedia.org/wiki/Hushmail](https://en.wikipedia.org/wiki/Hushmail)

~~~
Flimm
You're correct. It can't possibly be end-to-end, since they have the keys, and
they can provide webmail. They use OpenPGP but they give themselves the
private key! This is dishonest, in my view.

------
rdl
There are lots of drawbacks to an SMTP based service vs. something built on a
newer protocol with client-side crypto everywhere, but email has a huge
installed base. This becomes a question of "good" vs. "perfect", but it might
also be a question of "too dangerous to use" vs. "replacement" \-- depends on
threats, alternatives, and quality of implementation.

I know one of the people at Proton Mail pretty well, and have met the others.
Of all the companies doing secure email right now, they seem like the best.

~~~
drakenot
I was curious to read about any proposed successor protocols there are for
SMTP that offer end-to-end encryption. It looks like Dark Mail might be one of
the forerunners in this regard?

------
hackuser
A few critical questions:

1) How are spam filters implemented if they can't access the content?

2) How is metadata protected?

3) Also, can I use POP/IMAP and store my mail locally, or must I trust them
with my data?

~~~
jboynyc
Regarding 3, no, there is no protocol to store mail locally. You have to use
webmail or one of their applications.

[https://protonmail.com/support/knowledge-base/imap-smtp-
and-...](https://protonmail.com/support/knowledge-base/imap-smtp-and-
pop3-setup/)

~~~
e12e
It's odd. Seems like a no-brainer to allow power users access over IMAPS; just
put the encrypted private gpg key in an IMAP folder, and let the users mirror
their encrypted mail.

------
chatmasta
The fundamental problem with e2e encrypted email, outside of the many
technical limitations, is that the encryption is only as strong as the weakest
link. Every member of an email chain must support the e2e encryption in order
for it to work. One unencrypted sender/receiver is sufficient to break the
whole model.

So if you want encrypted email, you can only communicate with other people
using the same encrypted email stack.

What's the point of that? If you're paranoid enough to the point that you're
using encrypted email and you can convince all your correspondents to use it
as well, then you have far better options available to you than email.

It really makes no sense to me... It's 2016, there are thousands of ways to
communicate online, many of them encrypted. Why force the use of email?

We would all be far better off if we just assumed that all email is public. If
you need private communication, don't use email.

~~~
ohthehugemanate
The way Protonmail and co try to solve this problem is by sending the non-
protonmail recipient a notification email, with "click here to read". From
[https://protonmail.com/security-details](https://protonmail.com/security-
details) :

"We support sending encrypted communication to non-ProtonMail users via
symmetric encryption. When you send an encrypted message to a non-ProtonMail
user, they receive a link which loads the encrypted message onto their
browser, which they can decrypt using a passphrase that you have shared with
them. You can also send unencrypted messages to Gmail, Yahoo, Outlook and
others, just like regular email."

~~~
Flimm
At that point, you might as well send people invites over email to switch to
using a completely different messaging system that is more secure.

------
swordswinger12
Can you search your emails? If so, how is the search index stored? Is it local
or stored at ProtonMail?

~~~
msh
It's webmail. Everything is stored on their servers.

~~~
mchahn
It can't be searched on the server. The article says "The app is encrypted
end-to-end and, like Apple's iPhone, can't even be accessed by the company
itself."

~~~
msh
Everything available OB the app is available in the webinterface (I am a
protonmail user)

------
SonicSoul
_The strong encryption makes it impossible for the company to comply with
government demands for data. And since ProtonMail and its servers are located
in Switzerland, there 's nothing that US authorities can do to shut it down.
The company gained a lot of publicity, much of it bad, when a leaked document
revealed the app was a preferred choice for ISIS terrorists._

Couldn't any company host their servers outside of jurisdiction and bypass US
laws? I wonder how US gov't plans to work around this.

~~~
junto
They'll do what they did to Wikileaks. The USG phone Visa and MasterCard CEOs
and threaten the shit out of them personally. Suddenly you lose the ability to
take credit card payments.

You can turn to Bitcoin, but that's like trying to quench the hunger of a
million people with one faucet.

Plus if you are an American then it doesn't matter where your servers are
hosted. The men in black suits are going to be knocking on your door.

~~~
mtgx
> The USG phone Visa and MasterCard CEOs

Don't forget Amazon. Never forget Amazon:

[http://www.theguardian.com/media/2010/dec/01/wikileaks-
websi...](http://www.theguardian.com/media/2010/dec/01/wikileaks-website-
cables-servers-amazon)

~~~
MichaelGG
Amazon's pretty corrupt. Apart from Wikileaks they've also decided to abuse
their position and not compete by refusing to sell Apple TV or Chromecasts.
Just get a 404. Their service reps deny everything and say it's just a
temporary stock issue or that they "lack the contracts to sell such products".
Scummy, and I'm very reluctantly cancelling prime over it, and I'm a customer
of 13 years.

~~~
junto
Can you explain the background to this story? This is because they only want
to sell their solution?

~~~
MichaelGG
[http://www.theverge.com/2015/10/2/9439281/amazon-ban-
apple-t...](http://www.theverge.com/2015/10/2/9439281/amazon-ban-apple-tv-
chromecast-why)

Their supposed explanation (though several CSRs denied this) is that people
want Amazon Prime Video (heh ok), and Chromecast/AppleTV doesn't "support it".
Hence they are refusing to sell these devices.

In reality it seems far more like a pathetic death throe of the folks running
FireTV or a response to the (most likely?) low uptake of the poor Prime Video
offering.

The thing is they are so entrenched (I spent a lot on Amazon, and Prime is a
main reason) they can really shut hurt products by refusing to carry them.
Ordering via someone else is a pain. (I used jet.com to buy Chromecasts and
they're so, so, far from Amazon.)

------
yaelwrites
Here's a deep dive into ProtonMail's claims on Wired (disclosure: I wrote it)
www.wired.com/2015/10/mr-robot-uses-protonmail-still-isnt-fully-secure/

------
jaguar86
> Our primary datacenter is located under 1000 meters of granite rock in a
> heavily guarded bunker which can survive a nuclear attack.

Would they seriously have done this on intent?

~~~
nickik
Switzerland has a lot of bunker, it probebly cheap to get one and its a cool,
but gimiky feature.

------
dil8
Is this service open source? How can we know it does what it says it does?

~~~
zokier
> How can we know it does what it says it does?

How does being open source help with that?

~~~
infodroid
Open source makes it is easier for security experts to review the code and
determine whether it meets its security claims. If it is closed source, then
there is no guarantee that the code the experts review is the same code that
is used by the service. And also it is at the company's discretion whether to
allow a security audit or not, and then which auditors to allow or exclude.

But if the whole of the client software is open source, then it also
eliminates the need to trust binaries provided by the vendor (which can be
MITM) because you can build the software yourself or use a version audited by
an entity that you do trust.

~~~
mtgx
That, also the fact that if they have it in their privacy policy and website,
then we can call them out on it when they insert a backdoor or remove the
encryption. We can't say the same about Whatsapp and its end-to-end
encryption, because they never even publicly admitted to using it. How can we
ever hold Whatsapp responsible for _not_ using end-to-end encryption then?

We _can_ do that with Protonmail.

