- From: Richard Barnes <rbarnes@bbn.com>
- Date: Wed, 17 Dec 2008 19:00:01 -0500
- To: public-geolocation <public-geolocation@w3.org>
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