The padlock is such a regularly referenced instance of poor security signalling that it is now almost always referred to as "the much-maligned padlock." Most of the angst surrounding it has to do with the fact that it mixes signals - it is really a signal about the presence of SSL/TLS encryption, but it has been cross-purposed to serve as a signal for safety.

As a result, attempts have been made to layer richness onto it, like Opera's multi-level padlock, or IE's Padlock + Green Bar. While these measures are obviously attempts to clean things up, the continued reliance on the padlock (an understandable approach, given it's long history with users) results in continued muddiness.

Critically, the padlock is also a cue which relies on people to notice its absence. Identity information should always be available to the user, even if the information we have is "No identity can be verified." In the case of the padlock, non-ssl/tls sites present no UI, and hence no contextual cue (except absence), and no affordance for users seeking to verify information or allay their fears that they are on an imposter site.

This recommendation requires that user agents create an always-available indicator in primary UI which is concerned only with identity. This indicator should be independent from indicators of encryption status and should not try to indicate "safety," only identity. On sites which supply identity credentials (e.g. through SSL/TLS, but the decision of which credentials are "worthy" might be UA-dependent) this indicator should supply information about the site's identity (owner, address?) and the identity of the verifier (e.g. "Identity verified by VeriSign").

Applicability (*)

This recommendation applies to all web user agents capable of supporting the relevant site-identity technologies (e.g. EV SSL Certificates).

Requirement (*) | Good Practice (*)

Techniques (*)

The most obvious technology to employ in implementing this recommendation is the Extended Validation certificate. Issuing of these certificates requires strong checks of identity, high availability mechanisms for verifying validity and checking revocation, and the use of cryptographically secure protocols for all steps of the verification process. A user agent which displayed the Subject Organization field as the web site owner, the Issuer Organization field as the verifying party, and which otherwise adhered to the presentation criteria outlined above would be conforming to this recommendation.

At time of writing, the workgroup is not aware of this kind of indicator being deployed in a production user agent. IE7's "green bar" implementation does provide supplemental identity information, but only on sites where the green bar is activated (i.e. sites presenting EV certificates.) On sites without this technology there is, to my knowledge, no way of obtaining identity information. This violates the conformance criteria above.

Within the Mozilla community, there has been discussion about introducing this indicator in Firefox 3 using the universal airport symbol for "Passport Check" - an icon of a uniformed person inspecting a passport, since this more closely reflects the intended interpretation. Not safety, just a check of relevant identity documents. This design has not been finalized, and even if it were, the recommendation does not attempt to specify this particular visual presentation, however, it is included here for reference:



This recommendation relies upon the availability of strongly verified identity information. Currently, this is most likely provided by the information outlined in section 7.3 of the note, [javascript:void(0);/*1181666200512*/ Information Provided By SSL].


Because this is an always-on indicator, it is implicitly included in all use cases. In its intended role is to provide site identity information, so it will be particularly implicated in cases where the site in question is either novel, or of an uncertain identity. This makes it particularly relevant as a piece of context in use cases #2-6, 8, 9 and especially cases like #18, where a user is actively seeking information to validate a site's identity.

Attack resistance and limitations

This indicator exists as a direct response to attacks based on subverting a user's trust relationship with a legitimate site by emulating portions of that site, i.e. spoofing. Because the identity information it requires is strongly validated and presented prominently, spoofing risk is mitigated through the user's ability to inspect the site's identity information.

This indicator is limited by the quality of the information on which it relies. If a weak identity technology is employed, or a vulnerability is discovered in a previously-strong identity technology, attackers could co-opt the identity indicator and display misleading information. While the indicator's always-available behaviour helps reduce the risk of chrome spoofing, it does not eliminate it. Attackers could place look-alike indicators within their page content which might deceive some users.

Usability effect

Expected User behavior

The expectation is that by establishing a consistent method for checking identity information, users who are curious about, or unsure of, the identity of sites they interact with will tend to check with this indicator as a form of user-driven investigation. It is also anticipated that, for implementations which comply with the best practices recommendations around putting this indicator in primary chrome, the at-a-glance ability to check identity will become part of users' passive mental security context.


The indicator does not require material disruption of user browsing habits, except insofar as it may change state to reflect new identity information, which can serve as a visual distraction. To the extent that this calls attention to the identity of the site in question, this is appropriate, but the recommendation does not propose more "active" forms of workflow disruption (e.g. modal pop ups indicating identity status.)