Re: Additional security and privacy considerations?

Hi Thomas,

Thanks for the suggestions!

2009/5/13 Thomas Roessler <tlr@w3.org>:
> To put some more meat to this discussion, here are some proposed edits for the "privacy considerations for implementors of the Geolocation API":
>
> <add>
>
> Persistent permissions can lead to privacy leaks due to a number of effects:  Users are known to sometimes grant permissions erroneously and unintentionally.  Domain names change owner, business practices change, web sites are subverted.  In all of these scenarios, the ability to easily revoke permissions can be critical to the user's safety and privacy; likewise, it becomes critical for users to understand what data are revealed during their ongoing interaction with Web applications.  Therefore, user agents must take steps to limit the risk of inadvertent location disclosure, even after permission to share location has been granted by the user:
>
>
> 1. User agents must inform the user when Web applications acquire location information based on a consent granted previously.
>
>  Example: A user agent shows a specific icon in the status bar when the web application that the user currently interacts with has acquired location information.
>

I agree that informing the users that their position is being
monitored sounds like a reasonable idea and we could probably
recommend that UAs do this. However, I feel that we don't really have
any concrete evidence to indicate that it will actually benefit users
(Doug's experience with ambient indicators seems to suggest the
opposite). As far as I know, such solutions are validated through
usability studies and I haven't yet seen such a study (do you know of
any?) so it is hard to say how useful this would be in practice. Given
this and the reasons given by Hixie, I think that we should not make
this a "must" in the spec. Instead we could mention it as a
non-normative suggestion.

> 2. When location information is passed to a web application, a user interface for revoking the relevant permissions must be easily and obviously available.
>

Again, since we cannot define what is meant by "easily and obviously
available", I feel that this requirement is not really useful.

> 3. User agents should limit the scope of authorizations in time by asking for re-authorization in certain intervals.  As a general guideline, authorizations related to location information should not be considered valid for more than one week. Often, a shorter time will be appropriate.
>

Ok, I agree with the "User agents should limit the scope of
authorizations in time by asking for re-authorization in certain
intervals" part.  But why exactly would the guideline say one week and
not some other period? Again, I think we should refrain from
suggesting such magic constants in the absence of any usability
studies or implementation experience that would demonstrate their
validity.

> </add>
>
>> 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.
>
> Additional points:
>
> - Add: "In some circumstances, use of sensor data (GPS, wireless networks, GSM/CDMA cell information) to acquire location data might be inappropriate.  Conforming implementations of this specifications may use other mechanisms to acquire location data, including prompting users for location data that is then made available through the API specified here."
>

I'm sorry, I don't really follow. The API is meant to be agnostic wrt
to the sources of location data. What purpose would the above wording
serve?

> - In the privacy considerations for recipients, replace "use of HTTPS is encouraged" by "use of encryption is encouraged"
>

Ok, sounds good.

Many thanks,
Andrei

Received on Wednesday, 20 May 2009 01:13:17 UTC