
Introducing ProtonMail Contacts - artsandsci
https://protonmail.com/blog/encrypted-contacts-manager/
======
maggit
I'm a paying would-be user of ProtonMail. "Would-be" because it is simply not
reliable enough. It is frustrating that they are diversifying (contacts, vpn)
when I find the core product too unreliable to depend on.

I mainly have two problems: 1. The mobile client logs out spontaneously (or
crashes and logs out) every once in a while and I have to reenter both the
password and the TOTP code. Cumbersome, and really inconvenient if I'm on the
go and for example my plane ticket is in ProtonMail. (I don't know my password
and keep it in a password manager, inaccessible from my mobile), 2. The web
client logs out whenever the browser is restarted. The web browser at least
remembers the password, but I need to interact with my phone to get the TOTP
code in. This means that I end up in a state where I don't get notifications
for new mails, and I have to go and deal with it proactively. They recently
released the "bridge", which runs as a daemon and lets me access the mail via
IMAP. This alleviates the problem, but it is unfortunately still unavailable
for Linux.

Are there any other happy or unhappy ProtonMail users out there? Am I alone in
these frustrations?

~~~
stabbles
I'm happy to use a service that is not Gmail or Outlook. And I like the fact
that I can use my custom domain easily.

In the end I'm not really using it though, simply because none of my contacts
uses it. In that case ProtonMail is simply begging the question when it comes
to privacy and security:

You can set an expiry for emails to non-Protonmail recipients, meaning they
just receive a link to the contents of the email. Obviously you must also
password protect it (otherwise gmail / outlook will just follow the link). Now
the point is: how do you safely communicate the password?

Either you know how to safely communicate a password; in that case why not
send the message without ProtonMail? Or you do not know how to safely
communicate a password; what security does ProtonMail offer then?

~~~
nothrabannosir
Depends on your threat model. If you're protecting against dragnet
surveillance and _retroactive_ targeted surveillance, after your link expires,
then just putting the password right there in the e-mail body, with an
expiring link, should work fine. For now.

Especially if it's not life-or-death, but you'd just "rather not appear in the
data set, if avoidable." To each their own :)

------
shao87
Calling it the 'first encrypted contacts manager' is preposterous. What about
Tutanota and Posteo? The contacts there have been encrypted all along.

~~~
chrisballinger
Also Flock by Open Whisper Systems, which did end-to-end encrypted WebDAV sync
for Android's Contacts and Calendars. (now discontinued)

