- From: Andrei Popescu <andreip@google.com>
- Date: Mon, 30 Mar 2009 11:35:08 +0100
- To: Greg Bolsinga <bolsinga@apple.com>
- Cc: Angel Machín <angel.machin@gmail.com>, Doug Turner <doug.turner@gmail.com>, public-geolocation@w3.org
Hi, Here is a new draft wording based on the feedback received so far. 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. 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 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. Furthermore, a clear and accessible privacy policy should be made available to all users that details the usage of location data. This should include any exceptions to the guidelines listed above. On Wed, Mar 25, 2009 at 3:41 PM, Dirk Segers <dirk.segers@vodafone.com> wrote: > Hi all, > > Looks very good to me, just 2 minor suggestions below. > > Regarding the example of calling emergency services : as in Europe the > passing of the location is mandatory for calls to emergency services, > for Europe the wording "may not" would even be "is not allowed to"... > Ok, but I think it's fine to keep as is, since that sentence shows just an example of when it is reasonable not to present a user interface before acquiring the user's location. > Regarding the two primary concerns with the recipients of geolocation > information, one might add a 3rd one (or alternatively include it in > "data retention" more explicitly), being the concern to ensure proper > protection of the geolocation data with the recipient (eg against > unauthorised access by the staff of the website owner and/or access to > these data by unauthorised 3rd parties). Added the following sentence "Sites must also take measures to protect this information against unauthorized access". Do you think we need to be more specific than this? > Also if this aspect is covered > by the privacy policy we might want to mention it explicitly here as > well. > I'm not sure I fully understand. Should we explicitly mention that the privacy policy may say something about how the location information is protected against unauthorized access? I've added a sentence that explains how does the privacy policy relate to this guidelines. Would you think that is enough? On Wed, Mar 25, 2009 at 4:45 PM, Angel Machín <angel.machin@gmail.com> wrote: > Hi Andrei, > > > IMHO, I think it should be: "permissions *must* be revocable, and > applications *must* respect revoked permissions". > > If User Agents store these permissions internally they have to be revocable > by users at any time and the UI must allow it. As these sections are meant to be guidelines, I think we should be using the verb "should" in all cases except where we have a good reason not to. We're saying that the location must not be disclosed without user consent but, beyond that, I think the verb "should" is the appropriate one. Thanks, Andrei
Received on Monday, 30 March 2009 10:35:48 UTC