Re: Additional security and privacy considerations?

On Mon, May 25, 2009 at 10:47 AM, Thomas Roessler <tlr@w3.org> wrote:
> 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.
>

We didn't actually invent anything. The same convention is used by
HTML 4 (so 10 years ago!)

http://www.w3.org/TR/REC-html40/conform.html

and CSS 2:

http://www.w3.org/TR/CSS2/conform.html

and HTML 5:

http://dev.w3.org/html5/spec/Overview.html#conformance-requirements

Given this, I don't believe we should change anything.

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

I think the conformance section lists them in upper case precisely for
those people who are used to look for them in upper case. Given that
CSS and HTML 4 and 5 (and plenty of other standards as well) do the
same thing, I don't think we should do something else. Maybe Matt can
shed more light into this?

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

Ok, I will move the conformance requirements to the top.

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

Either way, I don't understand why this is required for the revocation
story. What is the exact reason?

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

Ok, but at least do we agree there is no proof for this? Or do you
have any (i.e. any usability study / implementation experience) that
would convincingly show that the visual indicator can achieve the said
goal?

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

I am sorry but I do not see above anything that answers my question.
You are asking to separate the goal from the realization of the goal.
To me this is entirely unrealistic in this case: the only mechanism
that has been proposed so far to realize the goal is some sort of
visual indicator. But whether this achieves the goal is debatable.
Also, what if the UA has a full screen mode (this was mentioned
before)? So what is an implementer supposed to do? For these reasons
I'm afraid that adding your goal to the spec will put our implementers
in an impossible situation. This is why I oppose adding your goal to
the spec.

Thanks,
Andrei

Received on Tuesday, 26 May 2009 13:00:55 UTC