RE: Additional security and privacy considerations?

Hi,

   I use a radar detector with GPS that  can record the location and
radar characteristics  and "learn" (based on remembering three
occurrences of the same radar signal at ~ the same location). I wish it
would indicate when it is detecting radar signals, even when they have
been "learned".

   Similarly, I wish there is an indication that location reporting is
occurring.

petere

Peter Ecclesine, Technology Analyst

MS SJ-14-4 170 West Tasman Dr, San Jose, CA 95134-1706 

Ph 408/527-0815, FAX 408/525-9256

"Time doesn't fool around."  "Without Prejudice" U.C.C. 1-207


-----Original Message-----
From: public-geolocation-request@w3.org
[mailto:public-geolocation-request@w3.org] On Behalf Of Perry Tancredi
Sent: Wednesday, May 20, 2009 8:26 AM
To: Thomas Roessler
Cc: Andrei Popescu; Rigo Wenning; Doug Turner; public-geolocation
Subject: Re: Additional security and privacy considerations?



Sent from my PDA

On May 20, 2009, at 3:41 AM, "Thomas Roessler" <tlr@w3.org> wrote:

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

Whether the recommendations are normative or not, I'm afraid that any  
goal that states that "users must be aware" of something is  
impractical enough to be effectively ignored.  UAs cannot control  
awareness. Something like the first goal is much more reasonable, and  
I would go a step further to say that "users must be able to determine  
when their information is being shared based on previously granted  
permissions, and have the ability to revoke those permissions.". Or  
you can change the must to should.  Either way, informing users  
without giving them the ability to act on the information is not a  
good recommendation.

If we want to require the user's explicit consent to share their  
location, the lanuage could be "users must grant their explicit  
consent before their location is shared."  Users can be able to allow  
sharing either the first time they grant permission to a particular  
provider (e.g. I grant foo.com permission to locate me and to share  
that information) or not.  If they don't, new permission must be  
granted each time it is shared.

On the question of usability studies, every option is equally flawed  
in the absence of a study, including doing nothing.

>>> 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 18:24:40 UTC