List of comments on “Web Security Context: User Interface Guidelines” (dated 26 February 2009)

Quick access to

There are 4 comments (sorted by their types, and the section they are about).

substantive comments

Comment LC-2199
Commenter: <Anna.Zhuang@nokia.com> (archived message)
Context: in
Not assigned
Resolution status:

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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2255
Commenter: Adam Barth <w3c@adambarth.com> (archived message)
Context: in
Not assigned
Resolution status:

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*

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


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
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

editorial comments

Comment LC-2256
Commenter: Anne van Kesteren <annevk@opera.com> (archived message)
Context: in
Not assigned
Resolution status:

"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

"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
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Comment LC-2257
Commenter: Marcin Hanclik <Marcin.Hanclik@access-company.com> (archived message)
Context: in
Not assigned
Resolution status:

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.

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

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

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

What if the installation-related security aspects are controlled by the underlying security policy?
[4], specifically its section 3.2.3 is just 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


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.
(space separated ids)
(Please make sure the resolution is adapted for public consumption)

Add a comment.

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