Subject: Catching up on various issues

From: John Morris <[email-masked]>
Date: Sat, 01 Jun 2002 09:04:31 -0400

Catching up on the list and looking ahead to the interim meeting next week, 
let me put in two additional cents on three of the issues that have come up:

1. Some have questioned the extent to which privacy can be expressed in 
code and the extent to which such expression is the mission of the working 
group.  Under the charter, the WG must "assess the the authorization, 
integrity and privacy requirements that must be met in order to transfer 
such information, or authorize the release or representation of such 
information through an agent."  As several members of the group have 
pointed out, this first requires a definition of privacy relevant to the 
context of location information. Jorge Cuellar, in his May 24 email, set 
out a working definition of privacy:

 >Privacy refers to the right of an entity, normally a person, acting in its
 >own behalf, to determine the degree to which it will interact with its
 >environment, including the degree to which the entity is willing to share
 >information about itself with others.

Controlling the "transfer," "release," or "representation" of Location 
Information involves more than allowing the Owner/Rule-Maker to specify the 
accuracy with which the Location Server will provide (F)LI to the Ultimate 
Location Recipient (ULR).  The Location Object must allow the Owner to 
specify who may receive the LI.

2. Although P3P provides a useful conceptual starting point for this 
requirement, as Richard Shockey suggests in his May 21 e-mail, it is not 
sufficient.  Critically, P3P does not set default values or a minimum 
baseline of privacy protection, something that many in the WG (including 
me) have suggested is needed.

Although this lack of default values can work in the Web context, it is 
very problematic here.  First, whereas Web users typically have the 
opportunity to evaluate a privacy policy prior to the release of personal 
information, location information will likely be released to some parties 
prior to any ability of the individual to assess their policies.  Second, 
Web site visitors can choose among similar websites, which sometimes 
compete on the basis of privacy policies.  LI users, however, often will 
not have a choice of provider.  There may be just one cell phone service 
provider in a given area, for example, or there may be barriers to 
switching providers, with the result being that many Owners would have no 
real choice as to whether to allow access and use of LI.  In this context 
default Location Object behavior that protects privacy is critical.

This becomes an even greater concern when we consider the diversity of 
activities and devices may ultimately involve LI collection.  People should 
be able to protect certain KINDS of information, and to prevent release to 
certain KINDS of recipients, and allow these decisions to vary in response 
to certain KINDS of context; Req. 22 is meant to require this kind of 
expressive power.

3. To be clear, the draft requirements document was not intended to suggest 
that existing transport protocols should be modified to accommodate 
concerns about privacy, authorization, security, etc.  Certainly what the 
WG produces can be carried with existing transport.

We have a lot to discuss in San Diego and on the list.  See some of you there.

John Morris