[liberationtech] FW: The security and ethics of mapping inrepressive environments

[P.A.Bernal at lse.ac.uk]

As someone who works primarily on the academic side of things (you might have seen my piece at http://therightsfuture.com/side-tracks/st5-the-internet/) but has also done work with NGOs, I'd just like to add a few comments - everything that Eric and Jonah have said ring true for me too. There's a level of foolhardiness, a level of lack of time/overwork, a level of technical expertise that's absent, and sometimes a sense of being overwhelmed by the technical details and the options available.
 
>From my perspective, what would ultimately help would be what might loosely be called the 'mainstream' to embrace privacy and security - if the mainstream players saw privacy and security as important enough to take a stand against those in authority and those doing the surveillance, then the whole game could shift. If mainstream software incorporated what was needed, then it would be much easier - and what that needs is for privacy and security to be a selling point. I don't think that's just a pipedream - when Twitter fought the gagging order over revealing the details of individuals 'associated' with Wikileaks that was at least one sign that doing 'the right thing' could be seen as 'marketable' in the face of pressure from some of the strongest of authorities.
 
In turn, what that needs - again from my perspective - that the good tools continue to be developed and pushed out there, so that when the tipping point is reached, the mainstream has something it can latch onto and use. And it means that we should be trying to find ways to work with the mainstream rather than against it...
 
Paul Bernal

________________________________

From: liberationtech-bounces at lists.stanford.edu on behalf of Eric King
Sent: Wed 2/9/2011 12:33 PM
To: Jonah Silas Sheridan
Cc: liberationtech at lists.stanford.edu
Subject: Re: [liberationtech] The security and ethics of mapping inrepressive environments



Echoing Jonah here. I work for a few human rights NGOs, and Skype is not only used but also trusted.

This is from groups who cross boarders with blank laptops, install their flavour of OS, get PGP up and running and are constantly looking over their shoulders - all the while calling home with Skype. Some have been caught out as a result in the past, but just haven't known what else to use.

Those NGOs that do serious work, in serious places, all have the required foolhardiness about their own safety that allows them to do their job, but are equally terrified of exposing their friends/ informants/ clients to the same risks. They are increasingly taking this seriously and as a result, they are reaching out to try and find better solutions. I now spend a lot of my time answering NGOs questions on these issues (which I am only semi qualified to do) while trying to make connections between NGOs and the tech community.

>  Is it really a question of building the better tools and then pushing them out?

It's also about how to go about building these better tools in the first place. Enabling conversations to take place so techies better understand NGOs needs, and build tools they can actually use. In my experience it's a lot less about convenience, which is often pointed to as the reason people don't choose the secure option, and much more about efficiency. NGOs are tiny, and some best ones are often <5 focused people. In this environment, it's not that they don't want to be better protected, but they just don't have time (or money) to waste on figuring out new software, testing it in the field, when that time needs to be spent getting a habeas petition in on time.

Eric


On 9 Feb 2011, at 07:23, Jonah Silas Sheridan wrote:

> Thanks for posting this Katrin.
>
> I am actually impressed by the writeup, as it is far beyond what most
> activists I have been around are doing. My own concern would be why
> encryption gets short shrift - why no encrypted local filesystem, why no
> PGP emails, etc. Without those tools, deleting sensitive materials
> (logs, files, emails) just made the forensics harder, not impossible....
>
> Although I agree *absolutely* with Jacob, I have worked with numerous
> U.S. based NGO's, many doing international and/or human rights work, and
> don't think I have ever gotten a single individual to conform to even
> these incomplete best practices. And that lack of movement, it seems to
> me, is the true barrier to penetration of these better tools.
>
> I think the Skype use case is a good example. As Danny stated:
>>> Right now I'd say people
>>> feel it falls in the  "gmail" category - not the best thing to use by
>>> a long chalk, but certainly better than nothing.
> And:
>>> The in-the-wild attacks on Skype
>>> users I *have* heard all involve attacks that compromise the client
>>> or obtain user passwords through malware. That combined with the
>>> circumstantial evidence that of state-actors' apparent fury at Skype
>>> for not providing intercept access would seem to point that it's not
>>> *garbage* per se. Or at least make it hard to compellingly onvince
>>> people to move off it.
> My own observations from working with NGO's mirrors Danny's. Folks are
> using Skype, warts and all, because it meets their immediate need better
> than the alternatives, which almost all demand some level of technical
> facility/staffing/training to operate and so are a non-starter for most
> of them. And this cultural bent around seeing Skype as
> anti-authoritarian, and "common enough" does not help the cause of those
> of us trying to redirect the narrative to potential harmful outcomes and
> alternate best practices, regardless of the threat model. In short, it
> just "doesn't matter enough" and the possible harm is abstract enough
> (and counter to the status quo) to overcome the barriers to better
> solutions.
>
> My restating of Jacob's quick response is that these harmful outcomes
> are very real and that the vulnerability arises from Skype's
> architecture. Because they use proprietary encryption and transport
> methods, there is no way to properly audit Skype for security. Beyond
> that, they are clearly known to use vulnerable components (e.g. VBR) in
> their product. This is why Jacob states it is their responsibility to
> prove to us it is secure, not the other way around. In turn the only
> way, truly, to verify the insecurity of the tool is when there is a
> breach, and that could have terrible consequences. As I have often told
> folks, "You don't want to discover your systems were insecure through
> somebody in your community's death, incarceration or repression." Is
> that a fair restatement? Can you imagine using that to successfully make
> a "compelling case" to a non-techie on why not to use Skype? Me neither...
>
> My answer then to Danny's question about how Skype is compromised is
> that it doesn't matter, or it matters less than the sector wide
> acceptance of the status quo over the facts of the matter, or the
> opinions of "us experts."
>
> So my question to the community is how we shift the conversation within
> organizations/communities of activists to one not of perceived risks
> (non-risks), or industry norms, but of actual effective steps to
> protecting yourself and those with whom you communicate? Is it really a
> question of building the better tools and then pushing them out?
>
> Hope this is a useful addition to the conversation -- writing it up was
> very helpful for me to organize my thoughts on these issues. :-)
>
> Jonah
>
> --
> **********************************
> jonah silas sheridan
> email:jonahsilas at jonahsilas.net
> skype, gchat, twitter:jonahsilas
> **********************************
>
> _______________________________________________
> liberationtech mailing list
> liberationtech at 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.
>
> Should you need immediate assistance, please contact the list moderator.
>
> Please don't forget to follow us on http://twitter.com/#!/Liberationtech
>

_______________________________________________
liberationtech mailing list
liberationtech at 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.

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

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



Please access the attached hyperlink for an important electronic communications disclaimer: http://lse.ac.uk/emailDisclaimer