Re: UWA WG feedback on geolocation API

Dear Dave,

Thank you for your comments. We appreciate your spending time on 
reviewing the specification.
Please find our detailed responses to your comments below.

Please acknowledge receipt of this email to public-geolocation@w3.org by 
November 12 2009.
In your acknowledgment please let us know whether or not you are 
satisfied with the working group's response to your comment.

On behalf of the W3C Geolocation Working Group,
Lars Erik Bolstad, Angel Machin

Dave Raggett wrote:
> The UWA WG has asked me (as the chair) to forward you these comments 
> on the geolocation API [1]:
>
> 1. Substantive Issues
>
> 1.1
>
> While we agree with the privacy considerations and the laudable goals 
> suggested in the text, the presence of privacy requirements in the API 
> document in their current form may be problematic, especially as the 
> text is demanding behaviour beyond that of the API. For example, in 
> the normative 4.2 sub-section it states:
>
> "Recipients must dispose of location information once that task is 
> completed, unless expressly permitted to retain it by the user."
>
> This is an operational issue. Adhering or ignoring this demand will in 
> no way affect the API itself. The requirement is therefore beyond the 
> API and has moved into business conduct and (unfortunately) legal 
> jurisdiction. In some countries it is a requirement for mobile records 
> to be kept for years, so that if necessary for the discovery of 
> evidence of criminal activity or intent, the data can be forensically 
> examined. We can see that jurisdictions may argue that this includes 
> location data. The matter thus becomes an issue of national security. 
> This is a very difficult space to deal with, and it may be better that 
> the API specification not be encumbered by it. It would be sufficient 
> to mention that privacy is desirable, and perhaps to list some of the 
> issues surrounding it, but it is probably best not to get into 
> demanding that privacy be implemented in specific ways.

The consensus in the working group is that the privacy requirements 
should be normative.
We acknowledge the fact that the ability of web sites to conform with 
the specification with respect to the privacy considerations may be 
limited by legal requirements that take precedence.


>
> 2. General Issues
>
> 2.1
>
> There is no way to inspect if the device has a cached location other 
> than to call getCurrentPosition with a maximum cache threshold and 
> then trap the timeout error. You might want this because getting the 
> actual location could involve a delay or additional power or cost, so 
> you could warn in advance that using the location feature might incur 
> an expense.
>
> Overloading the mutual behaviour of the successCallback, errorCallback 
> and doFallback functions to achieve this ability to inspect the cache 
> status without invoking getCurrentPosition is not a wonderful way to 
> specify the operation. It seems one can do everything needed (and with 
> zero timeout there is no delay) but it may not be the best way to 
> structure it - maybe one needs an "isThereACachedValue(maxage)" function.
>
> Aside: A question was raised within UWA as to whether presenting this 
> material in the introduction (which some regard as a set of comments) 
> is the best location within the document.

An early version of the API had a lastPosition attribute for this 
purpose, however the group decided to drop it in favour of the current 
mechanism.
You can find the mailing list thread here: 
http://lists.w3.org/Archives/Public/public-geolocation/2008Nov/0145.html

>
> 2.2
>
> Section 4 points out issues with user privacy. If permission is 
> denied, an implementation should return a PERMISSION_DENIED error. 
> This is not mentioned in section 4. 

Section 4 does not go into this level of detail. The error codes are 
defined in section 5.

> Furthermore, subsection 4.1 talks at length about user agents not 
> being permitted to transmit location information back to a Web server, 
> yet as anyone knows, if a script can access the data then it can be 
> mangled and placed into a form for delivery back to the server in a 
> generic Web browser. So we assume the UA in question must be a 
> location specific tool (such as a map rendering application) rather 
> than a generic script-enabled browser. Demanding that the UA itself 
> not convey such data merely gives people a false sense of security.

We will add a clarification that user consent is required for location 
acquisition in the user agent: 
http://www.w3.org/2008/geolocation/track/actions/26
A script will not have access to the location data without the user's 
express permission.

>
> 3. Typographical Issues
>
> 3.1
>
> According to the Introduction (paragraph 2), Location is limited to 
> Latitude and Longitude. However, the Coordinates interface (section 
> 5.4) lists altitude as one of the properties.

The intended meaning of that sentence is to make it clear that location 
information is represented by latitude and longitude coordinates, as 
opposed to for instance addresses or other location formats.
A location may indeed be represented with an altitude value as well if 
that information is provided by the location provider.

>
> 3.2
>
> Section 6.2.5 uses the word "cheaply", which is poorly defined. Does 
> it refer to ensuring that the processing/memory overheads of the query 
> are minimized? Does it refer to the monetary cost to the end user, 
> assuming the query is a paid-for service? Does it refer to the expense 
> that may be incurred by the network operator to answer such queries? 
> Does it mean all of these things, and/or more?

The intended meaning is to query the last known position by using a 
minimum of computational resources.
We have an open action to rephrase this requirement: 
http://www.w3.org/2008/geolocation/track/actions/49

>
>
>
> [1] http://www.w3.org/TR/geolocation-API/
>
> Regards,
>
>  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Tuesday, 3 November 2009 14:04:42 UTC