Re: Additional security and privacy considerations?

On 20 May 2009, at 03:12, Andrei Popescu wrote:

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

So, that brings up a deeper point.  My reading was that the current  
security and privacy considerations are essentially non-normative --  
they certainly read like they are.  I know that that's causing dismay  
in some quarters (and I'm not particularly happy with it, either), but  
I'd be willing to support non-normative looking considerations of the  
kind we now have, provided they lead to clearer and more strongly  
worded recommendations than what one would get out of normative ones.   
If, however, we're now going through the wordsmithing that would be  
applied to normative recommendations, then we can as well make clear  
that the privacy considerations are normative.

As far as usability studies are concerned, the underlaying question  
here is what the goal of the indicator is.  The goal that I have in  
mind is: "Users must be able to tell when location is shared." That  
goal is different from "users must be aware that location is shared at  
all times" -- even though I'd certainly prefer if we could achieve the  
latter one.  If you don't achieve the former one, though, you're  
basically asking for trouble on the policy side of things.

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

A different way to say it would be "the revocation mechanism must  
actually be credible, and it mustn't be put into the UI equivalent of  
the local planning council on Alpha Centauri".  But that isn't useful  
specification language -- so, take this as a challenge to come up with  
better wording.

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

I'm not feeling too strongly about this point -- as you say, any magic  
constant will have problems (hence "general guideline" and "should");  
the goal was to draw a line somewhere, so people don't say "oh, 2000  
years are a perfectly limited scope."  In other words, we probably  
know what is totally unreasonable, but we don't quite know where  
precisely the border sits.

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

Reading this again, it's probably phrased in a way that obscures the  
actual point.  That point being: "The API is agnostic. The location  
source may be unreliable. Don't assume that you're always told the  
truth by this API."

The goal here is to make clear to anybody who cares to read the  
documentation that, e.g., prompting users to give location information  
(in other words, giving them the opportunity to lie about where they  
are) is totally acceptable.  Yes, that is implicit in the API's being  
agnostic to location sources, but I think it's worth calling out.

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

Thanks.

Received on Wednesday, 20 May 2009 10:40:45 UTC