[liberationtech] CryptoParty Handbook

[Jacob Appelbaum]

Asher Wolf:
> On 9/10/12 9:46 AM, Jacob Appelbaum wrote:
> 
>> I'm sorry to say it but a lot of the users have been here for a while -
>> most people that use crypto just don't know they're doing it.
>> Ironically, if users don't get good advice, they'll just be in the same
>> spot - thinking they're safe when they're not - all over again!
> 
> That's what we want to avoid.
> 

I think a key way to avoid such issues is to teach critical thinking,
threat modeling and to state some principles as guidelines up front. As
an example - I reject non-free software, especially for non-technically
interested users - they won't reverse engineer the software and their
friends are unlikely to do so either. Some really talented people do it
regularly and they are so statistically irrelevant as to be non-existent.

So for me a key principle is to have Free Software as a criteria -
something that any user, technical or not - may notice about a project.
If it isn't clear if it is Free Software - we can start a discussion.

This has been a major objection of mine about previous manuals - relying
on closed tools, with closed protocols, and questionable security
properties. It probably makes sense to mention these kinds of tools but
I don't feel it is reasonable to advocate their use.

>> I think that the real changes belong in the platforms - anything that
>> requires configuration is probably already doomed to fail and screw a
>> user. 
> 
> That requires pushing developers to create user accessible, secure
> platforms.
> 

There is sadly a lot of trouble here - I think Guardian is doing a good
job with their dedication to Openness in the mobile space. I also think
that Tails is doing the same.

Some of the trouble is a lack of real UI testing - that is a real group
of users aren't consulted. OTR has done such studies and that is why the
OTR design is the way that it is - you can use it and never know, you
can know and take extra steps to protect yourself, and so on by design.

However - some people cannot afford open computers or unlocked mobile
phones, they can't afford to switch from their shiny iPhone now that
they realize they're locked into a closed platform that doesn't even
allow developers to *start* to build solutions. Android at times isn't
better but at the least, a person might opt out and switch to say,
CyanogenMod. I've actually seen it happen when an Android device was end
of life'd by the vendor and the user took their own fate into their
hands. That level of dedication is rare but far from totally absent.

I wish it was easier. Tor as an example has utterly failed to make Tor
Browser usable while also allowing other applications to use Tor on
Windows or Mac OS X. Users are endlessly confused. The pain is endless.
We're working on it but in some ways - we're not always sure of how to
do things.

As an example - I want to fork Adium and Pidgin, both security
nightmares in their own right, and simply make them Work Right without
so much as a single configuration. That is a lot of effort and it isn't
clear to me that we as a community have the resources to keep everything
updated, regularly released, and so on.

I'm open to knowing how we could do better and I take such criticisms to
heart.

>> That's generally the approach that I've seen work - everything
>> that requires 0) user education and 1) realistic honesty about threats
>> or risks results in 2) denial or mistakes or a bork'ed tool shooting the
>> user in the foot.
> 
> We don't know what we don't know. We're asking for help, and I at least,
> appreciate your imput.

I agree and understand. I also think that it is silly to *ask* users if
they know what they don't know! I think it should be secure and
anonymized by default. It should Just Work.

> 
>> Since clearly a few loud people were bent out of shape by my comments -
>> they have no idea that I encouraged you or tried to help out; so let me
>> set the record straight: go you!
> 
> Thanks, I appreciate the support. All of your contribution is appreciated.
> 

Thanks for saying that!

>> I think it is *great* to make the book and I think it is great to do it
>> with a set of unifying principles - it will help to ensure that good
>> stuff gets into the book and crappy stuff stays out of the book or is so
>> noted as crappy or contentious. I think that means that peer review is
>> essential before rushing to publish.
> 
> Agreed, and I did voice concerns at the short deadline for publishing.
> 

I think a book sprint is a great thing. I think Adam is awesome for the
efforts he has enabled with the F/LOSS manual visionary authorship and
publication model. I hope however that there is a larger community at
hand and that arbitrary deadlines for *publication* do not cancel out
improvements. We need a way to peer review sections - to add contentions
and disagreements, to remove known bad stuff, to note that some things
are unknown and so on - without that - a deadline is simply terrible.
Nothing is finished without errors and still some things may be finished
with reasonable omissions. If we *really* teach a model of evaluation
based on unifying points, I think we will get actual user feedback of
all kinds on the rest of the materials.

>> I really encourage you to put in a few chapters about the following:
>>
>>  social and technical compartmentalization
>>  targeted exploitation realities (from Core Impact to Metasploit)
>>  threat modeling
>>  intention/goal based risk analysis
>>  physical security risks
>>  practical information on real surveillance/censorship systems
>>  getting involved
>>    going from a user (to a translator or...) to a developer
>>  outlining the currently missing tools that we need to build
> 
> This list is appreciated. Thank you for the feedback.

I would have added it to the book properly if I knew where the URL was
located.

All the best,
Jake