W3C

Disposition of comments for the Web Security Context Working Group

Single page view

In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.

In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.

CommentorCommentWorking Group decisionCommentor reply
LC-2199 <Anna.Zhuang@nokia.com> (archived comment)
Dear WSC WG,

Below please find some comments to the guidelines.

Best regards,
Anna Zhuang

************************************

*** Rich internet capabilities and advanced browser behaviour is not very well covered by the guidelines. E.g. the document does not seem to address well cases when AJAX application initiates background HTTPS connections.In particular how should UI behave when self-certified certificates (or other "bordercases") are present. Main issue here is that user might not understand what is going on at all, as connection is really AJAX "internal implementation" thing. So normal rules presented in the document seem to be a bit problematic.

*** There is no any mentioning of the following problem: If several WEB pages are visible, and any security question pops up, how should user know which page intiates it? Of course the document cannot dictate one and only way to solve this, but problem itself should be at least mentioned. Again, in connection to AJAX, this can be even more confusing.

*** Term mobile is not mentioned at all - nor the UI and interaction constraints that brings. Generally, the document gives an impression that mibile environment has neither been considered nor being addressed at the time of writing the guidelines. E.g. in cases of error/warning conditions the user has to interact (ok so far, but depends on what you define as error/warning). However, limited real-estate of a mobile device is not considered at all. If the guideline wants to define UI elements (how they should look), the issue is that UI elements that work for the PC do not necessarily work for the handheld.

*** 3.4 Conformance claims: SSLv3 reference URL is broken. Related: should you reference something that is not a formal specification.

*** 5.3 Mixed Content: "A Web User Agent that can display an AA indicator MUST NOT display this indicator unless all elements of the page are loaded from servers presenting a validated certificate, over strongly TLS-protected interactions." Why is not AA level required for all content? There is a warning about this mixing in "8.6 Mixing Augmented Assurance and Validated Certificates" but it is still allowed.

*** 6.4.3 Danger Messages: "These interactions MUST be presented in a way that makes it impossible for the user go to or interact with the destination web site that caused the danger situation to occur, without first explicitly interacting with the Danger Message." Even if the user desides to ignore the message and proceed, the danger should continue to be indicated. This requirement is rather hard. It impacts the UI design and and overall user experience. The can not be MUST requirements for the UI. Such requirements may not be universally achievable.

*** It is difficult to read - the informative (introductions/overviews) and the normative (must/must not | shall/shall not) could/should be separated for readibility.

*** The document has strange format for definitions [Definition: xxxx] Oftenly the text between square brackets does not give a good definition for a term but rather appears as part of continuous presentation of some concept. At the same time the document does not have any glossary at all. The document will benefit from all definitions to be moved to the glossary.

*** Many terms in the document don't have any definition at all. Some terms that are unique to this document don't have sufficient explanation of justification for their introduction:

*** Section 4.2.1 introduces terms Primary and Secondary UI. Later in the document, e.g. in 6.1.1 I see Primary and Secondary chrome. Are they the same? I would say that chrome is part of the UI but Primary and Secondary chrome is neither introduced nor explained

*** Section 5.1.2 introduces Augmented Assurance Certificate. What Augmented assurance actually is is not explained. Also in this section the achronym AAC is introduced but later in the document AA is used. I kept wondering what AA certificate (as opposed to AAC) actually meant and checked the web. The search result gave me several usages of AA certificate and those have no connection to IT or security whatsoever.

*** The bottom of the Section 5.1.2 mentions additional assurance level. Augmented assursance itself is not explained and now we have additional assurance as a mere mentioning without any elaboration.

*** There are many terms for certificates and root certificates in this document and they are either not explained or insufficiently explained. Also their relationship is not at all clear. You have validated certificate, locally configured trust anchor, special trust anchor, domain validated certificate, custom root certificate, self signed certificate, untrusted root certificate, extended validation certificates and may be some more. All of these terms have to appear in the glossary that is currently missing and either referenced to some standards where they are sufficiently ecxplained or have to be explained in WSC UI guidelines.

*** Section 5.1.3 third paragraph mentions certificate chains pinned to a destination but the term "pinning" is only introduces later in section 5.1.4.

