McNealy -- Get over it, Part Two (was Re: BNA's Internet Law News (ILN) - 05/30/2001)

Win Treese treese at acm.org
Mon Jun 4 12:45:01 EDT 2001


> The point is not that there might be another way, the point is
> that understanding the bargain to be as he describes it, Scott
> finds it an acceptable one.  He is far from alone, I'd wager.

But is the tradeoff being made explicitly or implicitly in the system
design? Consider three systems:

1. One explicitly designed to track Scott at all times and then help
if there's an accident, where part of the price that Scott pays is the
loss of privacy. The service provider then may benefit in some way for
the extra information.

2. One designed to help if there's an accident, that incidentally
happens to implemented to track Scott all the time. Later, perhaps,
someone figures out that there's a way to use that extra data, but it
wasn't part of the requirements. Such use, of course, might include
proving that Scott's car wasn't at the scene of a crime, or sending
him the now-legendary wireless coupon for a latte at the nearest
Starbucks. 

3. One designed to help if there's an accident, designed in such a way
that it reveals only the information needed to do so. Beyond the
question of requirements for the system, someone might reject such a
design as too costly for some reason, putting us back in category 2.

In other words, the categories are:
1) Explicitly designed to collect "private" information
2) Collect "private" information as a side effect of the design
3) Explicitly designed not to collect "private" information

I suspect that most designers of such systems don't think much about
how to build things in category 3, especially about the subtle ways
that information shows up and can be correlated. 

What worries me is that the tradeoffs Scott finds acceptable are made
mostly behind closed doors, and the buyer doesn't know what they were,
or even what information is gathered and how it is used. 

Win Treese
treese at acm.org






---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com




More information about the cryptography mailing list