W3C home > Mailing lists > Public > public-geolocation@w3.org > April 2009

Re: geolocation privacy statement strawman

From: Alissa Cooper <acooper@cdt.org>
Date: Tue, 21 Apr 2009 17:57:45 -0400
Cc: public-geolocation <public-geolocation@w3.org>
Message-Id: <95E4065F-C8C9-4ED7-99BC-C8EE7A272A40@cdt.org>
To: Andrei Popescu <andreip@google.com>
Comments inline...

On Apr 15, 2009, at 11:03 AM, Andrei Popescu wrote:
>>
>>> Browsers SHOULD acquire permission through a user interface which  
>>> will
>>> include the URI of the document origin. All permissions SHOULD be  
>>> revocable,
>>> and User Agents SHOULD respect revoked permissions.
>>
>> Second sentence: I think both of these should be MUSTs. Consent is  
>> really
>> not that useful without control. UAs that either don't allow  
>> revocation or
>> don't respect revoked permissions need to ask themselves why they are
>> seeking consent in the first place.
>>
>
> True but re-reading 2119, I am reminded that the definition of  
> "should" is :
>
> "This word, or the adjective "RECOMMENDED", mean that there may exist
> valid reasons in particular circumstances to ignore a particular item,
> but the full implications must be understood and carefully weighed
> before choosing a different course."
>
> So I guess this is precisely the use case for "should"? The
> implementation must follow the spec wording unless there is a valid
> reason to do otherwise. For example, if a prearranged trust
> relationship exists, as described in the paragraph above, then the UA
> would have a valid reason not to implement a mechanism for revoking
> permission. I think there's no harm in keeping these as "should".
>

I can see the argument for the first SHOULD (permissions SHOULD be  
revocable) in the case of prearranged trust relationships. However, I  
really don't see the point of offering to revoke permissions but not  
respecting the revocation. So I still think the second SHOULD should  
be a MUST (UAs MUST respect revoked permissions).

>
>>
>>> If location information is stored, users
>>> SHOULD be allowed to update and delete this information. The  
>>> recipient
>>> of location information SHOULD NOT retransmit the location  
>>> information
>>> without the userís consent.
>
>> Second sentence: This should be a MUST NOT. Pretty obvious coming  
>> from me,
>> since I'm in favor of the user being able to provide explicit  
>> directives
>> about retransmission.
>>
>
> Heh, I see :) But in light of the paragraph below, I still think this
> can be a "should not".
>
>>> Recipients MUST clearly and conspicuously disclose the fact that  
>>> they are
>>> collecting location data, the purpose for the collection, how long  
>>> the data
>>> is retained, how the data is secured, how the data is shared if it  
>>> is
>>> shared, how users may access, update and delete the data, and any  
>>> other
>>> choices that users have with respect to the data. This disclosure  
>>> MUST
>>> include an explanation of any exceptions to the guidelines listed  
>>> above.
>>
>
> Since we allow exceptions as long as they are clearly and
> conspicuously disclosed, then is it ok to keep the word "should" in
> the previous paragraph?
>
>

I disagree that we "allow exceptions as long as they are clearly and  
conspicuously disclosed." The only places where we have exceptions are  
where we have SHOULDs: the prearranged trust relationship caveat to  
acquiring permissions through a UI and making permissions revocable,  
and access to stored information. The requirement that exceptions be  
disclosed certainly does not mean that all exceptions are allowed.

Therefore, I remain in support of using MUST NOT in the sentence "The  
recipient of location information MUST NOT retransmit the location  
information without the userís consent."


>
> ----------------
>
> For reference here's the wording with the changes we both agree on:
>
> Privacy considerations for implementors of the Geolocation API
>
> User Agents must not send location information to websites without
> express permission of the user. User Agents must acquire permission
> through a user interface, unless they have prearranged trust
> relationships as described below. The user interface must include the
> URI of the document origin. All permissions should be revocable, and
> User Agents should respect revoked permissions.
>
> Some User Agents will have prearranged trust relationships that do not
> require such user interfaces. For example, a Web browser will present
> a user interface when a Web site performs a geolocation request.
> However, a VOIP telephone may not present any user interface when
> using location information to perform an E911 function.
>
> Privacy considerations for recipients of location information
>
> The two primary concerns regarding recipients of location information
> are retention and retransmission. Recipients must only request
> location information when necessary, must use the location information
> for the task for which it was provided to them and must dispose of it
> once completed, unless expressly permitted to do so. Recipients must
> also take measures to protect this information against unauthorized
> access. If location information is stored, users should be allowed to
> update and delete this information. The recipient of location
> information should not retransmit the location information without the
> userís consent. Care should be taken when retransmitting and use of
> HTTPS is encouraged. Recipients must clearly and conspicuously
> disclose the fact that they are collecting location data, the purpose
> for the collection, how long the data is retained, how the data is
> secured, how the data is shared if it is shared, how users may access,
> update and delete the data, and any other choices that users have with
> respect to the data. This disclosure must include an explanation of
> any exceptions to the guidelines listed above.
>
>

There are a few places where this is a little off, I think, based on  
previous messages in this thread. I also think it might be worthwhile  
to break up the recipient section into a couple of paragraphs for  
readability. Here's my understanding of the current text, with the two  
outstanding 2119 issues in brackets:


Privacy considerations for implementors of the Geolocation API

User Agents must not send location information to websites without
express permission of the user. User Agents must acquire permission
through a user interface, unless they have prearranged trust
relationships as described below. The user interface must include the
URI of the document origin. All permissions should be revocable, and
User Agents [must | should] respect revoked permissions.

Some User Agents will have prearranged trust relationships that do not
require such user interfaces. For example, a Web browser will present
a user interface when a Web site performs a geolocation request.
However, a VOIP telephone may not present any user interface when
using location information to perform an E911 function.

Privacy considerations for recipients of location information

Web sites must only request location when necessary. Recipients must  
only use location information for the task for which it was provided  
to them. Recipients must dispose of location information once that  
task is completed, unless they are expressly permitted to retain it by  
the user. Recipients must also take measures to protect this  
information against unauthorized access. If location information is  
stored, users should be allowed to update and delete this information.

The recipient of location information [must | should] not retransmit  
the location information without the userís express consent. Care  
should be taken when retransmitting and use of
HTTPS is encouraged.

Recipients must clearly and conspicuously disclose the fact that they  
are collecting location data, the purpose for the collection, how long  
the data is retained, how the data is secured, how the data is shared  
if it is shared, how users may access, update and delete the data, and  
any other choices that users have with respect to the data. This  
disclosure must include an explanation of any exceptions to the  
guidelines listed above.
Received on Tuesday, 21 April 2009 21:58:21 GMT

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