- Page Info Summary
- This recommendation is made in support of the following workgroup goals:
The WSC WG exists in part as a response to the recognition that there is a broad spectrum of security context information available to web user agents, and that that information needs to be presented in a meaningful way to users at various levels of sophistication. While much of this context information can be handled in a user-passive way (refusing to load pages with mixed SSL/non-SSL content, for instance) it seems worthwhile to consider a recommendation around creating a user-requested "security and privacy summary" for users who want to further investigate their context.
This is not an attempt to solve security problems with dialog boxes, which are well established as being ignored by task-focused users. Rather, it is an attempt to standardize the information that is available to users who are skeptical or curious about the sites they are visiting.
This recommendation is considered applicable to all web user agents. Whatever modalities and presentation techniques are available for web page display can, in principle, be used for page info summary as well.
Requirement | Good Practice
User agents MUST provide a user-accessible information source (e.g. a dialog window) with a name like "Page Info" or "Identity & Privacy Information."
- User agents SHOULD make this information source accessible from primary chrome, though the information itself needn't be presented there.
- This information source MUST include:
- Relevant site identity information, including:
- Domain name
- Owner name, if supplied in a verified form (e.g. the O= field of an EV SSL certificate)
- Verifying authority for above if supplied
- Relevant history/context information, including (to the extent that such information is available to the user agent):
- Whether the user has visited this site in the past
- Whether the user has any saved credentials for this site
- Encryption information, when present, including:
- Whether the site is encrypted to prevent eavesdropping.
- If encrypted, a mechanism for inspecting the certificate used.
- Relevant site identity information, including:
- This information source MAY include:
- How server name was resolved - DNS, DNSSEC, or local HOST file
- Additional encryption information, including:
- Whether there are any problems with the certificate's validity or applicability (e.g. Domain mismatches, Expired certificates, etc.)
- Whether the page mixes https and http content
- TLS version, cipher/algorithm, and key length
- Certificate Authority type - self-signed, trusted root, EV root, or unknown
- Certificate status - expiration, revocation, signature (repeat for each cert in the chain)
The most straightforward technique for implementation of this recommendation in most user agents is as a secondary information dialog box. The conforming implementation described in the Examples section represents one possible approach.
This recommendation relies extensively on available security information as detailed in section 7 of the note. In particular, information:
Firefox 2, like most other browsers, currently provides security info through a multiple-tab Page Info dialog. The information currently supplied is extremely sparse, and limited to TLS layer information (e.g. "This web site is encrypted using AES-256. Click here to view the certificate.") The current implementation would not be deemed compliant with this recommendation.
The current builds of Firefox 3 now include a much richer security summary which would be deemed compliant with this recommendation.
Since the role of this recommendation is to provide supplemental information about a site, it will be particularly implicated in use cases where the site in question is either novel, or of an uncertain identity. This makes it particularly relevant to use cases #2-6, 8, 9 and especially cases like #18, where a user is actively seeking elaboration about a site's identity and her history with it.
Attack resistance and limitations
This recommendation does not introduce any active measures of attack resistance, however it does provide a method for users to protect themselves from luring and impersonation attacks, to the extent that they proactively consider the need to do so.
Because of its reliance on available security information (see Dependencies) it is implicitly bound by the limitations on each of those pieces of information. Indications of host name, for instance, are vulnerable to DNS spoofing. As another example, indications of identity tracking are limited by the browser's ability to detect such activity.
Expected User behavior
This recommendation relies explicitly on deliberate user action. The expectation is that, if the recommendation is implemented with sufficient visibility and if an appropriate affordance is made available, users will consult the page info summary when they are interested to learn more about the site with which they are interacting.
This recommendation describes a user-initiated interaction, and does not recommend the introduction of any disruption agent-initiated disruption to the user's browsing behaviour. To the extent that users discover and make use of this information source, it might more accurately be thought of as part of their browsing behaviour, rather than a disruption thereto.