1\.
[https://github.com/WhisperSystems/Flock](https://github.com/WhisperSystems/Flock)
2\. [https://signal.org/blog/flock/](https://signal.org/blog/flock/)

------
useranme
I'd like to know more about how it works.

"The private key is generated on the client side". Does this mean it gets
generated with Javascript sent from the server? What if the server gets
hacked?

~~~
hobarrera
It's never sent to the server; the key is derived from your passphrase, so
it's never sent anywhere.

It's still possible for a sophisticated MITM to replace the JS code so that is
DOES send the key somewhere.

~~~
amenghra
fun fact: the webcrypto api does allow marking a key as non-exportable. So you
could imagine deriving the key from the passphrase and having it only exist
within the WebCrypto framework.

It is however going to be hard to prevent a malicious active attacker from
stealing the passphrase.

~~~
AgentME
The webcrypto api also can't stop the server from sending malicious javascript
to a user which when run uses the webcrypto key to decrypt the user's data and
send it back to the server. Also, if the server is malicious on the first
connection, then the server could just not use the webcrypto api to begin
with, and just make use a key that the server knows instead.

The webcrypto api is still pretty cool though. I've been hoping for an excuse
to use it sometime.

~~~
carussell
This is why we need resource pinning in the browser.

The webservice would assert that the resources it's sending now are the same
resources it will continue to send in the future. The browser is in a prime
position to enforce this.

In the event the resources ever change, then the browser should refuse to
allow the changed resources to run and notifies the user what has happened in
a way that is at least as scary as broken TLS. If it's a legit deployment
(say, because the service has updated the backend), then this should be
independently verifiable out of band e.g. via a blog post, a public changelog,
etc. The process to accept the new deployment would need to be opt-in. If the
user choices not to opt-in, the browser may continue using the old resources
that were being served up in the past.

Without some mechanism like this, verification of the claims that services
like ProtonMail makes remains intractable.

~~~
hdhzy
I don't want to sound negative but I guess almost 100% of the web relies on
quickly updating resources and being fresh so I wouldn't hold my breath for
when "resource pinning" would happen.

For the record one can already do it if all resources would use Subresource
Integrity. Hashes of leaf resources would be embedded in parent resources up
to the root document that you could announce out-of-band (e.g.
[https://example.com](https://example.com) on 23rd of November 2017 has hash
1234566...). Then you'd have a cryptographic proof (like a Merkle tree) that
nothing in the page changed.

~~~
carussell
There are no standards and protocols in place for this, and there's no browser
that enforces this.

If you think that taking something that's 80% there and filling in the last
20% for yourself counts as something that's "already" possible, then nothing
is new and everything is already possible.

> Hashes of leaf resources would be embedded in parent resources up to the
> root document that you could announce out-of-band (e.g.
> [https://example.com](https://example.com) on 23rd of November 2017 has hash
> 1234566...)

This is really janky and not at all what I'm talking about. What I'm talking
about is as simple as what happens now, e.g., "GitLab/Mastodon/Whatever XX.x
Released".

~~~
hdhzy
> There are no standards and protocols in place for this, and there's no
> browser that enforces this.

And there will never be especially for web apps because there are no parties
interested in this. Look at what happened with HPKP. It looked good on the
surface but it turned out that extreme security is a little bit too extreme.

> If you think that taking something that's 80% there and filling in the last
> 20% for yourself counts as something that's "already" possible, then nothing
> is new and everything is already possible.

I'm just pointing out that you can already construct a scheme with the same
security properties as what you described. If you'd rather wait for some
hypothetical standard and implementation that will probably never happen then
that's your decision.

> This is really janky and not at all what I'm talking about. What I'm talking
> about is as simple as what happens now, e.g., "GitLab/Mastodon/Whatever XX.x
> Released".

Perfect is the enemy of good and "GitLab/Mastodon/Whatever XX.x Released"
seems to be just good enough. For paranoid people OpenPGP is there to verify
build artifacts.

~~~
carussell
> And there will never be

Are you an authority on this? Or just trying your hand at being pundit with an
endless supply of unsubstantiated stop energy?

> I'm just pointing out that you can already construct a scheme with the same
> security properties as what you described.

No, you can't. You're writing as if the "you" here is the party in control of
the service backend—the developer. That's not what this is about. This is
about how you—the user—can trust that out of the _n_ times you visited the
site it didn't serve up tampered assets to backdoor the process. If this were
about developers, we wouldn't be having this discussion; the developer doesn't
need to request proof that he or she hasn't done any tampering to covertly
introduce a backdoor.

> "GitLab/Mastodon/Whatever XX.x Released" seems to be just good enough.

I'm convinced at this point that either you're just responding without
actually giving any consideration to the words coming from either one of us,
or I'm having a frustrating exchange with a chatbot.

 _I 'm the one_ who wrote that a release announcement on the project blog
suffices to verify out-of-band that the user should expect the resources to
change. _You 're the one_ who wrote this:

> Hashes of leaf resources would be embedded in parent resources up to the
> root document that you could announce out-of-band

So why are you now trying to explain to me that a release announcement blog
post is "good enough"? Clearly if I didn't think so, I wouldn't have argued
for it.

I won't be returning to this thread.

------
throwaway4564
I'm curious why you chose to use asymmetric crypto for this instead of
symmetric (for example, encrypting a secondary key using the primary one, and
then using that with an authenticated encryption mode like AES-GCM to give
confidentiality/integrity).

Are there plans to have the protonmail service provisionally add contact info
for the user, then have the user accept this by signing it with their private
key?

~~~
badrabbit
I can only presume,but I believe they simply want it to integrate well with
the existing protonmail public key system. Also,maybe they plan on letting
protonmail users share or send contacts(non-repudiation and authentication).

