HailStorm was before its time

Next time you're filling out a registration form on the Web, try this experiment. Enter only your last name and ZIP code (let's assume you're a U.S. resident), then click Submit. The form's handler will complain about a bunch of missing fields, including address, city, state, country, and phone number. Now visit Google and type a query based on this construction: phonebook: LastName,ZipCode.

If you're Jon Udell in Keene, N.H., the missing fields will pop right up. If you're Robert Smith in Brooklyn, N.Y., you might (depending on your ZIP code) have to select from a couple of choices. But either way, a form that did a lookup based on partial information could save you some effort.

Why don't Web forms work this way? I can think of lots of reasons. Google's Web API doesn't support PhoneBook queries. Even if it did, the terms of service would require written consent for commercial use. Spidering the main Google Web site would be easy but, again, the terms of service prohibit that. Of course the information won't be available if the person who is filling out the form told Google to remove his or her information from the PhoneBook. And anyway, thanks to the modern browser's memory of form fields, repetitive data entry isn't the hassle it once was.

I suspect there's an even deeper reason, though. Many folks wouldn't want to be reminded how easy it is to convert sparse input into a detailed profile that includes a phone number, a street address, a satellite photo, and driving directions. Re-entering the basic facts each time perpetuates an illusion of privacy. Yet the reality, for many of us, is that these facts are public.

Since I haven't told Google (or any other directories) to delete my records, I've implicitly given permission for Web applications to use that data. Let me now make that permission explicit. I'd be happy if a Web form made intelligent use of public information about me.

I'd be even happier if I could control the source of that data. Public information is a poorly defined concept, after all. There are online directories that still remember an address I vacated five years ago. I'd like to maintain the facts about me that I deem public. When applications need those facts, I'd like to refer them to a service that dispenses them.

We've now arrived at the brink of a precipice. On the rocks below lies the shattered body of Microsoft's HailStorm. What sent it over the edge was the notion that it would manage not only public facts, but also private ones: credit card numbers, travel itineraries, musical preferences. Sooner or later, we will wind up delegating the management of these facts to services acting on our behalf. HailStorm was the right idea. But the dawn of this century was the wrong time and Microsoft was the wrong company.

Perhaps we can make some progress without taking the scary leap of faith. Suppose we create an ecosystem in which users maintain public profiles, Web services dispense them, and applications talk to those services? Your profile would contain only the facts you want to publicly assert about yourself. No secrets, no trust. We don't know how to solve the trust problem yet. While we're sorting that out, maybe we ought to bootstrap the formats, protocols, and mechanisms that will have to support whatever trust solutions emerge.