Catching up on various issues

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
Received on Sat Jun 1 09:04:44 2002