W3C home > Mailing lists > Public > public-geolocation@w3.org > January 2011

Re: Privacy considerations for implementors of the Geolocation API

From: Lars Erik Bolstad <lbolstad@opera.com>
Date: Thu, 06 Jan 2011 09:20:45 +0100
Message-ID: <4D257B5D.5050309@opera.com>
To: Doug Turner <dougt@dougt.org>
CC: Andrei Popescu <andreip@google.com>, Adrian Bateman <adrianba@microsoft.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
On 05.01.2011 18:49, Doug Turner wrote:
> On Jan 5, 2011, at 4:31 AM, Andrei Popescu wrote:
>> On Tue, Dec 28, 2010 at 12:33 AM, Adrian Bateman<adrianba@microsoft.com>  wrote:
>>> On Friday, November 19, 2010 7:16 AM, Andrei Popescu wrote:
>>>> On Mon, Nov 15, 2010 at 3:32 PM, Doug Turner<dougt@dougt.org>  wrote:
>>>>> I'd like the consideration section to reflect the intent we had.  I
>>>>> would rather have us leave the MUST but change what we meant to be
>>>>> displayed to the user.  Maybe "HOST of the requesting document".  There
>>>>> are probably others with a better name for this field.
>>>> I just checked and Adrian is right, nobody shows the scheme part. I think
>>>> changing to say "host" is reasonable. Adrian, would be ok with saying
>>>> "host" and keeping this as a MUST?
>>> Microsoft's position is that mandating a particular user experience is not appropriate for an API specification. Specifying this kind of UI does not protect users' privacy. Specified this way, an implementer could mistakenly choose to ignore the UI requirement if it doesn't match the UA's general approach without considering the consequences. It is much more useful to outline the privacy concerns and mandate that an implementation must suitably mitigate these in line with the overall privacy policy of the UA.
>>> The fact that the specification requires a particular UI today but that none of the implementations conform is ample demonstration that this clause does nothing to protect anyone's privacy.
>>> I realise it is late in the process to raise this issue for the v1.0 specification. If the consensus is to keep this language then we will encourage the working group to revisit the discussion as part of the v2 specification.
>> Keeping the existing language for v1 and re-visiting the issue in v2
>> sounds reasonable to me.
>> Thanks,
>> Andrei
> Yup.  Sounds fine.
> Doug

I agree.

I have created ISSUE-85 to keep track of this:

Lars Erik
Received on Thursday, 6 January 2011 08:29:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:57 UTC