RE: Additional security and privacy considerations?

 
I agree with #3 and Doug's suggested wording below.  

Also, we all agree that users must be able to revoke sticky permissions.


I wonder, however, if we still have a problem in the case that a user
who wants to revoke permissions to specific application won't know which
permissions to revoke because they don't where the permissions where
inherited from.

The goal, as stated earlier, isn't that "Users must be able to tell when
location is shared," it really is that "Users must be able to revoke
permissions to any application."  If a user can't figure out which
permission to revoke, then we've done a disservice to users and
applications because some users will feel forced to revoke all
permissions.

Actively informing users is not the answer.  Allowing users to discover
which permissions a specific application is relying on may make revoking
permissions more meaningful, but some platforms may find providing that
information too challenging.
  
Perry

-----Original Message-----
From: public-geolocation-request@w3.org
[mailto:public-geolocation-request@w3.org] On Behalf Of Doug Turner
Sent: Tuesday, May 26, 2009 12:34 PM
To: Thomas Roessler
Cc: Andrei Popescu; Greg Bolsinga; Rigo Wenning; public-geolocation
Subject: Re: Additional security and privacy considerations?


On May 26, 2009, at 10:52 AM, Thomas Roessler wrote:

> On 26 May 2009, at 19:33, Andrei Popescu wrote:
>
>>> So, let's take a step back here.
>>>
>>> Are you objecting against having *any* privacy considerations in the

>>> spec?
>>> Or are you objecting against having a MUST in normative language?
>>>
>>> As I said early on in this thread, I could live with text along the 
>>> lines of what I proposed included as non-normative implementation 
>>> guidance (or a "strong should", or something like that), distinct 
>>> from conformance requirements, *if* that helps to get clear guidance

>>> on privacy into the specification. It was Andrei who brought up the 
>>> point that the privacy considerations are currently meant to be 
>>> normative.
>>>
>>> Care to elaborate?
>>>
>>
>> My impression is that the existing wording (location permissions must

>> not be granted without user consent and users must be able to revoke 
>> sticky permissions) was agreed by everyone and are normative. What we

>> are discussing here are the extensions you suggested:
>>
>> 1. User agents must inform the user when Web applications acquire 
>> location information based on a consent granted previously.
>> 2. User agents should limit the scope of authorizations in time by 
>> asking for re-authorization in certain intervals.
>
> These extensions can be discussed as:
>
> 1. Normative language with a MUST (which I'm seeing opposition
> against)
> 2. Normative language with a SHOULD (which I saw Hixie and Lars Erik 
> suggest earlier) 3. Non-normative guidance (which I'd be willing to 
> accept, as I said earlier; in that case, I'd like to re-add the 
> examples and elaborate a bit more on the text)
>
> My question is whether there is opposition against 2 or 3.
>
>

I would be okay with something like:

User agents "MAY" inform...
User agents "MAY" limit the scope....

Is this in a "non-normative guidance" voice?

Doug

Received on Tuesday, 26 May 2009 23:15:10 UTC