[liberationtech] FW: The security and ethics

[Patrick Meier (Ushahidi)]

I agree with Paul's point re use of technical language.

I would also add that some technical experts in security & privacy at times
use a tone that comes across as arrogant, dismissive and belittling, making
non-experts want to avoid them entirely. Clearly, non-experts in computer
security don't know as much, but some are desperate to learn more. If
experts genuinely want to mainstream some of the security measures shared on
this list serve, one good place to start would be a change in attitude
towards non-experts.



On Wed, Feb 9, 2011 at 6:54 AM, <P.A.Bernal at lse.ac.uk> wrote:

> Agreed - though privacy by design doesn't really go nearly far enough both
> in theory and in practice.... and in practice, of course, it's much more
> often 'surveillance by design' than privacy by design. That's what needs to
> be opposed, together with the laws that seem to support or even demand it.
>
> For the purposes of this mailing list, though, there is a point I'd like to
> make from a lay-person's perspective: the technical language (not just the
> acronyms) that surrounds privacy is often highly confusing even to people
> with quite a lot of technical knowledge. What that means in practice is that
> people often just give up on it, particularly if they're short on time and
> have other highly pressing issues to deal with, as they generally do. Is
> there a way that this can be avoided? Often, of course, the level of
> technicality is unavoidable, but it would be great to try to cut through it
> at least to a degree.
>
> Paul Bernal
>
>
> -----Original Message-----
> From: Juliet Lodge [mailto:J.E.Lodge at leeds.ac.uk]
> Sent: Wed 2/9/2011 1:16 PM
> To: Bernal,PA  (pgr); liberationtech at mailman.stanford.edu
> Subject: RE: [liberationtech] FW: The security and ethics
>
> This is what I call baking security in  (part of which is referred to as
> privacy by design by officials these days) as the first principle when
> creating new systems/upgrading legacy systems. Without it, privacy intrusion
> is inevitable along with quantum surveillance.
>
> Technically it is possible. Procurers needs to be aware of the need to
> demand it : audits, legal regulations etc are necessary but insufficient.
>
> Juliet Lodge (Prof Dr Dr)
> Jean Monnet European Centre of Excellence
> Institute of Communication Studies University of Leeds UK
> f7p research  ICT Ethics
> BEST network on biometrics
> fp6
> R4EGov
> Challenge
> eJustice
> Confidentiality note:
> The information in this electronic mail (e-mail) message may be
> confidential and for use only by the named recipient. The information may be
> protected by privilege, work product immunity or other applicable laws. If
> you are not the intended recipient, then the retention, dissemination,
> distribution or copying of this e-mail message is strictly prohibited. Any
> review, retransmission, dissemination or other use of, or taking of any
> action in reliance upon, this information by persons or entities other than
> the intended recipient is prohibited.  If you received this in error, please
> contact the sender and delete the material from any computer. Thank you.
> ________________________________________
> From: liberationtech-bounces at mailman.stanford.edu [
> liberationtech-bounces at mailman.stanford.edu] On Behalf Of
> P.A.Bernal at lse.ac.uk [P.A.Bernal at lse.ac.uk]
> Sent: 09 February 2011 12:48
> To: liberationtech at mailman.stanford.edu
> Subject: [liberationtech] FW: The security and ethics of mapping
>  inrepressive environments
>
> 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
> _______________________________________________
> 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
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20110209/7bf42a7b/attachment.html>