Brian, Just to be clear, you do realize that your argument assumes a user either a) has Chrome installed or b) has the permissions to install Chrome?
In a perfect world, that would be true for every user, but given how much time you've spent abroad, I'm sure you know how most cybercafes work... That said, yes...it is very easy to install and use, much appreciation to Nadim et al for implementing. -Jillian On Wed, Aug 8, 2012 at 4:43 PM, Brian Conley <bri...@smallworldnews.tv>wrote: > In my attempt for brevity, I forgot to congratulate Nadim on the Chrome > implementation. > > I'd also like to ask that anyone who is critical of pushing individuals to > implement the chrome extension please *try installing the chrome extension* > and provide us their thoughts as to whether this is still a significant > barrier to users in their mind. > > I was critical of this idea until I tried it. In chrome there is virtually > no room for error or difficulty. As someone who is generally a vociferous > critic of the lack of usability of security tools, I don't think this is a > significant barrier to entry. > > I also think there needs to be a distinction between lazy users and users > who have difficulty understanding or finding time for complex technology. > The only solution for users who are lazy is to ostracize them and > discourage anyone with security concerns from collaborating with them. The > solution for the latter user type is to build better tools, in my mind, > cryptocat is clearly on the way to doing that. > > thanks again Nadim, and others who are working with him! > > Brian > > > On Wed, Aug 8, 2012 at 11:57 AM, Brian Conley <bri...@smallworldnews.tv>wrote: > >> 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 <mich...@briarproject.org >> > wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 07/08/12 06:19, fr...@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> >> >> > > > -- > > > > 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 > -- *+1-857-891-4244 |** jilliancyork.com | @jilliancyork * "We must not be afraid of dreaming the seemingly impossible if we want the seemingly impossible to become a reality" - *Vaclav Havel*
_______________________________________________ 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
