• Firefox 3.0 Conformance with June LC

This is a cut and paste of the rewrite.xml from June 10, 2008, with normative language called out, and the FF3 conformance statement below each. These statements are based on the soon-to-be-released Firefox 3.0. --JN

5 Applying TLS to the Web

5.1.2 Augmented Assurance Certificates

Web user agents MUST establish that a trust anchor is [Definition:

• AA-qualified ] through some out of band mechanism consistent with the relevant underlying augmented assurance specification.

Mozilla (and hence Firefox 3) establishes that trust anchors are AA-qualified through out of band mechanisms described in our certificate policy, here: http://www.mozilla.org/projects/security/certs/policy/ . This policy requires audits of AA-qualified issuers to ensure their practices are consistent with the underlying specification (CABForum's EV Guidelines).

Implementations MUST NOT enable users to designate trust roots as AA-qualified as part of

• a different interaction. Implementations MAY make user interfaces available for the purpose of designating AA-qualified trust roots. Such user interfaces MUST be focused on this specific task. In particular, the notions of an AA-qualified trust root and an interactively accepted trust root are mutually exclusive.

Firefox 3 does not enable users to designate trust roots as AA-qualified.

To derive a human-readable subject name from an AAC, user agents MUST use the Subject

• field's Organization (O) attribute.

Firefox 3 uses the Subject field's O attribute to derive a human readable subject name from AACs.

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 AA-qualified trust root. User agents MAY consider such a certificate as an ordinary validated certificate.

Firefox 3 only accepts EV certificates as AACs, which are required by definition to have a subject Organization attribute. Trivially conformant.

• When the logotype information is derived from an augmented assurance certificate, then the
  • subject logotype MUST be rendered, if present.

Firefox 3 does not derive logotype information from certificates. Trivially conformant.

• Otherwise, when the logotype information is derived from a validated certificate, then the issuer logotype MUST be
  • rendered, if present.

Firefox 3 does not derive logotype information from certificates. Trivially conformant.

• The rendering of audio logotypes SHOULD be limited to a short amount of time, and clearly separate from any rendering of other security context information. In particular, user agents MAY shorten audio logotypes for playback. When a user agent will both display visual logotype information as well as emit/play audio logotype information, the user agent MUST ensure that the display/play of these two forms are time-synchronized so that the start times of their display/play coincides visibly and audibly.

Firefox 3 does not derive audio logotype information from certificates. Trivially conformant.

Web 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. Such behavior includes, e.g., warning users about changes of certificates, and not showing warning messages if a site shows a certificate consistent with previous visits.

Firefox 3's security exception mechanism does allow explicit pinning interactions after warning, but not implicit pinning after multiple visits. Since this is a MAY requirement, I don't believe the distinction impacts conformance.

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. The interaction MUST NOT cause an untrusted root certificate to be accepted automatically for additional sites. A pinned self-signed certificate SHOULD be considered sufficient identification to allow user agents to associate a petname with the site, if supported.

Explicit pinning does not cause a certificate to be pinned to more than one site, identified through scheme, domain, and port. The interaction does not cause an untrusted root certificate to be accepted. Firefox 3 does not support petnames.

If a client is able to automatically accept a self-signed certificate, or recover from similar problem without user interaction, it MUST NOT do so unless the client also have a history mechanism about security information.

Firefox 3 is not able to automatically accept a self-signed certificate.

5.1.6 Petnames

• For TLS-secured pages, the user MAY assign the authenticated entity a [Definition: petname]. If the web page uses a validated certificate, this assignment MUST create a binding from the petname to each of the host identifiers the certificate is valid for. These identifiers are found in the CN attribute and the subjectAltNames attribute, as specified in [RFC2818]. If the Web page uses a pinned self-signed certificate or certificate chain, this assignment MUST create a binding from the petname to the pinned destination only. It MUST NOT create a binding from the petname to any other destination.

Firefox 3 does not support petnames.

• To discover the petname that corresponds to the entity that is authenticated through a validated certificate, user agents MUST use identifiers from the certificate only. In particular, when the certificate includes domain name wildcards, then the same petname will be associated to all sites that present a validated certificate which includes the same wildcard.

Firefox 3 does not support petnames.

• Presentation of a petname MUST support renaming and deleting of a petname binding.

Firefox 3 does not support petnames.

• When the user assigns a petname, the petname presentation implementation MUST warn the user if the chosen petname is similar to one currently in use. The meaning of similar is up to the implementation, but MUST at least include an identical petname.

