Re: Additional security and privacy considerations?

peter, you are asking for a feature for some product, not for a  
requirement in the specification, right??

Doug

On May 20, 2009, at 10:07 AM, Peter Ecclesine (pecclesi) wrote:

> 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 21:35:31 UTC