Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] What I've learned from Cryptocat

Jacob Appelbaum jacob at appelbaum.net
Tue Aug 7 16:38:52 PDT 2012


Moxie Marlinspike:
> 
> 
> On 08/06/2012 06:59 PM, Eleanor Saitta wrote:
>> Except that with your harm mitigation, you push many potential users
>> back to plaintext, where they are guaranteed to be owned.  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?
> 
> Let's stop using the word "plaintext," because my understanding is that
> none of the chat services we're speaking of transmit data in the clear.
>  As I see it, there are currently three possible vectors for attack with
> "existing" web-based chat services:
> 
> 1) SSL interception.
> 2) Server compromise.
> 3) Server operator.

This is exactly correct. Thank you for making this point again and again.

> 
> The technology in CryptoCat v1 does not address any of these three
> vectors, and all of them remain possible.  My position is that it's
> actually more susceptible to attack via #1 and #2 than existing
> web-based chat solutions.  I believe your position is that it improves
> on vector #3 by virtue of being not-Facebook.  (I'm curious how you
> measure #3 in comparison to GChat.)

I agree. I think GChat beats Facebook hands down - Google has forward
secrecy for SSL/TLS with GChat and their web services as a design goal.
They also don't actively mine chats and turn users in to the police (!)
unlike Facebook.

> 
> If we postulate that CryptoCat does improve vector #3 by virtue of being
> not-Facebook, it isn't a result of the technology, but simply that we've
> agreed Nadim has a better monitoring/interception track record than
> Facebook.  If that's something you think is valuable, it actually seems
> like it'd potentially be better served by having someone like the EFF or
> Riseup host a web-based and SSL-protected chat service, without brining
> any additional cryptography confusion into the mix.  A trust project,
> not a cryptography project.

I agree. Or we might consider that Riseup can run a closed access
Cryptocat server and refuse to offer the web version. Then it would be a
trust project and a crypto project.

> 
> Unfortunately for me, I'd rather depend on cryptography than people.

I'm with you.

> But I believe that CryptoCat is actually well positioned to drive
> changes in the ecosystem that will allow them to really improve on those
> three vectors in time. 

I agree with you. That is why I think it's a good discussion and part of
it is that one day, HTML5 or HTML6 might offer a secure chat function
that is actually born of Nadim's ideas.

> I think it's difficult to experiment in public
> with security tools, however, and that it's a sage decision to make a
> secure solution available (CryptoCat v2) and work on reducing friction
> while maintaining security from there.
> 

I'd say that regardless of version, to offer some "more" secure
solutions and strongly encourage use, will allow us to actually see how
many people refuse to take the better option. I'd love to see those numbers.

If say, 1 out of every 1000 use it - what kind of social norms can we
try to change to go the rest of the way? Like - what if the web client
tells everyone "hey everyone, I need a bit of help! Let me know that I
should click on the install button for the Chrome plugin!"

I wonder if that would result in peers educating their friends but also
knowing that the limits of their peer's client. I know I'd like to know
that someone was using a client that was effectively reduced to SSL -
I'd certainly take the time to set some different social boundaries.

All the best,
Jake



More information about the liberationtech mailing list