Re: geolocation privacy statement strawman

Hi Alissa,

On Wed, Apr 8, 2009 at 10:13 PM, Alissa Cooper <acooper@cdt.org> wrote:
> 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.
>

This is fine with me.

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


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

So the proposal here is to add this sentence. Fine with me.

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

Ok.

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

Many thanks,
Andrei

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

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.

Received on Wednesday, 15 April 2009 15:04:18 UTC