*** What does "pinning" mean in practice, technically? The term is introduced in 5.1.4 but not sufficiently explained. Is this term unique to the guidelines or has it been used elsewhere? If former is the case, need to give more explanation about the process of pinning. If latter is the case, need to give reference to a standard that originally introduced this idea.

*** At the end of 5.2 in point 1 there appears a term "chryptographic material" but what it is is not explained anywhere.

*** What is AA indicator? (Found at the bottom of 5.3). Again it is not explained.

*** 5.4 has a lot of forward referencing to sections 6.4.2 and 6.4.3. This hints me that 5.4 is wrongly placed and perhaps should appear somewhere at the end of chapter 6.

*** 6.1.1 introduced "identity signal" by saying "identity signal should be part of primary user interface". This still does not explain what identity signal is.

*** Section 6.2 point 4 uses the term "identity information" is it the same as identity signal. Identity information is not explained. What forms identity information?

*** Section 7.3 starts with "when confronted with multiple modal interactions", then it talkes about miltiple browser windows being opened. Multi modality means a different thing and user response to multiple windows opened lays in the same modality.

*** 7.4 starts with "user agent" whereas 7.4.1 starts with "web user agent". The document has to be checked for consistence in used terminology. Also it may be the case that achronyms introduced earlier in the document are not at all used. In such a case achronyms need not be introduced at all.

*** In 7.4.1 the term security user interface is introduced but does not seem to be explained anywhere.

*** There is no clear (logical) link between use cases, threat analysis and the actual guidelines document. The guideline document merely mentions "the companions" Reading threat analysis and use cases before or after reading the guidelines does not help to get a good picture of which use cases/use case groups were addressed by the guideline document. There is a need for somewhat clear mapping of the use cases to the guidelines. Use cases would then better explain the guidelines.

*** The guideline document does not have any examples/UI examples whatsoever. Although it is understandable that the guidelines don't want to influence implementation in any way, it can be very hard to understand some requirements without any accompanying example being provided. Providing examples would also better address the different approaches that might be taken by the PC and mobile environments and also examples would better bring accessibility into the scope of WSC UI guidelines. Accessibility is mentioned in the use case document but is not articulated in WSC UI guidelines.

*** The current text revolves around requirements. However separating normative text from informative is a hard task partly due to the structure of the document and partly due to the lack of introductory explanatory text preceeding requirements. Without examples, introductions and clear link to supported use cases this document is hard to read for its prime audience: UI and user experience experts.
Thank you for your excellent review.

We are looking at additional information on AJAX, if it is covered by current best practices, which is the target of this specification, under ISSUE-225
<http://www.w3.org/2006/WSC/track/issues/225>
We have also augmented our security considerations section on this topic
<http://www.w3.org/2006/WSC/track/actions/579>

Current best practice is not consistent on the topic of pop ups if several web pages are visible.

We extensively discussed mobile in the working group. References to smart phones and minimal chrome modes reflect the results of those discussions.

We have fixed the SSLv3 reference.

AA is only the root since it is vouching for everything it controls. See discussion at
<http://www.w3.org/2008/05/13-wsc-minutes.html#item11>

6.4.3 The MUST scopes the need for the user to interact with the message in the case of verifiable danger. Additional text attempts to make this clear
<http://www.w3.org/2006/WSC/track/actions/573>

We now have a list of terms in the document
<http://www.w3.org/2006/WSC/track/actions/576>

4.2.1 comment - we will make that more consistent
<http://www.w3.org/2006/WSC/track/actions/577>

We have cleaned up AA and AAC terminology
<http://www.w3.org/2006/WSC/track/actions/578>

5.1.2 cleaned up
<http://www.w3.org/2006/WSC/track/actions/580>

We have clarified "pinning"
<http://www.w3.org/2006/WSC/track/actions/581>

5.2 - have clarified
<http://www.w3.org/2006/WSC/track/actions/584>

We will clarify "identity signal"
<http://www.w3.org/2006/WSC/track/actions/586>

We will clarify 6.2
<http://www.w3.org/2006/WSC/track/actions/587>

We will clarify 7.3
<http://www.w3.org/2006/WSC/track/actions/588>

We will clarify "user agent"
<http://www.w3.org/2006/WSC/track/actions/589>

7.4.1 will be clarified
<http://www.w3.org/2006/WSC/track/actions/590>

