My dear friend John, whose generosity and interests drive this site, has said something in comment to this entry, which I just have to call him on:
“The more everything ties together the more we are open for invasion. But the Paris Hiltons of the world seem to embrace the great borgification, the assimilation into the overmind, in which notions such as autonomy and privacy are not so much quaint as incomprehensible.”
Whoa, there buddy! You’re going to have to explain why tying stuff together makes it more open to invasion. Ever try to invade a strawberry thicket? There’s good design and bad design (with respect to various desirable or undesirable effects), but I see no reason that a good interconnected design is any more pervious then a bunch of isolated stuff. In fact, in my admittedly limited understanding of military and tech. security history, the concepts of “defense in depth” and “divide and conquer” suggest to me that interconnected stuff (if done right) may be inherently safer.
Besides, I’m touchy-feely enough that I just plain like the idea of interconnectedness (done right) being not only safer, but freer and more open and enabling, not more oppressive. Croquet architect David Smith just attended the International Summit on Democracy, Terrorism and Security in Madrid. They have produced a document that begins to articulate how I happen to feel. It is called The Infrastructure of Democracy.
I had a conversation with someone at the University here about architecting Croquet – or a class of Croquet applications – so that the infrastructure can be centrally controlled. By the University, by a consortium of universities or what have you. “This is wrong,” I thought. If you design it so that the whole thing – the very infrastructure — can be controlled by you, then it will be controlled, but not by you. Either Croquet will be a success or it won’t, and if it is a success, then the Elephant in the Hallway, Microsoft, will come along and control their version. Or some government, or terrorists, or whatever bad guys haunt your anxiety closet.
I’ve recently learned from some folks in the tech security community that security is weakened when you rely on prohibiting that which you cannot prevent. Systems fail, so design your system to fail gracefully. Connectivity is abused, so design your systems to respond to it. Openness and interconnectivity are powerful tools for dealing with the attacks we cannot prevent.
My preoccupation with the hive mind and encroaching technology is no secret. Heck it’s the paranoia that makes me who I am.
But I have been meaning to write a little Wetmachine essay about the great "kotting into", and your post here is one more goose in that direction. Perhaps I’ll get around to it soon.
I do like your points about not trying to prevent what you cannot control, and about designing systems to fail gracefully.
My main problem is that I was born in the wrong century. I was meant to be a contemporary of Mark Twain. Dear Wife also suffers from a phase skew, but not so badly. She’s convinced that she was supposed to have been born in 1905: a flapper in the 20’s and a NYC sophisticate in the 30’s. That would have made her a contemporary of Marlene Dietrich, who gave us that wonderful motto as pertains to all things croquet/overmind/ubiquitous computing/etc:
"I vant to be alone."
I look forward to your post!
Funny, I always thought of Twain as a curmudgeon who was dubious that progress would be done right or be altogether a good thing, yet hopeful just the same that it would be. Maybe that’s just my techie’s projection rather than historical facts. Probably the truth is more complicated than either view.
I wrote the above rant quickly, and have since edited the control mantra in the last paragraph to more clearly reflect what I was taught. For the record, then, what I had first misquoted was, that "you’re better off not trying to prevent what you cannot control." In fact, I haven’t yet made up my mind how general the "don’t prohibit" mantra is. For example, I’m not prepared to say it should be a guiding principle for writing society’s laws.)
This particular security community (http://www.erights.org/) has another interesting design principle: the Principle of Least Authority. The idea is that instead of, for example, granting complete access to your computer to every installer you download off the internet, each process should get exactly all the power it needs to do its specific task, and no more. I saw two signup activities at my children’s schools that illustrated this as a general principle, not specific to security. The first signup had tables for each event, staffed by an administrator with a clipboard. You waited in line and gave your name to the administrator who entered it into a grid on the clipboard with a fixed number of lines. Changes were made by the administrators erasing lines. It took about an hour and my kids and I were all fried by the end. The second sign up party had the same tables, and a fixed number of coupons laying on each. The coupons specified the event and the time, and happened to also be color coded by time slot for our convenience. Pick up one red coupon, one blue, etc. No administrators. No one needed to know my name or my child’s names. It was unnecessary information. Principle of Least Authority. By the way, the tables had pictures of the activity, and so my emerging reader was empowered to execute the whole signup activity by herself in just a few moments. (http://wetmachine.com/i…) By contrast, in the first signup, my kids had that crushing feeling of just hanging out while the ‘dults did their thing. I get that same feeling when I need to have to have an IT administrator do something for me, or when I go to the bank, or try to sign up for cell phone or cable/Internet service.
Stearns, the signup story is a beautiful example of system design . I love it! And it has nothing to do with computers !