Re: geolocation privacy statement strawman

On Tue, Apr 21, 2009 at 10:57 PM, Alissa Cooper <acooper@cdt.org> wrote:
> 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).
>

Ah, you're right. Agreed.

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

Ok with me.

If you (or anyone else) have no further comments, this is what I will
be adding to the spec:

---------------------------------

Privacy considerations for implementors of the Geolocation API

User Agents must not send location information to Web sites without
the 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 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

Recipients must only request location information when necessary.
Recipients must only use the location information for the task for
which it was provided to them. Recipients must dispose of location
information once that task is completed, unless 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 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.

---------------------------------

Also, I hope you are ok with adding your name to Acknowledgments?

Thanks again for the contribution,
Andrei

Received on Monday, 27 April 2009 16:38:26 UTC