Firefox 3 does not support petnames.

• A web user agent that supports petnames MUST also support a presentation of bookmarks that presents the association between each bookmark and the petname of the hosting site. If the hosting site could be assigned a petname, but the user has not yet done so, the presentation MUST present those bookmarks as being associated with a distinct, but not yet petnamed site. If the hosting site cannot be assigned a petname, because the hosting site does not support the previously established constraints for assignment of a petname, the presentation MUST indicate so. This bookmark presentation MUST support assignment, renaming and deletion of petnames.

Firefox 3 does not support petnames.

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 an AA certificate.

Based on the resolution of ISSUE-200, this text should read:

A 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 protected TLS connections.

Firefox 3 does not display an AA indicator unless all elements are loaded from servers presenting a validated certificate, over strongly protected TLS connections.

5.4.1 TLS errors

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

Firefox 3 will apply to most severe signalling level applicable in a given situation.

• When, for a TLS-protected HTTP connection, the certificate chain presented by the server does not lead to a trusted root certificate, and the certificate chain presented was not pinned to the destination at hand, the following applies to user agents that are capable of storing and using information about certificates that were previously encountered:

1. If a validated certificate (including an
   • augmented assurance certificate) was previously presented by the same destination, then error signalling of class danger (6.4.4 Danger Messages) MUST be used.
2. If a different certificate was previously pinned to the same destination, then error
   • signalling of class warning or above (6.4.3
     • Warning/Caution Messages
     , 6.4.4 Danger Messages) MUST be used. User agents MAY offer the possibility to pin the newly encountered certificate to the destination at hand.
3. Otherwise, user agents MAY use error signalling of class notification (6.4.2
   • Notifications and Status Indicators
   • ) to offer pinning a given certificate, consistent with 5.1.5 Self-signed Certificates and Untrusted Root Certificates.
4. Otherwise, user agents SHOULD use error signalling of class warning or above (6.4.3
   • Warning/Caution Messages
   • , 6.4.4 Danger Messages).

The above section does not apply, since Firefox 3 is not capable of using information about previously encountered certificates. Instead, the section below applies.

• In the same circumstances, the following applies to user agents that are not capable of using information about previously encountered certificates.

1. Error signalling of class warning or above (6.4.3
   • Warning/Caution Messages
   • , 6.4.4 Danger Messages) MUST be used to signal the error condition.
2. User agents MAY offer a possibility to encounter newly encountered certificates to
   • the destination at hand.

Firefox 3 will signal this situation using a Warning-style message, including complete interruption of user task flow, and no way to dismiss the warning without deliberate interaction with it. That interaction can include adding a security exception, which is an explicit form of pinning interaction.

• User agents SHOULD store the state of certificates that were previously encountered. (specifically, whether or not a site previously presented a validated certificate). Historical TLS information stored for the purposes of evaluating security relevant changes of behavior MAY be expunged from the user agent on the same schedule as other browsing history information. Historical TLS information MUST NOT be expunged prior to other browsing history information. For purposes of this requirement, browsing history information includes visit logs, bookmarks, and information stored in a user agent cache. When certificate information is presented in these interactions, human-readable information derived from the certificates (e.g., Common Name or Organization attributes) in question MUST NOT be presented as trustworthy.

Firefox 3 does not remember the state of certificates previously encountered in the generic way described here.

• When certificate information is presented in these interactions,

• web user agents MUST NOT display identity information from a self signed or untrusted certificate in a warning or error message. Web user agents MAY display this information in a dialog or other secondary chrome reachable through the warning or error message or dialog.

Certificates explicitly trusted by the user for use on a particular domain are identified as "You have added a security exception for this site." Information from the certificate about ostensible subject or issuer identity is not displayed except in the certificate viewer tool.

• When, for a TLS-protected HTTP connection, the certificate presented is found to have been revoked, error signalling of class danger (6.4.4 Danger Messages) MUST be used.

Firefox 3 treats revoked certificates as a non-bypassable hard stop.

• When, for a TLS-protected HTTP connection, the certificate presented is found to have been expired, error signalling of class danger (6.4.4 Danger Messages) MUST be used.

Firefox 3 treats expired certificates as a full stop compatible with the definition for danger level messages. The user task flow is interrupted and the message cannot be bypassed without explicit interaction.

• When certificate status checks are attempted, but where the check fails, (i.e. does not produce an answer as to certificate status), due to network errors or related error conditions, the following applies:

