Re: Additional security and privacy considerations?

Hi Thomas,

On Thu, May 21, 2009 at 9:54 PM, Thomas Roessler <tlr@w3.org> wrote:
> 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,

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.

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

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

Yes, as explained above, it does contain normative requirements as far
as I can tell.

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

What exactly do you mean by "clearly not acceptable"? Clear to whom and why?

> nor does it make the revocation story credible.

But if the user was the one who granted permission to a Web site in
the first place (so the user knows that particular Web site can read
her location), why is the revocation of permission by the same user
not 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?
>

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

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

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

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

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

All the best,
Andrei

Received on Friday, 22 May 2009 22:26:29 UTC