[liberationtech] What I've learned from Cryptocat

Jacob Appelbaum jacob at appelbaum.net
Tue Aug 7 16:30:44 PDT 2012


Eleanor Saitta:
> On 2012.08.06 18.40, Jacob Appelbaum wrote:
>> Eleanor Saitta:
>>> It is true that you have to trust the server operator in both cases.
>>> However, having a server configuration which does not completely
>>> compromise user privacy (vs. the operator) by default, like Facebook
>>> does, is still a significant improvement in many use cases, as is the
>>> ability to have a diversity of server operators.
>>
>> That is only true if they play nice.
> 
> No, some potentially good server operators, in aggregate, are better for
> a population of users than a single operator known to leak data under
> many conditions.

There is currently only one. I believe that when this changes, yes,
things change and for the better. We're probably in agreement once that
changes.

> 
>> So this is where a lot of people take issue - you say "will be" without
>> the acknowledgement that SSL has major issues and that it is thus,
>> broken by many actors, right now. At least with the plugin version, we
>> can try to mitigate that harm right now.
> 
> Except that with your harm mitigation, you push many potential users
> back to plaintext, where they are guaranteed to be owned.


That isn't fair. People are using Google Chat over SSL and Facebook chat
over SSL. There is only plaintext in these models for the server itself
but the network sees SSL/TLS. So for passive sniffing, it's not
plaintext and with Google Chat in Google Chrome, it's almost impossible
to MITM that web session. That is a way harder SSL hurdle than Cryptocat
presents.

> What
> percentage of potential cryptocat users would the plugin version have to
> stop from using the tool for you to accept that there was a place for
> the non-plugin version?
>

It depends on how it is used. For example, Google Chrome to crypto.cat
with HSTS, hard cert pinning against specific keys, forward secrecy
modes for TLS, disclosure to people that a person is using the web chat
version (if say, ten people are using the plugin, and one isn't), etc -
those things make me feel a lot better about a web version.

> If it's 100%, what you're actually saying is that you would rather those
> users had no security than even a chance at security through diversity.
> 

Nah, I'm saying that unless the person is in the US, Google chat with
their "off the record" option in Chrome is basically about as good as it
gets, it's usable, offers federation, etc. I'd suggest they use Google
chat and that's coming from someone who has been targeted by the one
thing that Google can't protect against, the US government.

>>> It has been 21 years since PGP was released.  To this day, it remains a
>>> niche product at best.  Users with real world security concerns rarely
>>> if ever use encrypted email.  It is exactly this attitude which is to blame.
>>
>> Right and OTR is the counter example. Will Cryptocat be the middle
>> ground, where it's perfectly easy to use cryptography but missing key
>> items that make it safe?
> 
> OTR in a traditional thick client is an example of a tool which provides
> good security while being realistically usable for technical users with
> full access to their machine.  Don't get me wrong, it's great, but there
> are also users who can and will not be able to use it.  They need tools too.
> 

Well, Cryptocat is going to use OTR as a protocol. So we probably agree
here.

>> It seems that you're speaking generally here because otherwise, it's
>> unbelievably rude and frankly, silly. For better or worse - I've
>> contributed countless hours to helping Nadim with Cryptocat.
> 
> I am largely speaking generally, but I'm also speaking specifically in
> the sense that you've actively undermined the utility of a tool here by
> encouraging Nadim to not make it available to users who cannot install
> software, which is and was the only reason to use it.

That's not true. I have explained that rolling his own crypto, only
offering a web version, not having TLS/SSL setup properly, etc - those
are all bad to be the _only_ choice.

Furthermore - you and others keep saying that users can't install
software. I have not actually seen a Chrome browser where a user was not
allowed to install a plugin - it is all handled within Chrome, so what
do you mean? Are you saying that it's too hard to install? I mean, sure,
I'll buy that. However that is not a limitation of ability, it's a
matter of desire. If the user has the ability and the desire, a better
option should be provided. I should be able to use a fat client if I
want, a thin client if I want or no client, if I want.

To only offer the last option is very very bad news and that is why I
have actually actively helped improve this tool.

>  Having both
> versions available is a reasonable compromise, but suggesting that the
> web version never be used is counterproductive given the userbase in
> question.  I understand and appreciate your contributions in time -- I'm
> definitely not attempting to minimize that -- but you're still refusing
> to acknowledge that there exists an underserved userbase.

That's exactly why I have pushed for that compromise - which is also why
you've basically got me all wrong. Pretty frustrating. And for the web
version, I really believe Nadim needs to be straight forward and tell
people that it's about as secure as SSL/TLS and the browser - a
reasonable thing to say and a reasonably accurate thing at the same time.

All the best,
Jake




More information about the liberationtech mailing list