1. If a certificate check was successfully performed before, or if an Augmented
   • Assurance Certificate is used, then error signalling of level danger (6.4.4 Danger Messages) MUST be used.
2. Otherwise, error signalling of level warning (6.4.3
   • Warning/Caution Messages
   • ) SHOULD be used.

I believe this section is slated to be removed, per ISSUE-201. Firefox 3 would not be conformant to this text as worded.

• When the URL corresponding to the transaction at hand does not match the certificate presented, and a validated certificate is used, then error signalling of level danger(6.4.4 Danger Messages) MUST be used.

Firefox 3 treats domain name mismatch of this type as a full stop, interrupting the user task flow, and requiring explicit interactions to override.

• If TLS negotiation otherwise fails, error signalling of level danger (6.4.4 Danger Messages) MUST be used.

Firefox 3 treats other TLS failures as hard stops, with no bypass possible.

5.4.2 Error Conditions based on Third Party or Heuristic Information

• User agents that use third party services or heuristic approaches to assess the possible danger of a pending Web transaction MUST use error signalling of class danger (6.4.4 Danger Messages) to signal positively identified dangers, e.g., identified malicious downloads or exploits of user agent vulnerabilities. To signal risks that are identified with high likelihood, but involve further user decisions (e.g., phishing heuristics were triggered), error signalling of class warning or above (6.4.3
  • Warning/Caution Messages
  , 6.4.4 Danger Messages) MUST be used.

Firefox 3 employs 3rd party services for malware/phishing protection, and uses Danger class signalling when a reported attack site is encountered.

5.4.3 Redirection chains

Web user agents MUST signal an error of class warning or above (6.4.3

• Warning/Caution Messages

• , 6.4.4 Danger Messages) when a user interaction with a TLS-secured page causes dereferencing of a URL that leads to a

• chain of Web transactions that:

• does not involve user interactions, and,
• involves weakly TLS-protected or unprotected HTTP
  • transactions.

Firefox 3 warns during these interactions.

Note that this applies whether or not the resource in which the non-interactive chain of

• redirections terminates is TLS protected in any manner. In particular, even if the retrieval of the final resource in the chain of redirections is strongly TLS protected, clients MUST signal an error. Also note that this section is not limited to HTTP level redirection mechanisms; it also covers redirections that are caused by scripting or HTML constructs.

This section is confusing since it suggests that we are signalling an error, not a warning as mentioned above. It's also not clear how to interpret this text in light of things like image transfers which, if they occurred over unprotected connections would be cause for mixed mode treatment, but not warnings or errors. I can't declare conformance here at the moment, given these confusions.

This section does not apply to situations in which, e.g., an HTML form is served by way of

• a strongly TLS protected transaction, but the user's input is submitted through plain HTTP.

This is surprising and not something I've noticed before. Firefox 3 warns in this instance.

6.1.1 Identity Signal

This section is normative. Examples are informational.

Web user agents MUST make information about the identity of the Web site that a user

• interacts with available. This [Definition: identity signal ] SHOULD be part of primary user interface during usage modes which entail the presence of signalling to the user beyond only presenting page content. Otherwise, it MUST at least be available through secondary user interface. Note that there may be usage modes during which this requirement does not apply: For example, a Web browser which is interactively switched into a presentation mode that does not display any chrome need not preserve security indicators in primary user interface. On the other hand, a user agent such as a smart phone, air plane seatback or TV set which has a usage mode that makes minimal (but visible) chrome elements available does need to preserve security indicators in such a mode.

Firefox 3 makes information about the identity of the web site available via the site identity button in primary chrome, and the page info dialog in secondary chrome.

• If a positive form of identity is available, the identity signal 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. These sources include URLs.

Firefox 3 includes positive identity, if available, as part of primary user interface.

User interactions to access this identity

• signal MUST be consistent across all Web interactions facilitated by the user agent, including interactions during which the Web user agent has no trustworthy information about the identity of the Web site that a user interacts with. In this case, user agents MUST indicate that no information is available.

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. Web Content MUST not obscure security chrome, ???.

Firefox 3's "Site Identity Button" is available in all identity conditions, including interactions where no trustworthy information is available. The interaction is always the same.

6.1.2 Identity Signal Content

Information displayed in the identity

• signal MUST be derived from validated certificates, or from user agent state. Web user agents MUST NOT use information as part of the identity signal that is taken from unauthenticated or untrusted sources.

Firefox 3 derives identity information from validated certificates and user agent state only.

During interactions with a TLS-secured Web page for which a petname has been defined, the identity signal MUST include that petname.