We are clarifying the relationship between our documents.
<http://www.w3.org/2006/WSC/track/issues/226>

The implementation reports during CR will reference existing browser behavior which will provide examples of current best practice.
tocheck
LC-2255 Adam Barth <w3c@adambarth.com> (archived comment)
Comments below.

> Web user agents MUST prevent web content from obscuring, hiding, or disabling security user interfaces.

This is impossible in a multi-window web user agent in an overlapping
window manager (e.g., every major browser on every major
general-purpose operating system).

> Web user agents MUST NOT allow web content to open new windows with the browser's security UI hidden.

This precludes innovative solutions to the full-screen video problem,
like Flash's disabling of the keyboard to prevent password theft.

> Web user agents MUST prevent web content from overlaying chrome. User interactions that are perceived to deal with browser chrome must not be detectable for Web content.

This is generally not the case for keyboard user interactions. In
typical user agents, keyboard events are sent to the content area
before being processed by browser chrome.

> Web user agents MUST NOT expose programming interfaces which permit installation of software without a user intervention.

What does it mean to install software?

> Web user agents MUST inform the user and request consent when web content attempts to install software outside of the browser environment.

Why can't the user agent simply ignore these attempts?

> Web user agents MAY inform the user when web content attempts to execute software outside of the agent environment.

What is the agent environment? For example, does follow a mailto link
fall under this requirement given that seems to execute the user's
default mail software outside the user agents environment

> Web user agents MUST NOT expose programmatic interfaces that allow bookmarking without explicit user consent.

Should the user agent not expose the API without consent, or should
the API not allow bookmarking without consent?

> Web user agents MUST NOT expose programmatic interfaces that allow bookmarking an URL that does not match the URL of the page that the user currently interacts with.

Why not?

On a more general note, what do you mean by expose a programmatic
interface? Does that cover browser extension APIs? Those are
certainly programatic interfaces exposed by the user agent. Pushing
in another direction, what if the user agent exposed that
functionality via an HTML tag. Would that be a *programmatic*
interface?

> Web user agents which offer this restriction SHOULD offer a way to extend permission to individual trusted sites. Failing to do so encourages users who desire the functionality on certain sites to disable the feature universally.

What if the user agent doesn't expose a user interface to disable the
feature universally?

Adam


On Thu, Sep 17, 2009 at 11:06 AM, Arthur Barstow <art.barstow@nokia.com> wrote:
> The title of the spec is actually "Web Security Context: User Interface
> Guidelines":
>
>  http://www.w3.org/TR/wsc-ui/#robustness-api
>
> On Sep 17, 2009, at 1:57 PM, Barstow Art (Nokia-CIC/Boston) wrote:
>
>> All,
>>
>> The Web Security Context Working Group asked WebApps to review
>> Section 7.4 of their Web Security Context Working Group spec:
>>
>>  <http://www.w3.org/TR/wsc-ui/#robustness-apis>
>>
>> If you have any comments, please send to the following list by
>> September 24 at the latest:
>>
>>  public-usable-authentication@w3.org
>>
>> -Regards, Art Barstow
>>
>>
>>
>
>
>
Thank you for your review.

We're not talking about pop ups in the context of "MUST prevent web content from obscuring, hiding, or disabling security user interfaces."

Innovative full screen solutions are covered in the interaction between section 6.1.1 and section 7.1. Section 7.1 says the user agent cannot open windows without security chrome, however section 6.1.1 specifically allows for this when going into "presentation mode". The Flash behavior described falls into this category.

The wording on "overlaying chrome" was confusing, as you were explaining the exact cause for that text. We've attempted to make it clearer.

Installing software means downloading it for later execution.

The requirement to notify the user is if the user agent is going to do the install and not just ignore the attempt.

Since the third paragraph of 7.4.2 ("attempts to execute software outside of the agent environment") was (only) a MAY, and causing some confusion, we have removed it.

The user consent is required for the action of bookmarking, not the browser making the APIs available.

User agents often include features that enable Web content to update the user's bookmark file, e.g. through a JavaScript API. If permitted unchecked, these features can serve to confuse users by, e.g., placing a bookmark that goes by the same name as the user's bank, but points to an attacker's site.

