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