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.