We are changing 7.4.3 to:
> User agents often include features that enable Web content to update
> the user's bookmark file, e.g. through a JavaScript API. If
> permitted unchecked, these features can serve to confuse users by,
> e.g., placing a bookmark that goes by the same name as the user's
> bank, but points to an attacker's site.
>
> Web user agents MUST NOT permit Web content to add bookmarks without
> explicit user consent.
>
> Web user agents MUST NOT permit Web content to add URIs to the
> user's bookmark collection that do not match the URI of the page
> that the user currently interacts with.
>


Browser vendor experience indicates that if the user agent provides annoying seemingly useless dialogs and do not provide the user with a way to disable them universally, users switch to another browser.
tocheck
LC-2256 Anne van Kesteren <annevk@opera.com> (archived comment)
"user agent" -- The draft uses the term "user agent" for conformance
levels and uses the term "web user agent" elsewhere. For the kind of
requirements the draft makes most other specifications simply use "user
agent". It would be nice if the draft could align with that. In case the
deviation is found necessary for some reason it should be consistently
used. In section 7.4 the term "browser" is also sometimes used. Is that
intentional?

"web page" -- The definition of Web page seems to include that it cannot
be embedded so I wonder what "top-level Web page" in section 4 means. If
this document is indeed aimed at browser vendors (and it sure seems like
it) it might be good to align terminology with HTML5. For what you want
here the term "top-level browsing context" would be appropriate. Unlike
"web page" that term is also defined in a lot more detail so that there
can be no doubt as to what is meant.

"must not" -- the last paragraph of 7.4.1 has a lowercase must not. I
assume this is supposed to be uppercase.

"chrome" -- technically scrollbars and such are also part of this, but
should probably be excluded for most purposes here since positioning
something over an element with a scrollbar is fine.

I also wonder the excessive use of MUST is warranted given that a lot of
these things are user interface constraints that might not be applicable
everywhere.
Thank you for your review.

We consistently use "user agent" now.

We're staying with the "web page" definition we have, since it's what we all understand.

actually the "must not" in the last paragraph of 7.4.1. was not conformance language; it has been reworked.

"Chrome" refers to both primary and secondary UI; we've attempted to make the clearer.

We've reviewed the MUSTs (and all the recommendations) carefully and think they're sane. Want to change any in particular, and if so, why?
tocheck
LC-2257 Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived comment)
The term "chrome" seems undefined, in the document it seems to be implicitly equivalent to the user interface.
FYI: The View Modes specification [1] (currently approaching FPWD) tries to define what chrome is, mentions scrollbars etc.

4.2.1
The term "widget" is used. In order not to confuse a potential reader (aka W3C Widgets), I suggest to change "widget" to "control" or "UI component".

7.2
Could the document mention the Widget User Agent as well?
[2] defines the "mini" mode that is without chrome.

6.3
Widgets related:
[3] could be used to define some indicator specifying who/how the widget was signed.

7.4.2
What if the installation-related security aspects are controlled by the underlying security policy?
[4], specifically its section 3.2.3 is just FYI.

7.4.1
FYI:
"Web user agents MUST prevent web content from overlaying chrome. User interactions that are perceived to deal with browser chrome must not be detectable for Web content."
is important for [5] and [6].

[1] http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html#chrome
[2] http://dev.w3.org/2006/waf/widgets-vm/vm-mediafeature.src.html#mini
[3] http://www.w3.org/TR/widgets-digsig/
[4] http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_v1_01.pdf
[5] http://bondi.omtp.org/1.01/apis/ui.html
[6] http://www.w3.org/2009/dap/

________________________________________

Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Thank you for your review.

"chrome" is primary and secondary UI; we've attempted to make that clearer, by stating that explicitly.

"widget" is a term used in user interface terminology, which is why we are using it.

Without a specific proposal, we were unsure what to mention about the Widget User Agent.

A widget signing indicator is beyond the scope of this version of the spec. But thank you for pointing that out.

Thank you for the fyi on BONDI and the pointer to DAP.
tocheck

Developed and maintained by Dominique Hazaël-Massieux (dom@w3.org).
$Id: index.html,v 1.1 2017/08/11 06:44:32 dom Exp $
Please send bug reports and request for enhancements to w3t-sys.org