UWA WG feedback on geolocation API

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.

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.

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. 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.

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.

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?



[1] http://www.w3.org/TR/geolocation-API/

Regards,

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Monday, 10 August 2009 19:03:44 UTC