- From: Alissa Cooper <acooper@cdt.org>
- Date: Fri, 31 Oct 2008 17:57:07 -0400
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-geolocation <public-geolocation@w3.org>
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 UTC