Re: Additional security and privacy considerations?

On 21 May 2009, at 22:22, Andrei Popescu wrote:

> Ok, can you please explain why do you think they read like they are
> non-normative?

Well, the privacy and security considerations don't contain a single  
RFC 2119 keyword, and they come right between the non-normative scope  
and the conformance requirements section.  These are all typical  
characteristics of non-normative material.  If this text is meant to  
be normative, then it ought to contain some normative requirements, no?

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

> Well, what really matters is for us to have a clear set of privacy
> protection requirements for API implementers and recipients of
> location information. Asking for user consent and offering the
> possibility for users to revoke permissions are basic requirements
> that are meant to put the user in control of how their location is
> made available.

Glad to see that we're on the same page on that.

> However, a goal such as "Users must be able to tell when location is  
> shared", well-intended as it may sound, would need to be tested to  
> prove its real benefits. This is why I am proposing that we add it  
> as a non-normative suggestion, at least until some evidence is  
> produced to prove its value.

Well, the opposite view would be that it's ok for implementations to  
generate a situation in which the user has no ability to make that  
distinction.  That is clearly not acceptable from a privacy  
perspective -- nor does it make the revocation story credible.  You  
certainly wouldn't want to say that it's fine for the API to grant  
access to location information without the user being able to  
distinguish the situations, right?

The evidence you're talking about would prove the value of a specific  
*mechanism*.  I'm not suggesting to prescribe a mechanism, merely to  
prescribe the goal.  (And the goal is not that users *are* aware under  
all circumstances, but that there is some signal available to them  
that makes the situations distinguishable.)

> Having it as a non-normative suggestion will encourage implementers  
> to explore it but will not force them to stick to it if it doesn't  
> work or, as Hixie said, they find some better solution.

I'm happy for concrete details (e.g., "have a visual indicator") to be  
non-normative examples, and have suggested that much.  The general  
goal, though, needs articulating, and in strong words.

Again, if you can come up with wording that's acceptable to you, I'd  
love to see your ideas.

>>>> 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.
>
> I understand. I don't have a better alternative at the moment.

Let's both think more about wording for this one, and see where that  
takes us.

>
>>>> 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.
>>
>
> Right, so perhaps we could just live without giving a concrete number?
> Since this is a "should", those UA who will implement it will also
> have a sensible limit?

I can probably live with that, but would like to have a better sense  
of the overall privacy considerations before calling this a decision.

>> 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.
>>
>
> Ok, I thought it's pretty clear already but perhaps it isn't. The
> "Introduction" section says:
>
> "The API itself is agnostic of the underlying location information
> sources. Common sources of location information include Global
> Positioning System (GPS) and location inferred from network signals
> such as IP address, RFID, WiFi and Bluetooth MAC addresses, and
> GSM/CDMA cell IDs."
>
> We can add to the above paragraph that asking the user is another
> example of a source of location? We can also say that the location
> information is not necessarily guaranteed to be correct. Can you
> suggest a sentence to this effect?

Append: ", and user input.  No guarantee is given that the API returns  
the device's actual location."

Received on Thursday, 21 May 2009 20:54:59 UTC