Revised UA privacy considerations

Hi all,

Below is some proposed text for the UA privacy considerations section 
that Andrei added.  It's a lot simpler and more readable than what 
Alissa and I had proposed before.  The baseline requirement is that (1) 
users MUST be allowed to set permissions on a per-recipient basis, and 
(2) the default MUST be to deny.  A UA can optionally allow users to 
specify how long to remember their permission and how accurate the 
location can be.

Feedback would be appreciated.  For instance, I'm a little fuzzy on 
whether the notions like "page", "site", and "visit" are well-defined in 
this context, so if someone could comment on whether the usage below is 
valid (and suggest improvements!), it would be really helpful.

Cheers,
--Richard


-----BEGIN Quoted Text-----
<p>
By default, a conforming UA MUST deny access to location to all 
requesters, until a user grants permission for the UA to provide access 
to location.  UAs MUST allow users to disable this API entirely if they 
do not want to share their location at all.  In order to allow access to 
location when this API is used, a UA MUST allow users to specify 
permissions that grant access to location.
</p>

<p>
A full permission has three parts: An identifier for which page(s) or 
site(s) are given access, a validity interval, and a description of 
location the recipient should be given.
<ul>
<li><em>Identifier</em>: A permission may grant access to either a site 
or a specific page.  A sites is identified by a domain name and matched 
according to the "same domain" criterion [XMLHTTP].  A page is 
identified by a URI and matched according to the URI comparison defined 
in RFC 3986 [RFC3986].</li>
<li><em>Validity</em>: A permission can specify how long it is valid in 
three ways.  First and second, it may specify that it is only valid for 
a single visit to a page/site, or for a single "session" with that 
recipient (the UA must determine the length of a session).  Third, a 
permission may also specify beginning and ending times (e.g., a "sticky" 
permission could have an end very far in the future).  Obviously, if a 
permission is deleted, it is invalid.</li>
<li><em>Granularity</em>: A permission can specify what granularity of 
location is provided to sites that are allowed access by the above 
attributes.  Permissions may set a mininum size for the 
<code>accuracy</code> attribute in returned location.  If the 
<code>Position</code> is extended in the future, then permissions may 
make similar specifications for other portions of the object.
</ul>
<p>

<p>A compliant UA MUST allow users to specify the identifier for a 
permission, but not necessarily the other attributes.  If the validity 
attribute cannot be set by the user, then it MUST specify validity for a 
single visit (i.e., the user must be prompted on every visit).  If the 
granularity attribute cannot be set, then it MUST specify access to the 
full position provided by the location provider.
</p>

<p>
A UA MUST authorize requests for location by checking against available 
permissions, and SHOULD allow the user to specify new permissions (allow 
new access) at the time of a request.  Specifically, when a UA receives 
location from a location provider, it SHOULD execute the following 
authorization procedure for each recipient (i.e., each call to 
<code>getCurrentPosition</code> or <code>watchPosition</code>):
<ol>
<li><em>Look for permission</em>: The UA searches available permissions 
for ones that match the recipient's identity, either as a site or as a 
page.  If no permissions are matched, then the UA MAY prompt for new 
permissions.  If permissions are matched (or added), then access is 
granted; otherwise, access is denied and this process is aborted.</li>
<li><em>Validate granularity</em>: If permissions are found, the most 
permissive granularity is selected (e.g., with the smallest minimum 
uncertainty).  The UA validates that the location has the desired 
granularity.  If so, location is provided to the recipient by calling 
the corresponding <code>successCallback</code>.  If not, then the UA 
SHOULD deny location and invoke the corresponding 
<code>errorCallback</code>.  Alternatively, a UA MAY modify the location 
to meet the granularity requirement and return it through the proper 
<code>successCallback</code></li>
</ol>
</p>

<p>
Permissions are positive grants of permission.  They only grant access 
to location, and cannot be used to deny access.  A UA MAY remember a 
user's preference to deny location to specific sites at specific times, 
e.g., by recording a "denial" object.  Such a denial could be expressed 
in a structure similar to the permissions above, with an identifier and 
a validity interval.  A denial structure would lack a description of 
location, however, since no location is to be provided.
</p>

<p>
Permissions are not static things.  They are expected to change 
dynamically with as the user encounters new pages or changes the level 
of trust he give to individual recipients.  For example, when a page 
requests location, the UA might present a dialogue asking the user to 
allow or deny access, and if the user allows access, asking the user how 
long the access should last (e.g., this visit, this session, or 
forever), and what granularity should be provided.  If the user grants 
access, the UA could store a permission for this page and refer to that 
permission before granting access or prompting the user when that page 
requests location in the future.  If the user denies access, the UA 
could note this and not prompt the user in the future.
</p>
-----END Quoted Text-----

Received on Thursday, 18 December 2008 00:00:44 UTC