W3C home > Mailing lists > Public > public-geolocation@w3.org > October 2008

Re: wording for the privacy section

From: Alissa Cooper <acooper@cdt.org>
Date: Fri, 31 Oct 2008 17:57:07 -0400
Cc: public-geolocation <public-geolocation@w3.org>
Message-Id: <3A579329-B4DC-4334-B53C-BCD569889A01@cdt.org>
To: Ian Hickson <ian@hixie.ch>

Hi Ian,

On Oct 29, 2008, at 6:20 PM, Ian Hickson wrote:
> On Wed, 29 Oct 2008, Alissa Cooper wrote:
>>
>> In addition to the Position attribute in the Geolocation interface,  
>> we
>> could have a UsageRules attribute:
>>
>> 	readonly attribute UsageRules usageRules;
>>
>> where the UsageRules interface is defined as:
>>
>> 	interface UsageRules {
>>  		readonly attribute boolean retransmissionAllowed;
>>  		readonly attribute DOMTimeStamp retentionExpires;
>>  		readonly attribute DOMString rulesetReference;
>>  		readonly attribute DOMString noteWell;
>> 	};
>>
>> This data structure maps to the usage-rules element defined in [1],  
>> the
>> Geopriv location object format specification.
>
> Could you show what values you would expect to see these attributes
> return? For those attributes that return URLs, could you give  
> examples of
> what the text of those resources would look like in a typical case?
>
<snip>
>
> Could you show what the UI would look like that would deal with these
> values?
>
>

Let's tackle a UI example first, and then the values.

Inserting a Geopriv rule set does not automatically necessitate any  
additional UI, because the usage rules have defaults. This is a  
crucial point. An existing implementation could return a default  
UsageRules object to the client (retransmissionAllowed = false;  
retentionExpires = lastPosition + 24 hours; rulesetReference = null;  
noteWell = null) without any additional UI.

The next case is where there's a per-site UI. Despite some  
disagreement in an earlier thread about whether UI would be exposed on  
a per-site basis, let's assume for a moment that it is, so that every  
time a site requests location information via this API, the user gets  
prompted to consent. In this case, one possible UI would prompt the  
user with two questions:

	Ask this site not to share my location with others [ yes | no ]
	Ask this site to retain my location for: [ 1 hour | 24 hours |  
indefinitely ]

The more plausible case, in my opinion, would be a global preference  
in the UA, similar to existing preferences for things like cookies. A  
set of options could be added for location information. For example:

	Ask sites not to share my location with others [ yes | no ]
	Ask sites to retain my location for: [ 1 hour | 24 hours |  
indefinitely ]
	[Exceptions]

where Exceptions would provide a dialog where users could set per- 
domain preferences for the above two questions and/or specify  
rulesetReference URIs for particular domains. Thus, the UA could serve  
two functions. It can store user-specified URIs where rulesets already  
exist. But it can also facilitate the creation of rulesets (per-domain  
or more global) by allowing users to set their location preferences  
and creating rulesets based on these preferences.

So, to the values of the attributes:

retransmissionAllowed is either true or false (corresponding to the  
default, the user's choice in the UI, or the existing value if the UA  
receives a Geopriv object from the host).

retentionExpires is a timestamp containing the retention limit of  
lastPosition (corresponding to the default, the user's choice in the  
UI, or the existing value if the UA receives a Geopriv object from the  
host).

rulesetReference is a URI. What exists at this URI is an extended set  
of rules relating to the location being conveyed. These rules can be  
written using the XML framework described at [1] and [2]. The rules  
language is highly flexible and extensible, and provides for all kinds  
of rules limiting or granting transmission, limiting or granting  
retention for specified periods of time, specifying location  
fuzziness, and other constraints. Here's a very simple example of what  
might exist at a rulesetReference URI:

<?xml version="1.0" encoding="UTF-8"?>
   <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
       <rule id="f3g44r1">
	           <conditions>	
	               <identity>
	                   <many>
	                       <except domain="adserver1.com"/>
	                       <except domain="adserver2.com"/>
	                   </many>
	               </identity>
	           	   <validity>
	                   <from>2009-08-15T10:20:00.000-05:00</from>
	                   <until>2009-09-15T10:20:00.000-05:00</until>
	               </validity>
	            </conditions>
	       <actions/>
	       <transformations/>
	     </rule>
   </ruleset>

This ruleset says that the Position object with which it is associated  
can be conveyed to and stored by anyone (i.e., any domain) between  
August 15 and September 15 except for adserver1.com and adserver2.com.


> Could you show how a script would use these values?

Let's take the pizza place example. The pizza place site has an  
agreement with an ad network to show location-based ads on the pizza  
place site. The pizza place also stores the locations of visitors to  
the site in its database for demographic analysis. Some pseudocode of  
how the usageRules might interact with these two endeavors:

navigator.geolocation.getCurrentPosition(someFunction(position,  
usageRules))
if (usageRules.retransmissionAllowed == true )
	send (position, IP address) tuple to adserver
insert (position, IP address, usageRules.retentionExpires) tuple in  
location database

If the user allows retransmission of his location, the pizza place  
sends it to the ad server. The retention time of the user's location  
information gets stored in the pizza place's database so that  
(hopefully) it gets deleted when its time expires.

Cheers,
Alissa

[1] http://www.ietf.org/rfc/rfc4745.txt

[2] ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-geopriv-policy-17.txt
Received on Friday, 31 October 2008 21:57:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:40 GMT