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

Dealing with "accuracy"

From: Thomson, Martin <Martin.Thomson@andrew.com>
Date: Thu, 23 Oct 2008 22:53:17 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF10501EEB7@AHQEX1.andrew.com>
To: <public-geolocation@w3.org>
(Firstly, apologies for the mail format; it’s hard to talk about this without pictures.  I hope that the images aren’t lost in transit.)

 

Hi,

 

It appears that a holistic view of accuracy is needed.  From the application perspective, there is an understanding that the accuracy of the result needs to be considered.

 

I proposed in an earlier mail that the “enableHighAccuracy” flag be deprecated in favour of a “targetAccuracy” value.  This would have the effect of putting a measure of control in the hands of the application.  I’d like to close the loop now and look at the entire process.

 

Say I’m developing a location app: yet another food finder.  As an application developer, I decide that 200m accuracy is sufficient for my purposes.  I include that in the PositionOptions.

 

When I ask for location, a user to my site sees a message like the following:

 

 

 

This differs from the UI we’ve seen so far (Geode, [1]).  The new piece of information is that is shows what accuracy the web site wants.

 

If the user wants to change the accuracy provided, they can select “Limit accuracy…”, which expands as follows:

 

 

 

If the user opts to remember the setting, the accuracy is remembered along with the site.  The default would be to not limit accuracy if the user allowed the request.

 

I’ve shown in the figure that the user has opted to provide higher accuracy than requested if that is the outcome of the positioning method.  Obviously, if a user is attempting to protect their privacy, they could specify a higher value.

 

It’s necessary also to specify how a browser obscures location information in this case.  An inconsistent approach could lead to inadvertent leaks of private information.  I’d recommend that the method employed by the IETF GEOPRIV WG be adopted.  [2] is quite clear in setting out requirements and proposes a general method of obscuring that is quite applicable here.

 

A “targetAccuracy” attribute is also useful as a hint to the browser in selecting location providers, or to the location provider in selecting an appropriate determination method.  I’ve also shown a possible addition to the interface that shows the location providers configured in the browser.  Maybe there is an option to explicitly select or disable each.  Obviously, that’s a trade-off the browser developers need to consider.

 

 

 

Therefore, the algorithm for a successful request might be as follows:

 

1.  The application requests location and specifies “targetAccuracy”.

2.  The user grants the request and sets a preferred “targetAccuracy”.

3.  The larger of user and application “targetAccuracy” is used by the provider(s) to determine location information.

4.  If the resulting accuracy is better than the user’s preference then the result is obscured as in [2].

5.  The result is provided to the application.

 

Applications will need to learn how to deal with poor accuracy.  That’s just how location is unfortunately.  The positive side of this for privacy is that when a user purposefully degrades accuracy to protect their privacy, the application is not necessarily able to distinguish between this and an occasion where the location determination failed to perform.

 

Regards,

Martin

 

[1] http://www.azarask.in/blog/post/firefox-geolocation-js-library/


[2] http://tools.ietf.org/html/draft-ietf-geopriv-policy-17#section-6.5.2


 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

image001.png
(image/png attachment: image001.png)

image002.png
(image/png attachment: image002.png)

image003.png
(image/png attachment: image003.png)

Received on Friday, 24 October 2008 03:54:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:52 UTC