Firefox 3 does not support petnames.

During interactions with a TLS-secured Web

• page for which the top-level resource has been retrieved through a strongly TLS-protected interaction that involves an augmented assurance certificate, the following applies:

• • 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, unless a petname is displayed.

Firefox 3's "Site Identity Button" displays the human readable information about the certificate subject in this situation.

• • For Web user agents that use a visual user interface capable of displaying
    • bitmap graphics the identity signal MAY include display of a suitable logotype, selected according to the rules in 5.1.4 Logotype Certificates.

Firefox 3 does not support logotype display.

• • Web user agents that use sound to communicate with the user MAY render an audio
    • logotype that is embedded in the certificate using the logotype extension, according to the requirements in 5.1.4 Logotype Certificates.

Firefox 3 does not support audio logotypes.

During interactions with a TLS-secured Web

• page for which the top-level resource has been retrieved through a strongly TLS-protected interaction that involves an validated certificate (including an augmented assurance certificate), the following applies:

• • 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 or a petname), then it MUST include an applicable DNS name retrieved from the subject's Common Name attribute or from a subjectAltName extension.

Firefox 3 displays an applicable DNS name for validated or AA certificates as part of the identity signal retrivable via the site identity button.

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

Firefox 3's identity information includes the Issuer field's Organization attribute.

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

Firefox 3 does not support logotypes.

During interactions with a mixed content Web

• page, the identity signal MUST NOT include any positive indicators exceeding those in use for unprotected HTTP transactions. In this situation, the identity signal MAY include indicators that point out any error conditions that occurred.

Firefox 3 does not present verified identity information on mixed content interactions.

During interactions with mixed content, Web user agents MUST NOT render any logotypes

• derived from certificates.

Firefox 3 does not support logotypes.

6.2 Additional Security Context Information

This section is normative.

Web user agents MUST provide additional security context

• information as described in this section through one or more user-accessible information sources. These information sources can be implemented in either primary or secondary user interface. Where security context information is provided in both primary and secondary chrome, the presentation and semantics of the presented information MUST be consistent.

Firefox 3 presents this information through the site identity button and page info dialog. The mechanisms for this interaction are always and consistently available.

The information sources MUST make the following security context

• information available:

1. the Web page's domain name
2. Owner information, consistent with 6.1.2 Identity Signal Content
3. Verifier information, consistent with 6.1.2 Identity Signal Content
4. The reason why the identity 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.

Firefox 3 presents this information in the identity signal, obtainable by clicking the "Site Identity Button" in primary chrome.

The information sources SHOULD make the following security context

• information available:

1. Whether a Web page is TLS-protected, whether the protection is
   • weak or strong, and the reasons for the value of the protection.

Available via Page Info dialog.

1. When the Web page is TLS-protected and a validated
   • certificate was used, whether or not a certificate status check has been performed.
2. If a certificate status check has been performed, what
   • the result was.

Only available implicitly since failed checks will result in danger messages.

1. Whether the user has visited the site in the past.

Available via Page Info dialog.

1. Whether the user has shown
   • credentials to this site.

Not available

1. Whether the user has stored credentials for this
   • site.

Available via Page Info dialog.

1. Whether the site content was encrypted in transmission.

Available via Page Info dialog.

1. Whether the site content was authenticated.

Available via Page Info dialog.

1. Logotypes embedded in certificates used, consistent with
   • 6.1.1 Identity Signal and 5.1.4 Logotype Certificates.

Firefox 3 does not support logotype display.

Additionally, the information sources MAY make the following security

• context information available:

1. When the user most recently visited the site in the
   • past.
2. When the user first visited the site in the past.
3. How often the user visited the site in the past.

Available through the history management UI, but not as part of security interactions.

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.

Firefox 3 makes no claims of this sort.

6.3 TLS indicator

Web user agents MUST make information about the state of TLS protection available. The

• [Definition: TLS indicator] SHOULD be part of primary user interface during usage modes which entail the presence of signalling to the user beyond only presenting page content. Otherwise, it MUST at least be available through secondary user interface. As in the case of 6.1.1 Identity Signal, there may be usage modes during which this requirement does not apply. Web content MUST not obscure security chrome, ???.

Firefox 3's site identity button presents information about the TLS protection available both textually and via the button colouring.

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

• interactions. This includes when TLS has not been used to protect those interactions. In this case, web user agents SHOULD indicate the interaction was not TLS protected. 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.

Firefox uses consistent presentation and visual position across all web interactions.

