Jon Udell

The WSJ reported recently that the FBI, looking for fresh leads in the 1982 case of Tylenol poisonings, suspects Ted “Unabomber” Kaczynski and is trying to get hold of a sample of his DNA. Coincidentally I was just thinking about that case thanks to Bruce Schneier. In his recent TED talk he mentions that the Tylenol incident led to tamper-proof caps — a perfect example of what Schneier likes to call “security theater”:

As a homework assignment, think of 10 ways to get around it. I’ll give you one, a syringe.

So far this is typical Schneier. It’s a great point, but one I’ve heard him make many times before. In the next sentence, though, he breaks new ground:

But it made people feel better. It made their feeling of security more match the reality.

Bruce Schneier used to mock the theatrical dimension of security. Now it seems his thinking has evolved — and in a really interesting way. He’s alway viewed security in a relativistic way, and as a game of economic tradeoffs. Here he twists the lens to bring something else into focus: the relationship between how secure we feel and how secure we are.

We know that modern hominids evaluate risk poorly:

One way to think of it is that we’re highly optimized for risk decisions that are endemic to living in small family groups in the East African highlands in 100,000 B.C. — 2010 New York, not so much.

There are two ways our feelings about our security can disconnect from reality. We can have a false sense of security, as when we underestimate the risk of automobile travel. Or we can have a false sense of insecurity, as when we overestimate the risk of air travel.

What matters most, Schneier suggests, is that we align feelings and reality. And if security theater helps us do that, then it’s a perfectly good thing. The Tylenol episode represents the kind of risk that the media thrive on and magnify. People felt unsafe even though they were astronomically more likely to die in other ways. Tamper-proof caps may be a purely theatrical response, but that may still be useful.

Technologists too rarely display this kind of nuanced thinking; it’s refreshing to see it.

Many people assume that web thinking comes naturally to anyone born after 1990. Yes and no. Yes, the experience of 21st-century digital natives is qualitatively unlike what all prior generations shared, as far back as the dawn of genus homo over a million years ago. But no, the virtual dimension hasn’t fundamentally changed us — at least not yet.

Consider the physics of things in the real world. As hominids we have a million years of experience with the properties and behavior of physical things. And as individuals we have lifetimes of such experience. Based on those experiences, here are some things we know:

• If I give you a thing then it’s yours until you give it back. We can’t both use it.

• If I want to make a collection of things, I get a bucket and put things into it. A thing is either in the bucket or it isn’t. The same thing can’t be in two buckets at the same time.

• If I invite you to work on a project using my collection of things, you have to visit my house.

In the virtual dimension none of these laws apply.

• I can give you a link to a thing, and we can both use it. If either of us improves it, we both share the improvement.

• If I want to make a collection of things, I can invent a tag that identifies things in a collection. We can invent many tags for many collections. A thing can be in more than one collection.

• If I invite you to work on a project using my collection of things, you can join me in a virtual place.

As we begin to colonize the virtual dimension, we begin to learn about the physics of virtual things. But we still haven’t fully internalized the laws and properties that govern them. All of us, digital natives included, still tend to treat virtual things as if they were physical things.

Making and sharing collections of things is a common scenario that illustrates the tension between these two different sets of laws. When the things are physical objects — say, coins — there’s no choice about how to collect them.

Scenario 1: Somebody passes around a bucket, people toss coins into the bucket, whoever holds the bucket has the coins.

But when the things are virtual objects — say, chunks of information, existing as web resources, identified by URLs — there is a choice. Somebody can still pass around a virtual bucket, people can still toss virtual coins into it, and whoever holds the virtual bucket will have access to the collection of coins. That’s exactly what happens when we use an email conversation as the virtual bucket. Or:

Scenario 2: We can invent a name for a virtual bucket, and toss web resources into it by tagging them with that name. Now anyone who searches for the tag will have access to the collection of resources.

This new scenario raises important questions. How do we choose a name for the collection? How do we choose a service that binds the name to things in the collection? How do we restrict access to the collection? On what terms are these name-binding and access-control services provided to us?

I can’t answer all these questions at once, so let’s start with the most fundamental one: How can we name things?

