W3C home > Mailing lists > Public > public-geolocation@w3.org > March 2010

Re: enableHighAccuracy as a privacy feature

From: Doug Turner <dougt@dougt.org>
Date: Wed, 24 Mar 2010 09:17:55 -0700
Cc: public-geolocation <public-geolocation@w3.org>
Message-Id: <A00DB0B0-7AE8-4DEA-A7F0-BAB1CFE3C7E6@dougt.org>
To: Dominique Hazael-Massieux <dom@w3.org>
In the API, we do not have a way to negotiate accuracy.  I do not think that we should add yet another meaning to this already poorly named attribute.

Doug



On Mar 24, 2010, at 1:10 AM, Dominique Hazael-Massieux wrote:

> Hi,
> 
> The current Geolocation API editors draft [1] offers an optional
> enableHighAccuracy attribute on PositionOptions to make it possible for
> developers to inform whether they need a high level of accuracy or not,
> in the perspective of the power consumption and time that acquiring very
> accurate data may require.
> 
> But this attribute also offers a potentially useful privacy-enabler hook:
> indeed, a web site that doesn't need detailed location information can
> reduce the privacy risks associated with location information by
> ensuring that attribute is set to false.
> 
> But that aspect is not evoked at all in the specification  I think it
> should be (and have a specific text proposal below).
> 
> Right now, the spec doesn't recommend NOT sending high-accuracy data
> when it is not required, when I think it would clearly make sense for
> all interested parties to do so.
> 
> Consider the case of a user who has a GPS that already has a fix, they
> go to a website that has enableHighAccuracy set to false.  The
> application doesn't need accuracy, but nothing in the specification will
> prevent high accuracy location information from being sent.  Why
> needlessly expose information that the website doesn't need?
> 
> More specifically, I think it would make sense to require user agents to
> always provide less accurate information when enableHighAccuracy is
> false (which is the default when not specified).  The algorithm and user
> interface shouldn't be specified, and instead be left to the
> implementers.  The enableHighAccuracy flag could also be used for user
> agents as a hook to enable additional privacy-features (that I'll be
> happy to discuss if anybody is interested in the few ideas I've had).
> 
> To that end, here is a proposed addition to the spec that would complete
> the existing "enableHighAccuracy" description:
>        When enableHighAccuracy is false, user agents SHOULD ensure that
>        the location data sent back to the application is of limited
>        accuracy, regardless of whether higher accuracy data is
>        available, thus helping to reduce unneeded exposure of
>        privacy-sensitive data.
> 
> I'm also happy to provide test cases to help determine the current
> browsers behavior if that's helpful.
> 
> Dom
> 
> 1. http://dev.w3.org/geo/api/spec-source.html#position_options_interface
> 
> 
> 

Doug Turner
dougt@dougt.org
Received on Wednesday, 24 March 2010 16:18:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:46 GMT