Re: Additional security and privacy considerations?

On 23 May 2009, at 00:25, 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,
>
> Hmm, I thought "must" and "should" are RFC2119 keywords... Our
> "conformance requirements" section says
>
> "The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
> "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this
> document are to be interpreted as described in RFC2119. For
> readability, these words do not appear in all uppercase letters in
> this specification."
>
> So I am not entirely sure what makes you say that.

Ah, the joys of newly inventing editorial conventions.

For what it's worth, I'm happy to have privacy considerations as part  
of the normative spec material.

Editorially, I would suspect that quite a few people will (like  
myself) read the privacy considerations as non-normative, simply  
because the general convention is to have the keywords in uppercase  
(or at least bolded!) when they're meant to be normative.  That holds  
in particular when there's a conformance requirements section that has  
them listed that way.  Please either use the RFC 2119 keywords in  
their uppercase forms throughout the document, or change the  
conformance section to list them in the form in which they're actually  
used in the rest of the document.

The current approach is simply confusing, since many readers upon  
seeing the list of RFC 2119 keywords will simply skip on, and then  
expect the usual convention to be in place.

>> and they come right between the non-normative scope and the
>> conformance requirements section.

> Is there a rule about this? I am not aware of any but if there is, I'm
> happy to shuffle the sections around to match the rule.

Not a rule -- but shuffling these sections would certainly make things  
clearer, and less open for interpretation later on.  It's entirely too  
common that the "conformance requirements" section is what actually  
starts the normative part of a spec.

[snipping some pieces]

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

> I think what we want is for the user to distinguish between a Web site
> being able to access her location and the Web site not being able to
> access her location. That is the crucial distinction that makes the
> "revocation story" credible.

yes.

> I don't see why being able to tell at
> which point in time the Web site is actually making use of this
> capability is a mandatory requirement for the "revocation story".

I'm not insisting that some signal must be given *only* when the site  
invokes the API:  I'm saying that a signal must be given *at* *least*  
when the site invokes the API and succeeds based on previous  
permissions.

Whether an implementation chooses to show a signal whenever the user  
interacts with a site that has access to geolocation information, or  
whether a signal is only given when the API is actually exercised,  
should be an implementation choice.  (In fact, I can see good reasons  
to make either of these choices depending on the specific  
circumstances of a UI, so I think it's important that this particular  
choice remains up to implementations. I think that my language  
achieves that, but would be happy to have another example added to  
clarify this point.)

>> 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.)
>
> Right, but if that signal (or mechanism, if you prefer) is not some
> visual indicator (whose usefulness, I think we agree, is unclear),

No, we don't agree on that point.  Again, the usefulness is in giving  
the user the ability to distinguish the situations without having to  
remember the way to Alpha Centauri.  A visual indicator can achieve  
that.

The usefulness is questionable if the goal is for the user to be aware  
of the geolocation permissions at all times.  But, as I said before, I  
think that that goal is a red herring, and we shouldn't make the  
presence of a signal contingent upon achieving it.

> then what is left? I guess what I am saying is that, given the choice
> of available "mechanisms", it seems that forcing this goal upon our
> implementers may not be such a good idea, after all.

See above.

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

> I disagree, as explained above.

So, I'm confused about your logic now.  In the same message, earlier  
on, you said this:

> I think what we want is for the user to distinguish between a Web site
> being able to access her location and the Web site not being able to
> access her location. That is the crucial distinction that makes the
> "revocation story" credible.

How is that consistent with your disagreement now?


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

ok, let's keep this point as an open issue for the moment and see  
where the rest of the discussion goes.

>>> 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."
>>
>
> Ok, will do, thanks.

Thanks.

Received on Monday, 25 May 2009 09:47:32 UTC