In A tale of two dams I made up a tag, WestStDamKeene, that could be used by anyone to co-ordinate web resources related to an ongoing conversation in my city about the fate of the Ashuelot River dam on West Street. The tag is 14 characters long. With 14 characters you can make quite a lot of names. If each character can be a letter or a digit, then there are 36 choices for each character — 26 letters plus 10 digits. There are 36¹⁴ strings of 14 such characters. When faced with big numbers like that I turn to my favorite scientific calculator, WolframAlpha. It evaluates the number like so:

In a recent talk I failed (spectacularly) to convey the point I’m about to make, so I’ll try it again and more carefully here. We can make about as many 14-character tags as there are grains of sand on Earth. True, a lot of those won’t be nice mnemonic names like WestStDamKeene, instead they’ll look like good strong unguessable passwords. But there are still unimaginably many mnemonic names to be found in this vast namespace. Each of those can serve as a virtual bucket that we can use to make and share collections of arbitrarily many web resources.

The implications take a while to sink in. Grains of sand are inert physical objects. They just lie around; we can’t do much with them. But names can be activated. I can create a 14-character name today — actually I just did: WestStDamKeene — that won’t be found if you search for it today on Google or Bing. But soon you will be able to find at least one hit for the term. At first the essay I’m now typing will be the only hit from among the 30 billion indexed by Google and 11 billion indexed by Bing. But if others use the same term in documents they post to the web, then those documents will join this one to form a WestStDamKeene cluster.

This isn’t even tagging in the conventional sense. Set aside, for now, the clusters that can form around that tag on Delicious, or on WordPress, or on Flickr, or on Twitter, or even at the intersection of all those tag-oriented services. Consider only what can happen when you make up a never-before-seen term, utter it in a document placed on the web, and invite others to utter it in documents that they place on the web. When we enact this scenario we are, in effect, creating an ad hoc web service that we can use to make and share collections of things related to (in this case) a particular dam project in a particular town. Of course tag-oriented services enhance our ability to make and share such collections. But even without them we can still do it. In the realm of virtual things, names are as plentiful as grains of sand. But they aren’t inert. We can wake them up and use them to co-ordinate our activities.

The elmcity project thinks like the web, and invites users to do the same. Direct users of the elmcity service (hereafter just elmcity) are curators who run calendar syndication hubs. Indirect users are people who contribute calendar feeds that flow through the hubs. Everyone involved in this dance practices key principles of web thinking. Here are some ways:

In these scenarios the elmcity service partners with a number of other services, most notably Delicious. During last December’s Delicious-is-going-away scare I compiled a list of essays I’ve written since 2004 about how and why Delicious is far more useful than the tagline “social bookmarking” might suggest. Here’s the gist: Delicious, more than any other online service I know, encourages and rewards the practice of web thinking. That makes it a natural partner of elmcity, a service that invites communities to think like the web.

There are, of course, other ways to manage hub settings and feed registries. Various social bookmarking services can do what Delicious does. More conventionally, the elmcity service could manage this data directly. I’ve always been prepared to swap out Delicious for something else, and when it looked like Delicious might go away I reviewed my options.

Then came news that Delicious had been acquired by YouTube’s founders and would continue as part of a new company called AVOS. The transition promises to be seamless. In order to continue using their existing accounts and data after July 2011, Delicious users need only opt in to the AVOS terms of service.

For typical users it’s all straightforward, though you’ll want to note that AVOS declines responsibility for backing up your contributed data. I’m glad to see that in writing. Too many people assume, wrongly, that the data they send to free cloud services, in order to socialize with other people and other people’s data, will be backed up. It’s the cloud, right? The cloud can back up your stuff, right? Yes it can, but don’t expect that to happen unless you’re paying for it.

The elmcity service isn’t a typical user of Delicious, though. It accesses Delicious programmatically, scanning curators’ bookmarks several times a day in order to check for updates to their hub settings and feed registries. That may not square with this item from the list of Things Not To Do in the AVOS terms of service:

Attempt to access or search the Service or Service Content or download Service Content from the Service through the use of any engine, software, tool, agent, device or mechanism (including spiders, robots, crawlers, data mining tools or the like) other than the software and/or search agents provided by AVOS or other generally available third party web browsers.

That’s quite a change from the comparable paragraph in the existing terms of service:

Delicious provides access to portions of Delicious via RSS feeds and an API; for the purposes of these Delicious Terms, such access constitutes use of Delicious. Delicious asks that you use these features respectfully, as outlined in the documentation.

