Translucent databases revisited

translucent databases For an upcoming article on the eternal riddle of identity and privacy, I revisted Peter Wayner's notion of translucent databases (1, 2, 3), which can hide even from themselves -- and from their authorized or unauthorized operators -- such personally-identifying data as is not strictly needed.

I asked Peter how large a class of applications he thought might be suitable for this treatment. As a thought experiment, he's investigating to what degree an e-commerce system like Amazon could work translucently. Some aspects of this are seemingly straightforward. By keying your purchase history to the hash of your name and a password known only to you, for example, Amazon could in theory deliver all the personalization you expect, and do all the aggregate analysis it needs to do, without tying your name to purchase records. Why do we personalize data more than is necessary? It's a fascinating question about which I hope to see broader disussion when Peter posts his analysis.

Still, Amazon obviously has to store your name somewhere, plus your credit card number and street address, in order to do the e-commerce dance, right? Well, actually, no, it does not need to store those data, it needs your permission to use them -- and a means to access them. This was, of course, the Hailstorm vision. Microsoft floated that trial balloon a couple of years ago, and it got shot down. It's clear now that Microsoft won't own the identity business, and that identity systems will federate. But we ought not forget that at the core of Hailstorm is an idea that is correct, necessary, and inevitable. Services don't need to store your data, they need to use it with your permission. Hailstorm, as originally conceived, was a translucent database -- and a darned good idea.

Former URL: