Re: Session-Id and privacy mechanisms

The following pertains only to session-ID issues that arise from a desire
for better usage tracking.  It does not relate to session-ID issues that
arise from the need to create stateful connections...

Would it not be useful to think about the privacy aspects of
client-generated session IDs as they resemble caller-IDs provided by some
telephone companies?  Caller-ID provides a very useful service in some
ways and offers a powerful invasion of privacy in another. 

Good potential solutions reside in looking at all of the needs of all of
the parties, then seeking answers that meet as many needs as possible,
while avoiding "solutions" that actively block the meeting of some needs.

With this analogy, the client is the caller, the server the recipient of
the the call.

With caller-ID, most of the benefits devolve on the recipients of calls,
but a few upon callers (e.g., an emergency call placed by someone not able
to identify himself). 

Some callers have a great desire to identify themselves (e.g., the
emergency situation above), some are indifferent, and some have a great
desire for privacy (some for legitimate reasons, some because they wish to
place threatening calls). 

Some recipients have a great desire to identify callers (providers of
services for fees, maintainers of secure sites, etc); some recipients are
interested in identifying callers (for marketing purposes, say), but are
willing to accept calls that cannot be identified; some do not care about
the identity of their callers.  (I cannot think of examples of recipients
of calls that would actively not want to know the identity of callers, but
some may exist.)

Once we accept that enough value resides in providing caller ID service,
systems need to be developed to meet the needs of all classes of callers
and recipients, in all classes of calls -- e.g., calls placed by those who
seek privacy vs those who don't care; calls directed to recipients who
seek caller identities vs those who don't care. 

A good solution cannot be based on the pronouncement that some classes of
callers or recipients (or combinations thereof) have needs that do not
deserve to be met ("why worry about the privacy issue -- people can
identify you when you walk in their store, who cares if they can identify
you when you call their store"). 

The solution: develop technical caller-ID systems and protocols that
enable both callers and recipients to behave in ways that meet their local
needs and assume that market and other social forces will sort out the
rest.  Technical solutions that are based on social judgements have
problems, the biggest of which is their lack of generality.

With caller ID, a simple solution is to develop protocols that (a) allow
callers to block the sending of calls with a caller-ID and (b) allow
recipients to block the receipt of calls without a caller-ID.  The caller
who does not want to identify himself blocks the sending of caller-ID, the
recipient who insists upon knowing the identity of all incoming calls
blocks the receipt of unidentified calls.  Done!  

Market forces will sort out the rest.  The privacy-seeking person who
greatly desires the services of a caller-requiring recipient will, if the
desire is sufficiently great, identify himself.  The identity-seeking
recipient who wishs a broader audience of callers will yield and begin
accepting unidentified calls.  Everybody else will be happy from the
beginning.

As for figuring out how to explain the config parameters to naive users,
use the caller-ID metaphor and give client-side users the ability to turn
caller-ID on or off, as a preferences setting (default should probably be
off to protect privacy), and also provide the ability to over-ride the
preferences setting on a "call by call" basis. 

====================

Note: soap-box oration follows, stop reading here if not interested...

Computer systems that seek large market share should not attempt to behave
in a paternalistic manner, deciding for users what their legitimate needs
are and meeting those needs (and only those needs).  

Systems that are paternalistic ("what we do, we do incredibly well; what
we don't do, you don't need to do and indeed shouldn't do") can obtain
intense, almost religious support from those who agree with the particular
paternalistic view, but they are not likely to gain large market share and
may indeed lose market share over time to systems that allow the user to
do what he wants without requiring him to do it only that way.  

One might argue that the Macintosh is a prime example of a paternalistic
system that gained intense support in some circles, but now is seeing its
already small market share drop to record lows (8.3 % of desktop sales
last year), but that's another story...

Received on Saturday, 22 July 1995 07:57:52 UTC