Elmcity actually makes very little use of the Delicious API. But it relies heavily on the fact that for every HTML page that Delicious presents, there is a corresponding RSS feed. For example, curators add iCalendar feeds to their hub registries by bookmarking the URLs of those feeds, and tagging them in a certain way. As curator of the hub for Keene, NH, I review my hub’s registry using this Delicious query:

http://delicious.com/elmcity/trusted+ics+feed

When the elmcity service checks for updates to my registry, it uses the corresponding RSS feed:

http://feeds.delicious.com/v2/elmcity/trusted+ics+feed

That same feed serves another purpose. The elmcity support forum and project collaboration space is on FriendFeed. One of FriendFeed’s endearing features is ad-hoc RSS aggregation for groups. The elmcity group on FriendFeed compiles project status from a variety of RSS feeds, including Delicious feeds of the form shown above. What that means is that when any curator discovers a new iCalendar feed and adds it to his or her hub, everyone in the FriendFeed space is notified. It’s a wonderful example of how pub/sub networks can enable ambient awareness.

I hope that AVOS wants to celebrate, not forbid, this kind of emergent capability. But it does require accessing the service with tools and services other than “generally available third party web browsers.” I have always done this kind of access respectfully, and would like to continue on that basis. But if that won’t be acceptable I’ll make other arrangements. Either way I want to thank Delicious for many years of stalwart service and creative stimulation, and to thank AVOS for carrying on. I’m sending the Delicious/AVOS support team a link to this post, and I’ll use comments here to report what I find out.

I love small airports. When we moved to Keene, NH, over 20 years ago, I could roll out of bed, drive three minutes to our town’s airfield, hop onto a flight to LaGuardia, arrive in midtown Manhattan for a day of meetings, and be home for a late dinner. It was a good thing that didn’t last. The federal subsidy that kept those flights going ran dry, and Keene’s commercial air service ended long ago.

Years later I read James Fallows’ Free Flight and fell in love with its vision of an alternative air travel system that thought like the web: a decentralized and fluid network of interoperable resources.

Still later an old acquaintance, Ed Iacobucci, made a valiant effort to bring that vision to life. Our 2007 conversation about DayJet, the on-demand regional jet travel service Ed had then just launched, inspired me to hope that I might again fly to and from the Keene airport. Our hopes were dashed by the 2008 economic collapse, and now that vision is on hold. But last night I had a taste of what air travel once was and might someday be again.

I’m in Toronto for a couple of days. On my last two visits, not knowing another way, I used Toronto’s international airport, Pearson. It’s a typically unfriendly major hub, made even less friendly by its atypical lack of rail service into the city center. But on my last trip, during a morning lakeside run, I saw small planes landing at the city airport on Toronto Island within a stone’s throw of downtown. I wondered what it would be like to arrive on one of those flights.

Well, now I know. It’s delightful! I flew Porter Airlines from Boston Logan direct to Toronto Island Airport. It was a trip from a bygone era. The plane was a turboprop. The complimentary wine was served in a real glass. The customs queue was quick. The ferry crossing to downtown, over a hundred yards of water, was seamless. Then I simply walked, less than a mile, to my downtown hotel. True, it cost a hundred bucks more than flying into Pearson. But I saved almost that much money, plus a chunk of time, by not cabbing from Pearson. And I arrived refreshed and happy. When does that ever happen?

Porter Airlines isn’t the kind of service that James Fallows’ book imagined and Ed Iacobucci’s company created. But the retro 1950s-era experience that Porter offers may help to remind us that small airports are everywhere, waiting to offer pleasure and convenenience once again — if we can find ways to reactivate them.

I recently asked a web server for something and it responded like a teenager:

403 Forbidden: The server understood the request, but is refusing to fulfill it.

I thought the description of this status code was a joke, but no, it’s right there in the HTTP specification. Here are some others that you won’t find there:

200 OK: Are you happy now?

202 Accepted: I’ll do it tomorrow.

206 Partial Content: I’ll do the rest of it tomorrow.

301 Moved Permanently: It’s not my job.

305 Use Proxy: I can’t remember, ask mom.

401 Unauthorized: You’re not the boss of me.

404 Not Found: Why does everybody always ask me for that?

410 Gone: Zzzzzzzzzzzzzz.

417 Expectation Failed: I thought you were going to put gas in the car.

500 Internal Server Error: I’m not allowed to make a mistake?