Review of Security & Privacy text in current editor's draft

Hey all,

Sorry for the late comments, but I've just gotten back around to 
reviewing the Security and Privacy Considerations section in the current 
working draft.

One general comment is that this text indicates how privacy flags for 
retention and retransmission would be useful:
-- "...unless expressly permitted to retain it by the user."
-- "must not retransmit ... without the user’s consent."

Moreover, these flags would allow many sites to skip most of the 
disclosure requirements that are further down, since they would know 
what the user's privacy preferences are.  Two use cases:

Case 1:
1. Website requests and receives location information
2. Website finds permission indicated by privacy flags adequate
3. Website uses location information

Case 2:
1. Website requests and receives location information
2. Website finds permission indicated by privacy flags inadequate
3. Website displays disclosure box as required below
4. Website requests User Agent to upgrade permissions
5. User Agent asks user to confirm modifying privacy settings
6. User indicates permission (or not)
7. Website uses location information (if granted)

(Conversely, without these flags, the same text just encourages users to 
blindly click through of voluminous privacy agreements, since (1) it 
requires the disclosure of a lot of information, and (2) there is no 
mechanism besides click-through agreements for the user to indicate 
consent.)

Detailed comments are inline below, marked with <rlb></rlb>.

--Richard


Security and privacy considerations

The API defined in this specification can be used to retrieve the 
geographic location of a hosting device.

<rlb> s/can be/is/ </rlb>

In almost all cases, this information also discloses the location of the 
user of the device, thereby potentially compromising the user's privacy. 
A conforming implementation of this specification must provide a 
mechanism that protects the user's privacy and this mechanism should 
ensure that no location information is made available without the user's 
informed consent.

<rlb> Recommend deleting "provide a mechanism ... this mechanism 
should", since it doesn't mean anything. </rlb>


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 with users, as described below. The user interface must 
include the URI of the document origin [DOCUMENTORIGIN]. Those 
permissions permissions that are acquired through the user interface and 
that are preserved beyond the current browsing session (i.e. beyond the 
time when the browsing context [BROWSINGCONTEXT] is navigated to another 
URL) must be revocable and User Agents must respect revoked permissions.

<rlb> s/permissions permissions/permissions/ </rlb>
<rlb> I'm puzzled by all these references to HTML 5 when this document 
will clearly be used in the HTML 4 context. </rlb>


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.

<rlb> I'm concerned that people will view this paragraph as a loophole. 
  It seems like this could be restricted to simply the emergency case: 
In non-emergency applications, there is time for the user to authorize 
the UA to provide location (by definition!). Suggested text:
"
In some emergency applications, a User Agent may be prevented from 
obtaining a user's consent, either by the need to respond quickly to an 
emergency or by regulatory constraints.  Before providing location 
without user consent, the User Agent must have received an explicit 
indication that the recipient of location is an emergency application 
(the mechanism for this indication is outside the scope of this 
document).  When such an indication is not present (the usual case), the 
User Agent must acquire express user permission before providing location.
"
(... plus, delete the text above: "unless they have prearranged trust 
relationships with users, as described below")
</rb>


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.

<rlb> Recommend changing the second sentence to "Location should only be 
transmitted over secure channels, such as HTTPS" </rlb>

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, 12 May 2009 02:38:45 UTC