The TLS indicator MUST present a distinct state that is used only for TLS-secured Web pages. 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.

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

Firefox employs distinct states for TLS-secured and unsecured pages. Mixed content is treated as unidentified for the purposes of the Site Identity Button, however the Page Info dialog will present information about mixed content status.

6.4 Error handling and signalling

• This section defines common error interaction requirements and, ordered by increasing severity, practices to signal the following classes of errors:

• 6.4.2
  • Notifications and Status Indicators
• 6.4.3
  • Warning/Caution Messages
• 6.4.4 Danger Messages

6.4.1 Common Error Interaction Requirements

• Error signalling that occurs as part of primary chrome SHOULD be phrased in terms of threat to user's interests, not technical occurrence.

This feels pretty open to interpretation and difficult to make a binary conformance claim, but we certainly aspire to it.

• Primary chrome error messages MUST NOT be phrased solely in terms of art, e.g., jargon. They SHOULD NOT refer the user to enter the destination site that caused the error, e.g., to provide feedback or obtain assistance. 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.

Again, difficult to make a binary call. Firefox 3 does not phrase errors solely in terms of art, and does attempt to explain the impact of the error, and the potential remedies. For example, our page presented on unpinned self-signed certificates reads, in part:

- This could be a problem with the server's configuration, or it could be someone trying to impersonate the server. - If you have connected to this server successfully in the past, the error may be temporary, and you can try again later.

Firefox 3 does enable to user to return to the state prior to the initiation of the error.

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

Firefox 3 includes an error code to facilitate lookup of technical details.

6.4.2

• Notifications and Status Indicators Notifications and status indicators are used when the browser cannot accurately determine a security risk based on the current security context information available. These indicators SHOULD also be used for situations in which the risk level may vary based on user preference. For visual user agents, notifications and status indicators MUST be displayed in the user agent's persistent primary chrome. These indicators MAY include user interaction (e.g., forcing the user to click a button to continue the primary task). They MUST include a succinct textual description of their meaning.

Firefox 3 status indicators like the Site Identity Button are always available. Warning/Error messages are all presented in primary chrome.

6.4.3

• Warning/Caution Messages 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. These warnings SHOULD be used if the likelihood of danger is present, but cannot be confirmed. Warning / Caution messages MUST interrupt the user's current task, such that the user must acknowledge the message. For user agents with a visual user interface, headings of these warnings MUST include words meaning "caution" or "warning". The headings of these warnings MUST be the locus of attention. 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). 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. These warnings SHOULD include one recommended option, and a succinct text component denoting which option is recommended. 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.

Firefox 3 uses warning messages to interrupt user task flow. These messages use "caution" styling - yellow warning icons, etc. The heading of these warnings is the locus of attention. The warnings do not present only the option to continue.

6.4.4 Danger Messages

• Danger Messages MUST be used when there is a positively identified danger to the user (i.e., not merely a risk). The interactions communicating these messages MUST be designed such that the user's task is interrupted.

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

Firefox 3 presents danger messages to warn of positively identified danger. These messages interrupt the task flow by blocking page load and filling the content area of the browser. They can only be dismissed by interacting with them.

6.5 Chrome Reconfiguration

• If a Web User Agent permits the user to administratively reconfigure

the primary user interface in such a way as to suppress any of the displays required by this specification, then it MUST provide a simple administrative mechanism, such as a single button in a configuration menu, to reset the display to be in conformance with this specification.

Firefox 3 allows users to reconfigure chrome. Firefox 3 provides a single button in a configuration dialog that restores the default toolset (UI).

7.1.1 Use Shared Secrets to Establish a Trusted Path

• Web user agents that proactively present security context information to the user (or a channel presumed to eventually lead to the user, such as accessibility aides) MAY accept some presentation information from the user, and associate that information with parts of the user interface that are intended or commonly used to communicate trust information to users.

Firefox 3 does not support the selection of a shared secret as a distinct security-related action, though obviously things like theming support can have this effect, for users that choose to employ them.

7.1.2 Keep Security Chrome Visible

• For visual user agents, browser chrome SHOULD always be present to signal security context information. This requirement does not apply when UI is explicitly dismissed by the user.

Firefox 3's "Site Identity Button" is always available in primary chrome.

• This requirement is scoped to a specific interaction: When multiple Web pages might be displayed, security critical chrome MAY be not present for those with which the user is not currently interacting. However, chrome used to communicate security context information that relates to the currently interacted Web page MUST always remain on the screen.

