[liberationtech] FW: The security and ethics
John R Sundman
postmaster at wetmachine.com
Wed Feb 9 11:06:38 PST 2011
I've written about 30 hardware & software manuals. I was manager of
publications at Sun Microsystems for 8 years. I was the sole
technical writer on the OpenLaszlo (javascript/XML/"rich internet
application" language) project & wrote virtually all the programming
documentation for it. I wrote a TCP/UDP/IP programming manual in
1985. I sell my novels at DEFCON. etc, etc.
I can't keep up with the discussion of privacy & security. It's too
confusing and everything changes too fast.
I'm not the smartest person on this list, but I daresay if somebody
with my kind of background gets lost in this discussion, lots of
people with less technical experience must be at least as lost.
jrs
On Feb 9, 2011, at 1:51 PM, Jim Youll wrote:
> Minor clarification:
>
> I ** do not ** believe normal people who want to use electronic
> resources to communicate unpopular, potentially self-endangering,
> or merely private messages, should have to RTFM and become students
> of "personal technological security" any more than I would expect
> my artist friends to become mechanics before they may operate motor
> scooters.
>
> I ** do ** believe that hopeful thoughts and unprovably-confident
> descriptions of complex systems are NOT a substitute for a proper
> explanation of what can go wrong or what "must" be understood to
> use a technology "safely". Any such explanations must consider not
> only the moment but possibly the future, with information used not
> only alone but in combination with other information from other
> sources. You don't leak a key but your correspondent does, because
> he made a mistake. Are you both going to prison tomorrow?
>
> I see people speaking and writing /in the role of experts/ but
> expressing hopeful thoughts, rather than candidly expert opinions
> and cold facts. I do speak out against the idea of hopeful thoughts
> trumping cold fact. Techno-security talk is, and should be, fussy
> like that. Experts should say what they know, not what the 'think'.
>
> ====
>
> In the span of the past year the conversation has turned in a very
> useful, unprecedented way from "stop being so negative all the
> time" to "OMG that thing really COULD get somebody killed". This
> is a good start but now it exposes the gap in information that's
> been there all along. Didn't matter until now ... now that
> opponents of free communication and free thought have better
> technology than was predicted by the techno-hopeful - and they're
> using it without shame and without always hiding it.
>
> To an earlier point on this list about crypto / tech / security
> experts speaking in academic tones: don't shout those guys down.
> It's not their job to sugar coat things. Mathematicians and
> engineers - the good ones, anyway - speak in absolutes because
> their world is all about absolutes. In technology, a claim is
> either right, or it is wrong. An implementation of a protocol or
> algorithm is either correct, or it is not. Their fussing and
> complaining have no doubt already saved lives. Let them do what
> they do and be glad they bother.
>
> People are working on this problem of assessing what's available in
> the "stack" of { code, hardware, connectivity, third party
> services } and trying to sort out what combinations, if any, can be
> used "safely,"; what "safely" might mean; how to /describe/ what
> "safe" means in a way that can be used on the ground by normal
> people to understand their own situations. Apparently I'm going to
> be one of those people shortly. It's exciting and scary and maybe
> impossible to do as correctly as is needed. These days I would not
> want to be a software creator making a grand claim about the "code -
> > safety" function of my own creations. One cannot make these
> claims with confidence absent consideration of the always-unique
> (and now always-changing) environments in which that code is set
> into motion.
>
> - jim
>
> On Feb 9, 2011, at 10:15 AM, David Rizk wrote:
>
>>> Additionally, just as literary illiteracy and innumeracy are serious
>>> education problems, so is technological illiteracy. So while I
>>> agree we
>>> should be accessible, I reject the notion that the ideal is to not
>>> understand the way that the world works. We reject it for other
>>> important topics and we should reject it here too. We should embrace
>>> understanding for this very important topic; most people actually
>>> get
>>> the big picture and most of the little details when they stop
>>> discouraging themselves.
>>
>> Paul -- agreed. I think the points you've made are often lost on
>> this list.
>>
>> @Jacob, Jim: I understand that your points are directed mostly at
>> users who place themselves in harm's way, but I believe they lose
>> validity as universal tenets. Most people express their curiosity
>> and find happiness by learning about, and doing things, other than
>> implementing advanced privacy and security protocols. Expecting
>> users to want to learn more about our particular field misses the
>> greater point.
>>
>> Consider the alternative: ideally, users should need to know less,
>> rather than more, about the way networks and security protocols
>> work. Ideally, users should be able to spend cycles on the things
>> they care about -- pursuing happiness, fomenting revolutions --
>> without worrying about technical details. You may think hacking is
>> happiness, but plainly, most do not. If network and software
>> engineers (and governments and lawyers) were really successful at
>> their jobs, ordinary users wouldn't be threatened by any of this.
>> We strive to realize this vision in the law, and I would submit
>> that the same should be true of code. For example, Yale's Robert
>> Ellickson points out that the law is irrelevant for most people
>> most of the time -- and this is regarded as a great thing!
>>
>> Relatedly, I would also reject your analogy to basic literacy. Of
>> course, *some* basic level of computer literacy is going to be
>> essential for generations to come. But implementing advancing
>> privacy and security protocols is not really analogous to the
>> basic ability to read. To say that you can write, is not to say
>> that you can write a competent and persuasive brief to a judge.
>> You (wisely) hire a lawyer. Are you contending that, ideally, you
>> would mount your own defense? Or would you prefer to get
>> professional help?
>>
>> On the margins, I think we can agree, expertise is always going to
>> be necessary. And just as lawyers help their clients comply with
>> the law, and fend off attempts at enforcement, technologists
>> should strive to make life as uncomplicated as possible for users
>> -- while upholding their expectations and social norms (e.g.,
>> protecting their privacy, etc.).
>>
>> best, David
>>
>> ----------------------------
>> David Wade Rizk
>> Stanford Law School
>> drizk at stanford.edu
>>
>> On Feb 9, 2011, at 9:26 AM, <P.A.Bernal at lse.ac.uk> wrote:
>>
>>> Jacob, I'm certainly not advocating that we don't aim for
>>> understanding the world 'as it is' - but sometimes you need to
>>> teach someone to drive rather than how to design and build their
>>> own car, let alone the physics behind the internal combustion
>>> engine. There's a balance to be found - and as you say, creating
>>> a space in which we can find that balance is the key.
>>>
>>> What I was really looking for was a solution for the situation as
>>> it often is on the ground, as described by a few posters on here,
>>> where people have little time and lots of demands upon that
>>> little time, and who would like to find good solutions to their
>>> problems but who don't have the expertise to find their way
>>> through the technical language and literature.
>>>
>>> Paul Bernal
>>>
>>>
>>> -----Original Message-----
>>> From: liberationtech-bounces at lists.stanford.edu on behalf of
>>> Jacob Appelbaum
>>> Sent: Wed 2/9/2011 4:23 PM
>>> To: liberationtech at lists.stanford.edu
>>> Subject: Re: [liberationtech] FW: The security and ethics
>>>
>>> On 02/09/2011 06: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.
>>>>
>>>
>>> I agree. Surveillance by design is the normal behavior - it's both
>>> easier and well tested as far as most implementors are concerned.
>>>
>>> I think privacy by design is a great buzz-phrase. Ultimately for a
>>> discussion that critiques either advice or tools, it's probably not
>>> possible to just toss around buzz-words or buzz-phrases
>>>
>>>> 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.
>>>
>>> I find this interesting on a few levels.
>>>
>>> If we asked this of people about basic literacy or mathematics,
>>> we'd be
>>> pretty embarrassed. Rather than asking people to read to us or
>>> for us,
>>> we learn to read. Rather than asking someone to balance our
>>> checkbook,
>>> we learn to do it ourselves. This is a sub-goal of most educational
>>> programs. Obviously the main goal is an understanding of actual
>>> mathematics and literary challenges; learning about these topics
>>> is not
>>> just about functionally balancing a checkbook.
>>>
>>> To that end, computers and networks are an important part of our
>>> lives.
>>> Indeed, I think this is such a difficult topic precisely because
>>> a lack
>>> of knowledge or a lack of technical knowledge may be physically
>>> dangerous to people in the field. I don't want to exclude people
>>> from
>>> the discussion, rather I think we should seek to normalize the
>>> knowledge
>>> and embrace it when possible.
>>>
>>> To that end, I think that while we should try to make the language
>>> accessible but we must not forget that the details do really matter.
>>>
>>> Additionally, just as literary illiteracy and innumeracy are serious
>>> education problems, so is technological illiteracy. So while I
>>> agree we
>>> should be accessible, I reject the notion that the ideal is to not
>>> understand the way that the world works. We reject it for other
>>> important topics and we should reject it here too. We should embrace
>>> understanding for this very important topic; most people actually
>>> get
>>> the big picture and most of the little details when they stop
>>> discouraging themselves.
>>>
>>> If that means that people are going to give up on a discussion, I
>>> suppose that we should simply hope they're not calling the shots for
>>> other people who are less hopeless. There is little to do for
>>> people who
>>> simply and silently give up.
>>>
>>> However, as a practical manner - I would prefer to encourage
>>> people to
>>> help create a safe space. As my friend Ingy would say: "Hands need
>>> holding; if you only live in the future, it's a future nobody
>>> will ever
>>> see" and I tend to agree. There absolutely needs to be a desire
>>> on both
>>> sides to make this happen. It would be great to know when to
>>> define the
>>> technical language and when to break down the barriers; creating
>>> a safe
>>> space is key to greater understanding all around.
>>>
>>> All the best,
>>> Jacob
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
Blog: http://www.wetmachine.com/
Books: The Pains: http://the-pains.wetmachine.com
Acts of the Apostles: http://acts-of-the-
apostles.wetmachine.com
Cheap Complex Devices: http://cheap-complex-
devices.wetmachine.com
Facebook: http://www.facebook.com/jsundman
Twitter: http://twitter.com/jsundmanus
LinkedIn: http://www.linkedin.com/in/johnsundman
Salon: http://dir.salon.com/story/special/10th/2005/11/12/
best_of_salon_2003/index.html
More information about the liberationtech
mailing list