Re: geolocation privacy statement strawman

To me it makes sense for the privacy considerations section to be  
normative and use RFC 2119 terminology. Assuming we go that route,  
here's a rundown of the parts of the current proposal (as edited by  
me) where questions have been raised about 2119 language:

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


First sentence: This is tricky. I would want this to be a MUST, but  
there's a caveat in the text for UAs with prearranged trust  
relationships. My suggestion:

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

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.


> Web sites MUST only request location when necessary.


I think this can be a MUST because necessity is subjective. There is  
already some wiggle room built in by using the word "necessary"  
without defining what it means.


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


First sentence: I could live with this as a SHOULD -- providing access  
to information is not always possible, especially if steps have been  
taken to decouple the location from any identifying information.

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.

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


Any decent website should already be disclosing these things, so I  
don't see why these can't be MUSTs.

On Apr 8, 2009, at 7:13 AM, Andrei Popescu wrote:

> Hi Alissa,
>
> Thanks a lot for the comments!
>
> On Sat, Apr 4, 2009 at 12:19 PM, Alissa Cooper <acooper@cdt.org>  
> wrote:
>>> Privacy considerations for implementers of the Geolocation API:
>>>
>>> User Agents must not send location information to websites without
>>> express permission of the user. 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.
>>
>> FWIW, I agree with Angel that the "shoulds" above should be  
>> "musts." If the
>> whole section is going to be non-normative anyway, what's the harm?
>>
>
> I thought about this more and I'd like to propose that these sections
> remain normative and, hence, use RFC 2119 terminology. What do you
> think? Also, in such a case, is the current usage of "shoulds" vs
> "musts" reasonable to you?
>
>>>
>>>
>>> Some User Agents will have prearranged trust relationships that do  
>>> not
>>> require such user interfaces.
>>
>> To ensure that the sentence above doesn't swallow the  
>> considerations for
>> implementers entirely, I would say something like, "In limited
>> circumstances, certain User Agents will have. . .." Otherwise every  
>> UA could
>> claim to have "prearranged trust relationships."
>>
>
> Agreed.
>
>>> 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.
>>
>> I'm not so sure that this is true. A design decision was made  
>> within Geopriv
>> to include default privacy rules about retention and  
>> retransmission, but
>> that decision was based on several factors, with level of "concern"  
>> being
>> only one of them. As the rest of this paragraph explains, there are  
>> other
>> privacy considerations besides retention and retransmission (use,
>> disclosure, etc.), so I'm not sure how much value is added by  
>> declaring that
>> two of these are "primary." I would drop this sentence.
>>
>
> Here I have the same question as Doug.
>
>> Before getting into use limitation as the next sentence does, it  
>> might make
>> sense to say something about limiting collection, such as:
>>
>> Web sites must only request location when necessary.
>>
>> This might seem really obvious, but a surprising amount of data  
>> collection
>> goes on "just because" (look at how much data most Facebook apps  
>> collect
>> compared to what they need to deliver their services). This trend  
>> has made
>> collection limitation a pretty standard privacy principle.
>>
>
> Sounds good to me (+ same question as Doug, especially if this section
> stays normative).
>
>>> Recipients must only 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.
>>
>> Nit: It is unclear what the phrase "to do so" refers to in the above
>> sentence -- using the information for other tasks, or retaining it  
>> beyond
>> the completion of a task? Suggestion:
>>
>> 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.
>>
>
> Sounds good.
>
>>> 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.
>>
>> To stay consistent with the rest of this text, the sentence above  
>> should say
>> "user's express consent." Also, both of the "shoulds" in the above  
>> should be
>> "musts."
>>
>
> I think these should be "shoulds" if the section stays normative?
>
>>> Care should be taken when retransmitting
>>> and use of HTTPS is encouraged. Furthermore, a clear and accessible
>>> privacy policy should be made available to all users that details  
>>> the
>>> usage of location data.
>>
>> This disclosure suggestion is a little limiting if the words "privacy
>> policy" are interpreted to mean the usual long privacy statement  
>> linked at
>> the bottom of a Web site. It might make sense to leave some room for
>> disclosure in other places. It could also be more clear about what  
>> needs to
>> be disclosed -- there is a pretty standard set of items that are  
>> usually
>> disclosed in notices like this. Suggestion:
>>
>> 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.
>>
>
> Sounds good (+ same question as Doug).
>
> Again, thanks for the contribution, it is great we are making  
> progress on this.
>
> All the best,
> Andrei
>

Received on Wednesday, 8 April 2009 21:14:52 UTC