As anticipated, Firefox 3's "Site Identity Button" is scoped to the currently displayed tab in each window.

7.2 Do not mix content and security indicators

• Web User Agents MUST NOT communicate trust information using user interface elements which can be mimicked within chrome under the control of web content. Site-controlled content (e.g. page title, favicon) MAY be hosted in chrome, but this content MUST NOT be displayed in a manner that confuses hosted content and chrome indicators. This requirement applies to both primary and
  • secondary elements of visual user interfaces.

Firefox 3 does not use chrome to signal trust information in a way that would be mimicked by site controlled content.

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

Firefox 3 does not use a 16x16 image in chrome to indicate security status in such a way as would allow the favicon to mimic it.

7.3 Managing User Attention

• 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, e.g., by using a temporarily disabled "OK" button on user interfaces that make such an interaction paradigm available. When users interact with security relevant notifications (6.4.3
  • Warning/Caution Messages
  • and above), interactions caused by Web content MUST NOT be granted
  control of the user agent's interaction.

Firefox 3 employs disabled OK buttons to prevent immediate dismissal of installation prompts. Firefox 3 employs multi-step, non-immediate UI to pin certificate exceptions. Firefox 3 does not grant web content control of the user agent's interaction.

7.4.1 Obscuring or disabling Security User Interfaces

Web user agents MUST

• prevent web content from obscuring, hiding, or disabling security user interfaces.

Firefox 3 prevents web content from obscuring, hiding, or disabling security user interfaces, including the identity signal and page info summary.

Web user agents MUST restrict window sizing and

• moving operations consistent with 7.1.2 Keep Security Chrome Visible. This prevents attacks wherein browser chrome is obscured by moving it off the edges of the visible screen.

Firefox 3 prevents window sizing and moving operations that would serve to obscure chrome off the visible screen.

Web user agents MUST NOT allow web content to open new windows

• with the browser'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.

Firefox 3 does not allow web content to open new windows with security UI hidden.

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.

With the exception of favicon and page title, which are hosted in chrome and not the target of this requirement, Firefox 3 prevents web content from overlaying chrome.

7.4.2 Software Installation

Web user agents MUST

• NOT expose programming interfaces which permit installation of software, or execution of privileged code without a user intervention.

Firefox 3 does not expose programming interfaces which permit installation of software or execution of privileged code without user intervention.

Web user agents MUST inform the user and request consent when

• web content attempts to install software outside of the browser environment. The interaction used MUST follow the requirements in 6.4.3
  • Warning/Caution Messages

Firefox 3 requests consent for addon and plugin installs which, while designed to interact with the browser, will have the same privilege as Firefox to interact with the system at large. These warnings follow the requirements of 6.4.3.

• Web user agents SHOULD NOT provide features which can be used by web content to install software outside of the browser environment without the user's consent. Web user agents MAY provide mechanisms for users to pre-consent to a class of software installations. Web user agents SHOULD inform the user when web content is installing software outside of the browser environment that is covered by a pre-consent.

Firefox 3 requests consent for addon and plugin installs which, while designed to interact with the browser, will have the same privilege as Firefox to interact with the system at large. Firefox 3 does not provide a mechanism to pre-consent to software installations.

Web user agents MAY inform the user when web content attempts to execute software

• outside of the agent environment, and MAY also request user consent, but SHOULD NOT do so unconditionally for all types of content or software. If the agent chooses to do this then it SHOULD do so for specific content types, software types, or security context based on risk.

Firefox 3 does not provide mechanisms for web content to directly execute software outside the agent environment. If a downloaded file's content type cannot be displayed internally, Firefox 3 does prompt the user before allowing external programs to open the file.

7.4.3 Bookmarking APIs

Web user agents

• MUST NOT expose programmatic interfaces that allow bookmarking without explicit user consent. That consent MUST follow the requirements from 6.4.2
  • Notifications and Status Indicators

Firefox 3 does not expose programmatic interfaces that allow bookmarking.

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.

Firefox 3 does not expose programmatic interfaces that allow bookmarking.

7.4.4 Pop-up Window APIs

• With visual user interfaces that use a windowed interaction paradigm, Web user agents SHOULD restrict the opening of pop-up windows from web content, particularly those not initiated by user action. Creating excessive numbers of new popup windows is a technique that can be used to condition users to rapidly dismissing dialogs. This can be employed in interaction flooding attacks.

Firefox 3 does restrict the opening of pop-up windows from web content that are not initiated by user action.

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

Firefox 3 does allow a way to extend permission to individual trusted sites.