Hi all, I've been trying to decide how to weigh in on this thread, I'm sure some of you are surprised its taken me this long to jump in. That said, I'll keep this brief, because I'm going to write up more detailed thoughts on a blog post that I'll share with the list. The first issue I see is related to this succinct comment from Michael: That's only speculation on my part, of course. But if it's right, it

raises a difficult question: how do we maintain rigorous standards of critique within the information security community, without giving potential users of our tools the counterproductive impression that nothing works and you might as well give up?

The number one issue I see here is the culture of what i call "geek rage" "fear mongering" and "black and white response" First let me say I think this is *getting better*. However, it stands that there are *many* privacy/security tools with fairly significant flaws. I'm writing a security curriculum at the moment for a new mobile reporting app that SWN is creating. In the process I've begun to see bevy of flaws in tools that I myself misunderstood previously. A few of these tools are Truecrypt, TextSecure, OTR clients, and of course Cryptocat. I think there is a lack of clarity about "safety" and "security" as well as numerous other semantic problems with the way security experts, trainers, and researchers present tools. Truecrypt's issue with journaling filesystems is a flaw that many of the members of the list are no doubt aware of. I however was not aware of this serious issue. The Protektor Services and FrontlineDefenders Digital Privacy manuals do not cover this issue, yet TrueCrypt is now considered a standard tool by most organizations doing training. I recently assisted an "internet freedom" training on TrueCrypt, yet I was unaware, which means even if the issue was covered(I am fairly certain it was not) it wasn't covered well enough that I, a relatively knowledgeable user, picked up on it. Cryptocat's web interface as has been clearly described is only as secure as SSL/TLS and the lack of a keylogger. However, the implication of this discussion is that a MITM attack or having my IP address is enough to identify me. I am sure most of you don't believe this, however that is the implication of your talk. The primary issue comes down to the semantics and lack of clarity in communications. I think this could be solved by recruiting more people with strong writing skills and a focus on training methodology, and perhaps starting to host roundtables and dinners with the technologists in the group. I would love to have been at dinner with Nadim Jacob et al. I think this could be solved by creating an open consortium of technology researchers, trainers, and practitioners. Last point, I agree we are helped by a diversity of manuals, but a lack of clear standards is frustrating. Furthermore, I'm certainly not satisfied with the guides that exist, which is why I am still working on crafting new manuals, however the curriculum I'm currently producing is essentially an effort to edit and collate the best elements of the existing manuals. I hope this will result in a hybrid that still answers a lot of needs, but does it in a more user-friendly fashion. Brian On Wed, Aug 8, 2012 at 10:22 AM, Michael Rogers <michael@briarproject.org>wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 07/08/12 06:19, frank@journalistsecurity.net wrote:

...

How many people on this list have spent time asking non-technologists and other users who have tried, but have since given up even trying to use tools like PGP? Or have examined how new users interact with such tools? I have a great deal of respect for this community. But to be honest it seems to me that neither the technologists nor the donors have spent much time asking such questions.

Hi Frank,

I'd just like to make an anecdotal point here. A few months ago I spent an interesting afternoon talking to some activists in the UK about what communication tools they use for what tasks.

None of them regularly used PGP, Tor, or disk encryption software, but the reasons they gave had nothing to do with usability. They were aware of the tools and knew how to use them, but they didn't believe that doing so provided any practical security benefits. They believed that encryption software probably contained backdoors and could be defeated by keyloggers. They'd seen evidence trails from computers and phones produced in court, and rather than relying on technology to solve technology's problems, some of them preferred to avoid electronic communication altogether for secret work.

It's tempting to say they were right and leave it at that. Keep your secrets away from your gadgets and your gadgets away from your secrets. But that wasn't what they were actually doing. They all carried phones, even though they knew they were being tracked and possibly bugged. They all had email accounts, and some of them used mailing lists and forums for planning, even though they knew that if a keylogger could get their encryption passwords it could get everything else they typed. Why the apparent inconsistency?

One possible interpretation is that they were assessing encryption tools with a typical information security mindset: if there's any weak point, the adversary will exploit it, so the strong points are irrelevant. But they were assessing other techniques with a more balanced mindset: weigh up the risks and potential benefits, compare the available alternatives, and choose the best (or the least bad).

That's only speculation on my part, of course. But if it's right, it raises a difficult question: how do we maintain rigorous standards of critique within the information security community, without giving potential users of our tools the counterproductive impression that nothing works and you might as well give up?

Cheers, Michael

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJQIqBNAAoJEBEET9GfxSfMRLEH/04+ESJyNH9S6NYEwno1BvKe J8kMLCmR6OpolJ15nu3K7GkE4wQnhTmZVIrHApjWGz+8TACGiIQg7rOBl19r4MvA o/7tANsoUEgLRAO2hHQzA5tg+ZRtS+9oDe6LBVE3arHTCt9dYMW711ToOkgQwdoD ekNWbC4Ba2aKm3t8JmSUF+goDiadF+nSP0HByvNhKHCjzP/2SLBxDOQqeOMF/kpK Zej+0BZPCUGLaN6XaqoWw7DxgYfa9uUgx3E2ljwYnZZqcXr41kJp2uHQTZlExyxN TfiI+2P4bQfJtkK7KcOZtp/QWCAz3whmqV6F5y3tjfcHiEywzByInnKFr3tT5D0= =mHhw -----END PGP SIGNATURE----- _______________________________________________ liberationtech mailing list liberationtech@lists.stanford.edu

Should you need to change your subscription options, please go to:

https://mailman.stanford.edu/mailman/listinfo/liberationtech

If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?"

You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech

Should you need immediate assistance, please contact the list moderator.

Please don't forget to follow us on http://twitter.com/#!/Liberationtech

-- Brian Conley Director, Small World News http://smallworldnews.tv m: 646.285.2046 Skype: brianjoelconley public key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEEF938A1DBDD587<http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE827FACCB139C9F0> _______________________________________________ liberationtech mailing list liberationtech@lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE