Conformance details

For each of the conformance clauses of the specification, the Implementation report will list one of the six (colorful) phrases below. Additional notes may also be included. Only the conformance clauses are listed below; the full descriptions around each of the clauses may be found in wsc-ui.

Conforms Basic
(conforms to a MUST or MUST NOT)

Does Not Conform Basic

Conforms Advanced
(conforms to a SHOULD or SHOULD NOT)

Does Not Conform Advanced

Conforms Optional
(conforms to a
MAY)

Does Not Conform Optional

Conformance Claim

See wsc-ui Conformance section for details

  1. User agent  Google Chrome, Version 5
  2. Basic or Advanced?   Advanced?
  3. Strong TLS algorithms: yes
  4. TLS versions and algorithms supported but not "strong": none
  5. Practices for deeming a trust anchor augmented assurance: WebTrust EV audit, in accordance with CA/B Forum EV guidelines
  6. Features beyond conformance level conformed with

Implementation Report Details

Feature lettering maps features to table rows in Implementation Report roll up. Please also complete your column in that table.

5 Applying TLS to the Web

5.1 Certificate Handling and Information

5.1.2 Augmented Assurance Certificates

I. Implementations MUST NOT enable users to designate trust roots as augmented assurance qualified as part of a different interaction.

Conforms Basic

II. To derive a human-readable subject name from an augmented assurance certificate, user agents MUST use the Subject field's Organization (O) attribute.

Conforms Basic

III. If the certificate's Subject field does not have an Organization attribute, then user agents MUST NOT consider the certificate as an augmented assurance certificate, even if it chains up to an augmented assurance qualified trust root (5.1.2 Augmented Assurance Certificates).

Does Not Conform Basic (will probably show something like [US] if the C= field is present. Although, as such a cert is not supposed to be issued, I don't really care to make changes here.)

IV. User agents MAY consider such a certificate as an ordinary validated certificate.

Conforms Optional

5.1.4 Self-signed Certificates and Untrusted Root Certificates

V. User agents MAY support [Definition: pinning] a self-signed certificate or more generally a certificate chain that leads to an untrusted root certificate to a particular Web site, to enable behavior based on recorded state about certificates shown previously by the same site.

Does Not Conform Optional

VI. The interaction that enables users to pin a certificate to a destination SHOULD NOT cause a self-signed certificate to be pinned to more than one site, identified through URI scheme, domain, and port.

Conforms Advanced

VII. The interaction MUST NOT cause an untrusted root certificate to be accepted automatically for additional sites.

Conforms Basic

5.2 Types of TLS

VIII. At the point of writing of this document, versions of SSL prior to SSLv3 [SSLv3] MUST NOT be considered strong.

 

Conforms Basic - we don't support these cipher suites at all

 

IX. At the time of writing of this document, the "export" cipher suites explicitly forbidden in appendix A.5 of [TLSv11] MUST NOT be considered strong.

 

Conforms Basic

5.3 Mixed Content

X. Any UI indicator used to signal the presence of Augmented Assurance certificates MUST NOT signal the presence of such a certificate, unless the page is TLS-secured, i.e., all parts of the page are loaded from servers presenting at least a validated certificate, over strongly TLS-protected interactions.

Conforms Basic

5.4 Error conditions

5.4.1 TLS errors

XI. If multiple error conditions apply, the most severe signaling level currently known MUST be used, as defined in 6.4 Error handling and signaling.

Conforms Basic

XII. Error signaling of class warning or higher (6.4.2 Warning/Caution Messages , 6.4.3 Danger Messages) MUST be used to signal the error condition.

 

Conforms Basic

 

XIII. User agents MAY offer a possibility to pin newly encountered certificates to the destination at hand.

Does Not Conform Optional

XIV. When certificate information is presented in the interactions described in this section, then human-readable information from certificates MUST NOT be presented as trustworthy unless it is attested to. e.g., a self-signed certificate's Common Name or Organization attribute MUST NOT be displayed, even if that certificate is pinned to a destination.

Conforms Basic

XV. User agents MAY display this information in a dialog or other secondary user interfaces reachable from the warning or error messages specified here.

Conforms Optional

XVI. When, during TLS negotiation, the end-entity certificate presented or one of the intermediate certificates in the certificate chain are found to have been revoked, error signaling of class danger (6.4.3 Danger Messages) MUST be used.

Conforms Basic

XVII. When, during TLS negotiation, the end-entity certificate presented or one of the intermediate certificates in the certificate chain are found to have expired, error signaling of class danger (6.4.3 Danger Messages) MUST be used.

Conforms Basic

XVIII. When the URL corresponding to the transaction at hand does not match the end-entity certificate presented, and a validated certificate is used, then error signaling of level danger (6.4.3 Danger Messages) MUST be used.

Conforms Basic

XIX. If TLS negotiation otherwise fails, error signaling of level danger (6.4.3 Danger Messages) MUST be used.

Conforms Basic

XX. When TLS error conditions occur, user agents MAY choose to abort the connection without any further user interaction.

Conforms Optional

5.4.2 Error Conditions based on Third Party or Heuristic Information

XXI. User agents that use third party services or heuristic approaches to assess the possible danger of a pending Web transaction MUST use error signaling of class danger (6.4.3 Danger Messages) to signal positively identified dangers, e.g., identified malicious downloads or exploits of user agent vulnerabilities.

Conforms Basic

XXII. To signal risks that are identified with high likelihood, but involve further user decisions (e.g., phishing heuristics were triggered), error signaling of class warning or above (6.4.2 Warning/Caution Messages , 6.4.3 Danger Messages) MUST be used.

Conforms Basic

5.4.3 Redirection chains

XXIII. User agents SHOULD inform users, using an error of class Warning or higher (6.4.2 Warning/Caution Messages , 6.4.3 Danger Messages), when navigation between TLS-secured pages involves redirects which travel over weakly TLS-protected, or unsecured HTTP channels.

Does Not Conform Advanced

5.4.4 Insecure form submission

XXIV. User agents MAY warn users, using an error of class Warning or higher (6.4.2 Warning/Caution Messages , 6.4.3 Danger Messages), if form submissions from a TLS-secured page are directed to an unsecured channel.

Does Not Conform Optional

6 Indicators and Interactions

6.1 Identity and Trust Anchor Signaling

6.1.1 Identity Signal What is our identity signal? Is it the lock? Then in this case, we don't show the issuer of the cert, we have the absence of the indicator to indicate the lack of any identity information. If it's the "page info" then it's not available in primary chrome, etc. If it's the EV indicator, we only show it when there is EV information to show.

XXV. User agents MUST make information about the identity of the Web site that a user interacts with available.

Conforms Basic

XXVI. This [Definition: identity signal ] SHOULD be part of primary user interface during usage modes which entail the presence of signaling to the user beyond only presenting page content.

Conforms Advanced

XXVII. Otherwise, it MUST at least be available through secondary user interface.

Conforms Basic

XXVIII. If the identity signal is available, it MUST be part of primary user interface when any identity sources that are from unauthenticated or untrusted sources are (also) part of the primary user interface.

Conforms Basic

XXIX. User interactions to access this identity signal MUST be consistent across all Web interactions facilitated by the user agent, including interactions during which the user agent has no trustworthy information about the identity of the Web site that a user interacts with.

Does Not Conform Basic - what does this mean though? If our identity signal is something that shows up and displays the O= field of an EV cert when there is an EV cert, and is not present otherwise, does that mean that the way the user accesses this signal is consistent because they don't have to do anything, the signal just appears when there's relevant information?

XXX. In this case, user agents MUST indicate that no information is available.

Does Not Conform Basic - again, if there's no info we indicate that by not having any green text to the right of the lock.

XXXI. User agents with a visual user interface that make the identity signal available in primary user interface SHOULD do so in a consistent visual position.

Conforms Advanced - it's always to the right of the lock when anything is to be shown.

XXXII. Web Content MUST not obscure security user interface, 7.4.1 Obscuring or disabling Security User Interfaces.

Conforms Basic

6.1.2 Identity Signal Content

XXXIII. Information displayed in the identity signal MUST be derived from validated certificates, or from user agent state.

Conforms Basic

XXXIV. Web user agents MUST NOT use information as part of the identity signal that is taken from unauthenticated or untrusted sources.

Conforms Basic

XXXV. The identity signal MUST include human-readable information about the certificate subject, derived as specified in 5.1.2 Augmented Assurance Certificates, to inform the user about the owner of the Web page.

Conforms Basic

XXXVI. If the identity signal does not include any other human readable information about the identity of the certificate subject (derived, e.g., from an augmented assurance certificate), then it MUST include an applicable DNS name that matches either the subject's Common Name attribute or its subjectAltName extension.

Conforms Basic - our "identity signal" is our indication for EV. If there's no EV, we don't display anything to the right of the lock. We do provide this extended information in "Page Info" which you would get by clicking on the lock. Don't know what that means w.r.t. the spec.

XXXVII. User agents MAY shorten such a DNS name by displaying only a suffix.

Conforms Optional - we may abbreviate in page info dialog.

XXXVIII. The identity signal MUST include the Issuer field's Organization attribute to inform the user about the party responsible for that information.

Does Not Conform Basic - We don't put this in the URL bar for our EV indicator. It's available in the "page info" dialog someone would get from clicking on the lock. We don't feel this is meaningful to users and so not something we put in primary chrome.

XXXIX. Subject logotypes derived from certificates MUST NOT be rendered, unless the certificate used is an augmented assurance certificate.

Conforms Basic

XL. During interactions with a mixed content Web page, the identity signal MUST NOT include any site identity information exceeding those in use for unprotected HTTP transactions.

Conforms Basic

XLI. In this situation, the identity signal MAY include indicators that point out any error conditions that occurred.

Conforms Optional

XLII. During interactions with mixed content, user agents MUST NOT render any logotypes derived from certificates.

Conforms Basic

6.2 Additional Security Context Information

XLIII. Web user agents MUST provide additional security context information as described in this section.

Conforms Basic redundant with items below

XLIV. Where security context information is provided in both primary and secondary interface, the presentation and meaning of the presented information MUST be consistent.

Conforms Basic

The information sources MUST make the following security context information available:

the Web page's domain name

Conforms Basic

Owner information, consistent with 6.1.2 Identity Signal Content

Conforms Basic

Verifier information, consistent with 6.1.2 Identity Signal Content

Conforms Basic

The reason why the displayed information is trusted (or not). This includes whether or not a certificate was accepted interactively, whether a self-signed certificate was used, and whether the self-signed certificate was pinned to the site that the user interacts with, and whether trust relevant settings of the user agent were otherwise overridden through user action.

Conforms Basic - if a certificate was "accepted interactively", e.g. the user clicked through a warning, we still don't say it's "trusted"

The information sources SHOULD make the following security context information available:

What protection level is represented by the TLS indicator; ??? No idea what this means

Conforms Advanced

 

If the Web page is weakly TLS-protected, then, what conditions cause the protection to be weak (e.g., bad algorithms, mixed content, ...)

Conforms Advanced

Whether the user has visited the site in the past.

Conforms Advanced

Whether the user has stored credentials for this site.

Does Not Conform Advanced - don't indicate whether the user has stored credentials

 

Whether the site content was encrypted in transmission.

Conforms Advanced

Whether the site content was authenticated (e.g., server authentication via TLS).

Conforms Advanced

 

Additionally, the information sources MAY make the following security context information available:

When the user most recently visited the site in the past.

Does Not Conform Optional

LVI.  When the user first visited the site in the past.

 

Conforms Optional

 

LVII. How often the user visited the site in the past.

 

Does Not Conform Optional

LVIII. User agents that provide information about the presence or absence of Cookies [RFC2965] MUST NOT make any claims that suggest that the absence of cookies implies an absence of any user tracking, as there are numerous tracking and session management techniques that do not rely on Cookies.

Conforms Basic

6.3 TLS indicator - for Chrome I think this is the lock icon

LIX. User agents MUST make information about the state of TLS protection available.

Conforms Basic

LX. The [Definition: TLS indicator] SHOULD be part of primary user interface during usage modes which entail the presence of signaling to the user beyond only presenting page content.

Conforms Advanced

LXI. Otherwise, it MUST at least be available through secondary user interface.

Conforms Basic

LXII. Web content MUST not obscure security interface, 7.4.1 Obscuring or disabling Security User Interfaces.

Conforms Basic

LXIII. User interactions to access the TLS indicator MUST be consistent across all Web interactions.

Conforms Basic

LXIV. In this case, user agents SHOULD indicate the interaction was not TLS protected.

Conforms Advanced - if it's plain HTTP then we don't show a lock

LXV. User agents with a visual user interface that make the TLS indicator available in primary user interface SHOULD do so in a consistent visual position.

Conforms Advanced

LXVI. The TLS indicator MUST present a distinct state that is used only for TLS-secured Web pages.

Conforms Basic

LXVII. The User Agent SHOULD inform users when they are viewing a page that, along with all dependent resources, was retrieved through at least weakly TLS protected transactions, including mixed content.

Conforms Advanced

LXVIII. The user agent MAY accomplish this by using a third state in the TLS indicator, or via another mechanism (such as a dialog, infobar, or other means).

Conforms Optional

6.4 Error handling and signaling

LXIX User agents MAY communicate additional indicators to users. E.g., a user agent could additionally display a persistent indicator in a "danger" situation.

 

Does Not Conform Optional

6.4.1 Common Error Interaction Requirements

LXX. Error signaling that occurs as part of primary user interface SHOULD be phrased in terms of threat to user's interests, not technical occurrence.

Conforms Advanced

LXXI. Primary user interface error messages MUST NOT be phrased solely in terms of art.

Conforms Basic

LXXII. They SHOULD NOT refer the user to enter the destination site that caused the error, e.g., to provide feedback or obtain assistance.

Conforms Advanced

LXXIII. For error messages that interrupt the user's flow of interaction, user agents SHOULD enable the user to easily return to the user agent state prior to initiation of the last user interaction that led to the error signal.

Conforms Advanced

LXXIV. For advanced users, error interactions SHOULD have an option for advanced users to request a detailed description of the condition that caused the interaction to occur.

??? No idea what this means. If I tell you there's a certificate mismatch error, and tell you what was presented and what was expected in the initial error message, what additional options and detailed descriptions are you expecting?

6.4.2 Warning/Caution Messages

LXXV. Warning / Caution messages MUST be used when the system has good reason to believe that the user may be at risk based on the current security context information, but a determination cannot positively be made.

Conforms Basic but we are thinking of making changes for expired certs

LXXVI. These warnings SHOULD be used if the likelihood of danger is present, but cannot be confirmed. ??? what does this mean. This is not spec language. What is the likelihood of danger for an expired cert?

Conforms Advanced

LXXVII. Warning / Caution messages MUST interrupt the user's current task, such that the user must acknowledge the message.

Conforms Basic

 

LXXVIII. Warning / Caution messages MUST provide the user with distinct options how to proceed (i.e., these messages MUST NOT lead to a situation in which the only option presented to the user is to dismiss the warning and continue).

Conforms Basic - for a revoked cert, we do not allow the user to proceed to the site, only to go back. There are not "distinct options" there is exactly one option.

LXXIX. The options presented on these warnings MUST be descriptive to the point that their meanings can be understood in the absence of any other information contained in the warning interaction.

Conforms Basic

LXXX. One of the options offered SHOULD be recommended, and the warning message SHOULD include a succinct text component denoting which option is recommended.

Conforms Advanced

LXXXI. In the absence of a recommended option, the warning MUST present the user with a method of finding out more information (e.g., a hyperlink, secondary window, etc) if the options cannot be understood.

Conforms Basic

6.4.3 Danger Messages

LXXXII. Danger Messages MUST be used when there is a positively identified danger to the user (i.e., not merely a risk).

Conforms Basic

LXXXIII. The interactions communicating these messages MUST be designed such that the user's task is interrupted.

Conforms Basic

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

Conforms Basic

7 Robustness Best Practices

7.1 Keep Security Chrome Visible

LXXXV. For visual user agents, agent chrome SHOULD always be present to signal security context information.

Conforms Advanced We offer Full Screen mode, where we hide this. So does Firefox.

7.2 Do not mix content and security indicators

LXXXVI. Web User Agents MUST NOT communicate trust information using user interface elements which can be mimicked within chrome under the control of web content.

Conforms Basic

LXXXVII. Site-controlled content (e.g. page title, favicon) MAY be hosted in chrome,

Conforms Optional

LXXXVIII. but this content MUST NOT be displayed in a manner that confuses hosted content and chrome indicators, by allowing that content to mimic chrome indicators in a position close to them.

Conforms Basic

LXXXIX. In particular, Web User Agents SHOULD NOT use a 16x16 image in chrome to indicate security status if doing so would allow the favorite icon to mimic it.

Conforms Advanced

7.3 Managing User Attention

XC. User interfaces used to inform users about security critical events or to solicit comment MUST employ techniques that prevent immediate dismissal of the user interface,

Conforms Basic - I don't think "security critical" is defined in the spec. I define it for Chrome as going past a malware warning, where we make you check a box that you agree you are about to do a bad thing.

XCI. When users interact with security relevant notifications (6.4.2 Warning/Caution Messages and above), interactions caused by Web content MUST NOT be granted control of the user agent's interaction.

Conforms Basic

XCII. A Web User Agent SHOULD NOT display a modal security dialog related to a web page which does not currently have focus.

Conforms Advanced

7.4 APIs Exposed To Web Content

7.4.1 Obscuring or disabling Security User Interfaces

XCIII. Web user agents MUST prevent web content from obscuring, hiding, or disabling user interfaces that display security context information, except in response to a user interaction..

Conforms Basic

XCIV. User agents MUST restrict window sizing and moving operations consistent with 7.1 Keep Security Chrome Visible. This prevents attacks wherein agent chrome is obscured by moving it off the edges of the visible screen.

Conforms Basic

XCV. User agents MUST NOT allow web content to open new windows with the agent's security UI hidden. Allowing this operation facilitates picture-in-picture attacks, where artificial chrome (usually indicating a positive security state) is supplied by the web content in place of the hidden UI.

Conforms Basic

XCVI. User agents MUST prevent web content from overlaying chrome. This helps to ensure that user interactions that are perceived to target agent chrome are not redirected to Web applications.

Conforms Basic

7.4.2 Software Installation

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

Conforms Basic

XCVIII. User agents MUST inform the user and request consent when the user agent is attempting to install software outside of the agent environment as a result of web content.

Conforms Basic

XCIX. The interaction used MUST follow the requirements in 6.4.2 Warning/Caution Messages .

Conforms Basic

C. User agents SHOULD NOT provide features which can be used by web content to install software outside of the agent environment without the user's consent.

Conforms Advanced

CI. User agents MAY provide mechanisms for users to pre-consent to a class of software installations.

Does Not Conform Optional

CII. User agents SHOULD inform the user when web content is installing software outside of the agent environment that is covered by a pre-consent.

Conforms Advanced

7.4.3 Bookmarking APIs

CIII. Web user agents MUST NOT permit Web content to add bookmarks without explicit user consent.

Conforms Basic

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

Conforms Basic

7.4.4 Pop-up Window APIs

CV. With visual user interfaces that use a windowed interaction paradigm, User agents SHOULD restrict the opening of pop-up windows from web content, particularly those not initiated by user action.

Conforms Advanced

CVI. User agents which offer this restriction SHOULD offer a way to extend permission to individual trusted sites.

Conforms Advanced