1 Overview
TOEDIT: Web user agents are now used to engage in a great variety and number of commercial and personal activities. Though the medium for these activities has changed, the potential for fraud has not. This Working Group is chartered to recommend user interfaces that help users make trust decisions on the Web.
This first Working Group document elaborates upon the group's charter to explain what the group aims to achieve, what technologies may be used and how proposals will be evaluated. This elaboration is limited to the group's technical work and does not cover additional activities the group intends to engage in, such as ongoing outreach and education.
2 Conformance
2.1 Site-Identifying Images in Chrome
2.1.2 Overview
The most common currently deployed mechanism to associate identifying images with Web Sites is the favorite icon (FAVICON). Favorite icons are commonly displayed in browser location bars, alongside bookmarks, or in other parts of graphical user interfaces. The association of a particular bitmap with a particular site is controlled by the site's content. This section includes requirements for the display of site identifying icons designed to help separate site-controlled content from trust indicators.
2.1.3 Applicability
This requirement is applicable to Web User Agents that are capable of displaying bitmap graphics, and use a visual viewport to communicate trust information to users.
2.1.4 Requirement
2.1.5 Techniques
The following Techniques are necessary, but not sufficient, to fulfill the requirement:
Web User Agents MUST NOT display favorite icons [FAVICON] within the visual context of a Location Bar widget, if present.
Web User Agents MUST NOT display favorite icons in secondary user interface intended to enable users' trust decisions.
The following Technique is sufficient to fulfill the requirement:
Web User Agents MUST ignore favorite icon [FAVICON] references that are part of Web content.
2.1.6 Examples
2.1.6.1 Conforming Product
A conforming product could be a Web User Agent that uses the favorite icon to identify individual tabs in a tabbed browser interface, or to identify bookmarks, but does not display favorite icons in its location bar.
2.1.6.2 Non-conforming Product
A common UI metaphor in recent generations of common Web browsers is to include trust indicators (the padlock, and color coding) in the Location Bar widget that is part of typical primary browser user interfaces. Typically, the padlock is displayed toward the right border of the location bar. The Location Bar is therefor an area of the user interface that is commonly used to communicate trust information. Browsers that display a favorite icon near the left border of the Location Bar are an example for a non-complying implementation.
A Web Browser that displays a favorite icon in a dialog box in which certificate properties are presented for inspection when a user handles a TLS error condition.
2.1.7 Background
A web browser address bar may display a logo retrieved from a location specified in the web site's content, or discovered in a well known location, known as a favicon. In either case, the choice to display a logo, and what image to use, is at the discretion of the visited web site. In some browsers the favicon logo is also displayed in Bookmarks/Favorites lists and associated toolbar buttons, as well as window titles, tab titles, and elsewhere. Whether consciously or unconsciously, many users are beginning to view favicon logos as security context information. Specifically, they feel that seeing the logo they expected for a particular site is somehow an assurance the site is genuine. @@@ NEEDS REFERENCE @@@ Because the logo appears in browser chrome rather than the HTML page, it creates an impression that the logo is more "official". This is a mistake on the users' part because no central organization controls or approves the assignment of favicons to sites, and no technical security measures are required to ensure the authenticity of a favorite icon. A malicious entity can steal the exact logo used by a legitimate site (or create a visually indistinguishable logo) and associate it with a different site for impersonation purposes.
Favicons undermine the web security context display in several ways:
They appear to provide security context but in reality do not.
They blur the distinction between chrome and content.
They enable attackers to place trust indicators (such as the familiar padlock) in areas of browser chrome that are commonly used for trust display, creating a significant risk of user confusion.
2.2 Security Protocol Error Presentation
2.2.2 Overview
Web agents regularly encounter error conditions at the protocol layers (HTTP, SSL/TLS, X.509, etc.) that alter the risk profile and security context of a particular resource. Due to the highly technical nature of these errors (often related to cryptographic issues) the details are generally useful only to sys admins, web developers, security professionals, or the most technical end users. For the majority of web users the technical details actually lead to confusion and risky behavior. For most users the overall security context should be adjusted intuitively while hiding the details of the error condition.
2.2.2.1 Anti-Patterns
A number of security anti-patterns are observed today in the presentation of security protocol errors:
Technical jargon is used including terms unknown to the averge user. Examples include "certificate", "SHA hash", "root authority", etc.
User is asked to choose from among two or more possible actions without any explanation provided of the risks or consequences.
Agent gives the user advice that is not actionable.
User told to contact the site for help but only contact info given for the site is the URL or domain that the user is already attempting to access.
2.2.2.2 Recommendations
Web agents should follow these recommendations when presenting security protocol errors:
Allow technical user to access details of the error in a secondary user interface (UI) but hide them in the primary UI.
Primary UI security context indictors should reflect the error without displaying details.
Confine technical jargon to the secondary UI.
When user is asked to make a decision, explain the risks of each option presented.
Do not refer the user to the destination URL or domain for assistance.
2.2.3 Dependencies
This recommendation relies on security information primarily provided through the SSL (TLS) protocol. However it also incorporates information obtained from HTTP, DNS, and web agent.
2.2.4 Use Cases
This recommendation addresses all the WSC use cases because they all have unhappy paths that can be triggered by an error in the protocol layers.
2.2.5 Expected User Behavior
Detailed test cases for expected user behavior could be developed by identifying every combination of a protocol error and a use case. For example, What if use case 1 is disrupted by a revoked SSL certificate? In that case the expected user behavior is for Alice to cancel her entry to the bank's web site.
Absent such exhaustive analysis, at a high level we can say the expected user behavior in all error cases is to proceed or not proceed to access the offending web resource with an appropriate understanding that an error condition was encountered that indicates an increased level of risk.
2.2.6 Disruption
The status quo handling of security protocol errors includes several undesirable agent behaviors (see Anti Patterns). These disrupt the web browsing experience for many users and render it confusing or unsafe. The causes of such disruptions include:
Users ignore incomprehensible errors and enter unwittingly enter risky areas.
Users become desensitized to all security error messages.
Users pick among actions presented without understanding risk consequences.
Users forced to enter a suspect site just to contact the site administrator for help.
2.3 Safe Browsing Mode
2.3.2 Overview
Safe Web Browsing Mode (SBM) refers to a state that a browser can be placed in, where when in that mode, the user has both a real and perceived sense of security with respect to his/her knowledge that they can only be communicating and exchanging information with trusted websites and not a spoof. This is because when in SBM, the browser will only permit user-selected, highly trusted websites to be accessed. A highly trusted website is a website that can be certified as such. These are websites that have gone to some lengths to allow being reliably identified as authentic and trusted (have met the necessary technical requirements, as well as contractual requirements that include a rigorous certification and compliance process).
One way to achieve this would be to require the website to belong to a community (e.g. FI, healthcare, government) that is willing to work with the EV CAB Forum, and the EV certificate issuers, to put in place a process that would allow a website to apply for an EV Cert with a Community logo type. To obtain this logo, the community authority must strongly certify those of its members who have agreed to meet special technical, contractual, audit and compliance requirements, and to put its website through a rigorous certification process.
Upon certification by this community, the website would be issued an EV certificate, with a community-type logo added to their EV certificate. The website should agree to digitally sign and bind its url and IP addresses, to allow their web page’s authenticity to be verified, and to allow themselves to be audited, to accept certain liabilities required by that community.
The user should also be able to include in Safe Mode, any website that has met the technical requirements to be reliably authenticated and that the user knows sufficiently well, that they do not require a certifying community type logo. An example of this would be a user, who is an employee of Corporation X, who wishes to be able to access his company’s website under SBM.
This mode, SBM, is intended for the user who wishes to be sure that they are at the intended known, trusted website before they exchange sensitive information. It addresses the needs of several of the use cases brought up in the WSC working group (see Use cases below).
The Safe Browsing Mode needs to be extremely difficult, if not impossible to fool into passing through an “untrusted site”. This is assured by the technical requirements imposed on the website.
The user must take an active step to go into SBM. Initially, this will involve clicking a special control sequence. This mode of interaction is requires the user to know of and take explicit actions up front, and to take an extras step if the user wishes to browse boutside the set of homogeneously certified sites. In return, the user can assume all web sites they go to have a consistent level of trustworthiness, using only the look and feel indicator of SBM. Both “good indicators,” e.g. green bars, locks, that currently are used to indicate the user is at a good website and/or is exchanging information with the website securely); and “bad indicators” (e.g. red alerts that indicate the website is a spoofed or untrustworthy website) are often ignored by many users. Furthermore, the absence of these “indicators” (good or bad) is often over looked by many users. In addition, even poor spoofs of these indicators (indicators painted outside the chrome, or painted over the chrome) can fool enough users to make them not particularly useful. If users are somehow automatically placed into SBM mode without any action on their part, we are back to the same problem we are trying to avoid, which is getting users to recognize something that is “safe” solely on the basis of some kind of visual or other cue.
SBM is ideal for users that want to be careful before they conduct financial and other high risk transactions and information exchanges with a website, and desire higher assurance that they are communicating with the intended site, e.g. their bank. When in SBM mode the browser will only permit user-selected highly trusted websites to be accessed. This prevents the user from being able to receive and/or log on to the wrong site, an untrustworthy site.
SBM creates a separation between the space where users conduct sensitive transactions from the space, and where they casually browse the internet. When in SBM mode, the browser will have a distinct look, but the success of SBM is not dependent upon the user actually paying attention to this look.
When in SBM, the browser will be automatically placed in a default highly secure mode, where the browser’s security settings are pre-selected (this is discussed in the related recommendation, Browser lock-down). Many features deemed dangerous will be turned off (e.g. “FSTC BMA Browser Recommendations” in this wiki)
The user can test and verify whether they are in SBM by trying to access a website that is not one of the user’s selected highly trusted” sites.
The user can accept all highly trusted sites, or can start out with an empty personal list and can add additional sites to the list as they are accessed and used, much as one now adds to their web favorite list, provided the site is approved to be accessed while in SBM. The user can also take away sites from being accessed in SBM. Alternatively, the user can choose to enable all the sites approved to be accessed while in SBM.
The goal of SBM mode not to eliminate phishing attacks, but to protect those who are willing to take proactive steps to avoid them. SBM mode will not be required, but will be voluntary.
To make SBM useful, these things must be true:
Users must be in SBM mode before there is any possibility of providing bogus or spoof sites with information.
Users must be aware that they are in SBM (known by their taking a conscious act to put themselves into SBM, and by the distinct look).
Users must understand that only legitimate “ highly trusted” websites will be accessible in SBM, and that any information provided will only be received by the intended site, provided it is "highly trusted" and accessible in SBM.
Users must be able to verify that they are at the intended "website," and that only legitimate "highly trusted websites" are accessible while in SBM.
Although the creation of a SBM mode is vitally important to the Financial Services community where real dollars losses to our customers is at stake, the notion of safe browsing is inherent to many other communities; e.g. e-Bay, Amazon, your health care provider. So SBM should be developed so it can scale up to include any interested community that is willing to enforce compliance with the stringent technical and contractual requirements.
As with privacy, there may ultimately be different degrees of trust (multiple SBM levels, associated with different communities of varying trust, that is related to the strength of the technical and contractual certification process and the relevant rules and policies governing the community with respect to security measures and behavior subscribed to by a participating members). However, to start with, we might keep things simple; either a site is trusted and included in SBM, or not.
The ANEC report calls for a standardization of the means for identifying and filtering content, and this standardization might be extended to include Safe Web Browsing in addition to Privacy and other filtering, such as parental filters (e.g. filtering out pornographic sites).
SBM should be designed to be extensible. The initial operational capability will be built by adapting currently available technologies (e.g. Card Space, EV Certificates with logo type extensions and secure letterhead) as described below. However, SBM should be able to be strengthened over time, by including new, better technology as they get defined and introduced (e.g. a Community CA Bridge similar to the Federal Bridge; DNSSEC; a stronger, more tightly controlled Top Level Domain).
When Higgins, CardSpace, any other such open source equivalent is placed in SBM, by typing in the SBM control sequence, both the client and the website become relying parties in the sense that the website can select only those cards it is willing to accept for user authentication (the rest of the cards are grayed-out), and the client will only allow a card to be sent to a user-selected “highly trusted website, that can be verified as such. If a user tries to view a website that cannot be verified as a selected, highly trusted website, then all the available cards are grayed out and the user cannot attempt a log-on.
When a browser is placed in SBM, by typing in the SBM control sequence, and a user attempts to access a web page, that page will not be delivered unless it can be verified as one of the selected highly trusted websites.
In both cases, verification is done by comparing the digital signature of the websites’ url and IP addresses with that of one of the selected highly trusted websites, where the digital signature would have to use a key associated with an EV certificate, with one of the participating logo types that are willing to stand behind highly trusted websites. Secure letterhead could be used to display the name and logo type of the accessed website.
Other technologies could be added to further strengthen a websites ability to verify their identity. This would include the creation a special trusted top level domain (Tld) which can only be accessed through DNSSEC protocol. This would require DNSSEC to be supported by the browser and/or the customer's ISP.
These measures should enable the web browser and OS to distinguish the website from other websites, no matter how close they look like the real website, even if their web page is a copy of the real web page sent from a spoofed website.
The current approach violates the following usability principles:
10.2.2 Conceptual model
10.2.3 Match between the system and the real world
10.2.4 Habit formation
10.2.5 Single locus of attention
10.2.6 Aesthetic and minimalist design, and in many cases
10.2.11 Consistency
This is because the security is not built into the users intended task, and the security indicators are many, often not related to the concerns of the task at hand, are often complex to understand or relate to the task at hand, and often times are not consistent.
SBM, in contrast, is integrated into the intended task at hand. The task at hand is to allow the user to access a website in a way that ensures that they are at the intended known, trusted website before they exchange sensitive information. SBM allows the user to have this assurance, by adding an additional keystroke before clicking on a link or typing in a url. The act is minimal, and should be consistent across browsers. You want to browse in safe mode, you invoke safe mode, in a similar manner to how you invoke an operating system’s safe mode; and the safe mode directly relates to what the user is doing – trying to access a desired trusted web site and to block any spoofs. It is a relatively easy step to take, and it could become a habit. Enter a special key sequence before one tries to access a highly trusted site.
2.3.3 Applicability
Since SBM should be designed with a specific look and feel, and requires a user to invoke SBM using a pre-set keystroke sequence, an equivalent should be developed for those with a disability that prevents them from either discerning the look and feel, or from invoking the keystroke sequence.
2.3.4 Requirement
An implementation MUST be able to invoke SBM when the user enters the pre-set key stroke sequence.
The implementation, when in SBM, MUST check that a website had digitally signed its url and IP addresses, with a key that is certified by an EV Certificate, with a participating community type logo.
The implementation MUST be able to show the certificate, site name and logo type if requested by the user.
The implementation MUST block from access, when in SBM, any website that does not pass the website checks.
The implementation SHOULD provide a distinct look when in Safe Mode, that is consistent across implementations.
The implementation SHOULD have supporting instructions and information on SBM and how it works.
The implementation SHOULD be capable of being extended to support other technical checks and requirements as they become available, such as DNSSEC, filtering on Tld, supporting Bridge Authorities in addition to EV certificates with logo types.
The implementation MUST be capable of allowing the user, to take an action to get out of SBM. This could be as simple as closing down the browser.
2.3.6 Dependencies
This solution would be dependent upon the following:
7.1 Provided by HTTP
HTTP-Auth handshake [HTTP Auth]
7.2 Provided by web content
Does the content come from multiple domains?
Is the rendered view composed from multiple content sources, such as referenced images or stylesheets
Installed certificate authorities
7.3 Provided by SSL
Was the content transmitted using SSL?
SSL server certificate chain
certificate authority
distinguished name
public key
validity timeframe
extended validation [EV Cert]
Ciphersuite
public key algorithm and key length
symmetric key algorithm and key length
message digest algorithm
CRL [PKIX]
OCSP
7.4 Provided by IP or DNS
server hostname
server IP address
localhost versus intranet versus internet
DNSSEC
7.5 Provided by user agent
installed certificate authorities
default bookmarks
default security configuration
7.6 Provided by user
installed client certificates
installed server certificates
How was the URL entered?
typed into address bar
pasted into address bar
clicked hyperlink
command from another application user's understanding of his task
7.7 Provided by third-party
reputation and accreditation service
2.3.7 Examples
A conforming implementation would be an implementation that invokes SBM when the user enters the pre-set key stroke sequence, and when in SBM checks that the requested website had digitally signed its url and IP addresses, with a key that is certified by an EV Certificate with a participating community type logo, and blocks access to the website if it fails that check, and can show the certificate, site name and logo type if requested by the user.
A non-conforming implementation would be an implementation that does not block access to a requested website that fails the check.
2.3.8 Use Cases
Use Case Scenario 1 - Once a week, Alice pays her bills. She opens her web browser, invokes safe mode, follows the habitual bookmark to her bank's site, logs in by entering her credentials, and follows the routine course through the online banking system.
Use Case Scenario 2 - Once a week, Alice pays her bills. She invokes safe mode, opens her web browser, follows the habitual bookmark to her bank's site, and is directed to an unfamiliar site at a new domain. The unfamiliar site is blocked because it cannot pass the Safe Mode checks. Alice never sees the site announcing that her bank has recently acquired another one and changed names a bit, and asking her to enter her usual credentials.
Use Case Scenario 3 - Once a week, Alice pays her bills. She invokes safe mode, opens her web browser, follows the habitual bookmark to her bank's site. Both the phony message that informs her that, as a countermeasure to recent attacks against online banking customers, she needs to install a piece of proprietary software on her computer, and the download of the software is blocked.
Use Case Scenario 4 - Once a week, Alice pays her bills. She invokes safe mode and opens her web browser, follows the habitual bookmark to her bank's site. A phony download process is blocked.
Use Case Scenario 7 - Frank regularly reads a frequent flyer forum while sipping his first cup of coffee in the morning. He clicks on a link and walks off to the coffee-maker for a refill. Returning, he notes that his computer screen now includes pop-up advertising for a new cheque-management program which is purportedly offered by his bank. A free demonstration version is available for download. Frank, invokes safe mode to access the free demonstration. The advertising is served from an advertising agency's web site, not from the bank's and is therefore blocked.
2.3.9 Attack Resistance and Limitations
The Safe Browser Mode would eliminate all threats except for two cases:
User fails to activate the safe browsing mode and mistakes the spoofed site for the desired site. We believe that if the majority of a community, such as banking, moves to supporting Safe Browsing mode, and educating their consumers accordingly, this type of attack could be greatly minimized. Customers will get used to activating SBM before clicking on a link to a bank site, or typing a bank url, just as customers are trained today protect their ATM card and their PIN.
The PC is taken over by key stroke loggers and Trojans which attempt to take over control of the PC and cause it to follow instructions for taking actions from malicious websites, such as going into SBM mode logging on with users credentials and instructing the bank to transfer funds, pay bills, etc. to fraud accomplices. This attack is out-of-scope in the sense that it needs to be addressed at the OS level. However, it could be minimized by a number of techniques. The most effective would be creating a secure trusted path, between a secure module in the PC (could be a small trusted kernel) and the Trusted Website, which could be accomplished when using the SBM with Card Space authentication; and providing transaction level security safeguards (e.g. securing the transaction instructions, along with use of alerts and required user confirmations).
2.3.10 Expected User Behavior
Over time and through education, it is hoped that more and more users will elect to invoke SBM mode before they bank on-line, or do other high risk transactions where personal information is exchanged and high risk transactions performed. In fact, banks and other “trusted sites” could incent users to only access them on-line via SBM Mode (e.g. provide loyalty points, safety guarantees, fee discounts or higher interest rates).
It should be pointed out that there are already a number of circumstances where browsers, or browser add-ons, already block web sites from being accessed. Two examples are in the case of privacy (where privacy is set to high and the website either does not have a published privacy statement in P3P, or has one that is in conflict with the user's privacy preferences); and the example of a parental filter that blocks sites that are determined to be offensive, such as blocking pornographic sites. The Safe Web Browsing concept would include blocking sites that are not identifiable as well-known, often visited, trusted sites.
2.3.11 Disruptions
Issues/Concerns/Questions:
How is safe-mode substantially different from the "security zone" model employed (and unused) in current browser? Much of what we want is in the security zone model, but we want some additional things: e.g. be able to strongly link a website's IP address(s) to the desired website (e.g. with EV typed certs or DNSSEC or FI- (or other community) certified and signed websites hashed with the valid IP addresses). It is because there are these important bits and pieces already operational that we have hope we could see an implemented safe mode in relatively short order. Furthermore, the current security zone interface, such as in IE7, provide a long list of very technical terms that a user has to select, and it is somewhat cumbersome to change and reset. We would like something much simpler to invoke by the user, which by default eliminates when in safe mode all but the sites that both qualify and are selected by the user, as well as selecting a default security zone setting (most of the technical settings for safe mode are determined for the user, but if the user wishes he/she can see the settings).
Do you believe there are times when users don't want to be safe? Yes, when users want to go to social sites, browse the web, look for interesting content, converse with interesting people, they don't care about safety. On the other hand, there are some sites where the users wants to exchange very sensitive information and wants to be sure that they are on the correct site. In fact, if a user could easily switch back and forth, they would even be safer when they are not in safe mode because they would know they are NOT in safe mode and hopefully be much less trusting and willing to provide sensitive information when not in Safe mode. As a users travels around in the Wild Unsafe Web, they may find and establish a relationship with a web site that they now want to know interact with more safely. If that site is appropriately certified and conforms to the needed technical security, the user can find that site is available for Safe Mode and add it to its Safe Mode list.
Creation of a separation between SBM and normal web browsing, comes at the price of a seamless transition from regular mode to SBM. This would eliminate the option of an FI sending legitimate clickable links to the user by email (although we could keep the links if they are rendered unoperable unless the user goes through a clicking sequence before clicking on the link). Most FI's claim not to do this anyway, so this shouldn't be too big an issue. Forcing the user to launch another application keeps them conscious of what they're doing (the task at hand is a sensitive transaction and they must be knowingly go into the separate mode to complete the task).
There is concern that the business people who manage the consumer Internet channel at major banks will reject these conditions and their bedrock principle of “support all the popular web browsers” which is derived from a need to make online banking convenient and accessible to a very broad population of consumers. Any bank that unilaterally stops supporting today’s IE and Firefox browsers is simply giving away business to its competitors. That is why it is so critical that SBM mode be supported by the browser community and that going into SBM should be voluntary with education and incentives gradually causing a shift in user behavior. But attitudes may be changing. Consider the results of the following recent Javelin study [reference 4].
The distinction between safe browsing mode and regular mode must be absolutely clear to the user. It's been suggested that safe-browsing could take place in another tab or browser window. This solution would not draw a hard enough line between SBM and regular mode. A number of attacks we see now show that users can easily be fooled by windows that have the same look and feel. It's also important to keep in mind attacks like picture-in-picture, which would likely still be successful if SBM was simply another browser window [1,2, 4]. Also, SBM should be careful to present the user with the minimal interface necessary to allow them to conduct their transactions (i.e. a space free of advertisements and other noise on the page). Stripping the safe-browsing mode off all unnecessary information would help reduce the number of things an attacker can exploit, but the introduction of a stripped online banking interface would likely imply an education period. The users would have to be convinced that they are in fact on the correct site and communicating with their bank even though most of the graphics and links they're used to seeing are absent.
2.3.12 References
Dhamija, R., Tygar, J., and Hearst, M. "Why Phishing Works" In Proceedings CHI. (2006)
Jackson, C., Simon, D., Tan, D., and Barth, A. "An Evaluation of Extended Validation and Picture-in-Picture Attacks" In Proceedings Usable Security. (2007)
Shneiderman, B. "Designing the User Interface". [4] Wu, M., Miller, R., and Little, G. "Web Wallet: Preventing Phishing Attacks by Revealing User Intentions" Symposium on Usable Privacy and Security. (2006) RecommendationDisplayProposals/RecoTempl (last edited 2007-06-06 15:58:01 by ThomasRoessler)
Security Before Convenience Say Online Bankers, IDG News Service, by Tash Shifrin, April 5, 2007 [report based on Javelin Strategy and Research Survey by Stephen Knighten - Customers want online ID protection more than reimbursement from banks The majority of Internet users are more concerned with getting identity safeguards for online banking than being reimbursed for losses, according to a US survey conducted by Javelin Strategy and Research and commissioned by Authentify. Over half (58%) of the 2781 respondents surveyed said incurring a financial loss was not their primary concern about Internet banking. Instead loss of personal information and the possibility that fraudsters would commit financial fraud in their name were the two main worries. The research also found that the vast majority of respondents - 90% - are willing to sacrifice convenience for stronger security protection for online banking. Over three quarter (78%) of respondents wanted IDs to be verified using real-time authentication mechanisms in the event of suspicious account activity. Of these, more than 30% selected interactive phone calls or SMS text alerts as their preferred means to monitor transactions. Around eight per cent favoured traditional methods that delay a transaction until further authentication can be obtained by bank staff or written notification. Commenting on the research, Stephen Knighten, a statistical analyst at Javelin, says: "These findings demonstrate that the financial services industry must go beyond zero liability protection and offer more comprehensive identity safeguards to gain the trust of consumers." ]
2.4 Personally Identifiable Information (PII) Editor Bar
2.4.2 Overview
User studies of phishing have commonly found that user agent security indicators go unnoticed by users in both normal use and attack scenarios [Out of sight, out of mind]. In a way, this is as it should be, since in many scenarios, security information is not of great importance and so the user should not be distracted by it. However, in some scenarios, security information is crucial and so an interaction that ensures user awareness of this information is desirable.
Pulling the user's attention away from their primary task is intrusive and little tolerated by users, a phenomena confirmed in user studies [Poor usability of dialog boxes]. To remain effective in the long term, an interaction seeking to bring attention to information outside the user's locus of attention must always be seen as relevant and useful by the user and support habit formation to minimize disruption to the user's work flow.
To achieve this level of context sensitivity, this recommendation proposes a new user-driven interaction for entry of information deemed security critical by the user. This new interaction integrates consumption of relevant security information by the user while facilitating the data entry task and providing a record of the user's trust decisions.
This recommendation is an extension and modification of the form filling feature found in many user agents. The core conceptual change is augmenting the form filler with a record of what web site a stored text string was given to and providing the user with ready and reliable access to this record during a data entry task. The user interface to the form filler should facilitate repetition of a past trust decision, such as re-sending an identifier to a web site it has been sent to in the past, but alert the user when a new trust decision is being made, such as sending an identifier to a web site for the first time.
2.4.2.1 Desktop web browser implementation
To facilitate a more detailed description of the recommendation, this section describes a conforming implementation of a desktop web browser.
The chrome area at the bottom of a desktop web browser, which typically contains a status bar is replaced by a new chrome area which houses the new user interface to the form filler. This new user interface is called the "PII bar". A possible realization is shown below:
At the far left of the PII bar is the "contacts" button. When pressed, this button displays a list of links to each web site the user has sent identifiers to using the PII bar. The hypertext of each hyperlink is a user chosen name for the web site, called a petname. The petname for the currently displayed web site is displayed in the "petname tool" which is the editable text field immediately adjacent to the contacts button. If the user has not assigned a petname to the currently displayed web site, the petname tool displays the string "no history". Immediately adjacent to the petname tool is the "PII editor"; a text field for user entry of PII text strings. The arrow button attached to the PII editor displays a list of all text strings the user has entered into the PII editor, along with an indication of whether or not the text string has previously been sent to the displayed web site. Selecting a string from the list copies it to the editable text field. Pressing the enter key with the keyboard focus in the text field transfers the displayed text string to a corresponding field in the currently displayed web page.
The full functionality of the PII bar is further described in the Use-cases section, using the terminology introduced here. The complete design aims to leverage the following usability principles:
The major elements of this proposal's user interface are borrowed from existing form fillers, or auto-complete text editors, and so should have similar affordance properties.
The intended user model of the PII bar is that of a simple record keeper. The user sends PII text strings to a web site via the PII bar and it remembers this action and displays it in its history. The user acquires this conceptual model by entering text strings and seeing them immediately displayed in the history presentation.
The core of this proposal is the definition of an interaction for the exchange of PII between the user and the user agent. This interaction is designed to be readily repeatable by the user in normal, safe scenarios; while providing interruption points where the user agent can disrupt the user's habits when an action with new consequences is attempted.
A primary aim of the interaction defined by this proposal is directing the user's attention to relevant security information when doing so should impact the user's next action.
Aesthetic and minimalist design
This proposal is focused on communicating trust decision history to the user; enabling the user to readily recognize whether a pending action may have new consequences, or is simply a repetition of a past decision. No other functionality is presented.
Match between system and the real world
This proposal relies upon the security properties of TLS and other protocols, but does not directly expose these technical details to the user, either through jargon, or synonymous icons or color codings. Most status is communicated through the availability of user agent features. Natural language is used when more explanation is required.
Help users recognize, diagnose, and recover from errors
Whenever there is a choice for how the user may proceed, the proposed user interface describes both the situation, the reasonable choices and the criteria for deciding between them in natural language.
This proposal does not rely on any changes to web sites and so works uniformly across SSL-enabled web sites, as they exist today.
2.4.4 Use Cases
Following the categorization of use cases in the Working Group's Note, this proposal addresses use cases where:
Destination site: any
Navigation: any
Intended interaction: submission of sensitive information
Actual interaction: submission of sensitive information
In particular, the proposal addresses use cases: 1,5,8-10. The proposal can be extended to cover additional use cases.
2.4.4.1 Plain Scenario
For the plain scenario, the crucial piece of information Alice needs to proceed safely is confirmation that she is securely connected to the same entity she has given her bank login credentials to in the past. Given this information, Alice knows there are no new trust decisions to be made and so her normal login habits can unfold uninterrupted.
For this scenario, we assume Alice has previously provided her login credentials to her bank using the PII bar. To login anew, she selects her login credentials from the menu provided by her PII bar, rather than typing them in herself. In particular, Alice's normal login ritual is:
Alice positions the keyboard focus in the username text field of the displayed web page, or the web page puts it there automatically on page load.
Alice hits an attention key which moves the keyboard focus to the PII editor.
Alice selects her username by either:
Using the up or down arrow key to select the corresponding text string from the menu of previously provided PII text strings
Typing the corresponding text string until enough characters have been provided for auto-completion
Alice hits the Enter key, causing the PII bar to paste the selected text string into the UI widget that previously had the keyboard focus and return the keyboard focus to that UI widget.
Alice moves the keyboard focus to the password text field, or the web page does that for her.
Alice repeats steps 2 through 4 for her password.
2.4.4.2 Bootstrap Scenario
The above plain scenario assumes Alice has already initialized her PII bar's relationship with her bank. In the bootstrap variation of this scenario, Alice has not yet done this initialization and so the normal login ritual is interrupted in step 2 when Alice hits the attention key. In response, her user agent displays a message indicating the lack of history, such as:
You have not established a relationship with this web site through the PII bar.
You might not be at the right web site. Click here for a list of web sites you have established a relationship with.
If you know you haven't established a relationship with this web site, and you want to do so, click here.
If the user selects the first option, the hyperlink list displayed by the Contacts button is displayed.
If the user selects the second option, the following message is displayed:
SuperCA Inc. claims this web site belongs to "Big Bank Inc.", of Sunnydale, California, USA.
If this identification does not match the one you were expecting, click here to search for the organization you were intending to contact.
If this identification is acceptable for you, enter a name the PII bar will use to refer to this web site: <text field>
If the user selects the first option, the browser navigates to the user's preferred search engine.
If the user selects the second option, the browser searches the database of existing relationships to find any petname similar to the newly chosen one. If any matches are found, the user is notified of the collisions and given the opportunity to instead navigate to the corresponding web site. If no matches are found, the browser updates its database of stored relationships, enables the PII bar and puts the keyboard focus in the PII editor. The login ritual then resumes at step 3.
2.4.4.3 Imposter Attack on Plain Scenario
If Alice has established a relationship with her bank's web site, but not the imposter web site, the login attempt at the imposter site is interrupted at step 2. Instead of proceeding directly to step 3, the browser displays the bootstrap message.
A more advanced attack occurs when Alice has established a relationship with her bank's web site, and another with the imposter web site, under a different pretext. In this case, the login attempt is interrupted at step 6. Alice is unable to select her bank password since the PII editor does not list it as a text string previously submitted to the current web site. The petname tool also displays the name chosen for the imposter site, instead of the one chosen for the bank site. To avoid the attack, Alice must click the Contacts button to navigate to her bank's web site. The PII editor should display a message instructing Alice to do this when she fails to select a previously submitted text string.
If Alice has not established a relationship with either the bank's web site, or the imposter web site, the login attempt at the imposter site is again interrupted at step 2 and the bootstrap scenario unfolds. To avoid the attack, Alice must realize that the presented web site credentials are unacceptable and so instead search for the expected bank web site.
2.4.4.4 Spoofing the PII Bar
Spoofing of the PII bar itself is less of an issue than spoofing of the URL bar, since a spoofed PII bar does not contain the user's PII text strings and so may be recognized as a spoof. Alice's attempt to login using a spoofed PII bar is interrupted in step 6 when she is unable to select her password from the list of previously submitted text strings.
For robustness against spoofing, the PII bar MUST be displayed using a theme customized to the user. The user selects this theme at browser installation time and it remains forever the same. The icon for the Contacts button MUST also be selected by the user at installation time.
The "attention key" need not be implemented as a secure attention key like Window's CTRL-ALT-DEL combination. The keypress is simply one which the browser recognizes as one intended for its consumption, rather than the web page's. It is OK if the web page can spoof the hitting of the attention key; the features described above enable detection of a spoofed PII bar.
2.4.5 Expected User Behavior
2.4.5.1 Understanding of PII Security
A core assumption of this proposal is the expectation that users know what identifiers should be treated as security critical and so be entered using the PII bar. For example, the user must realize that their password or credit card number should be treated with care. To encourage such treatment, the interface is designed such that it is easier to provide information to a web site using the PII bar than it is for the user to enter information into a web page directly. When using the PII bar, the user need not remember the exact sequence of characters in a PII string, nor type them in; rather, the string is selected from a menu.
2.4.5.2 User Trust in User Agent
This proposal assumes the user will trust their user agent to keep a record of their PII.
2.4.5.3 Tendency to Use the Same Name for the Same Entity
If a user has created a large number of relationships using the PII bar, but has not created a relationship for all entities that PII is exchanged with, the user is vulnerable to an imposter who tricks the user into creating a new relationship. The proposal defends against this attack by detecting an attempted reuse of a petname. This detection is either manually done by the user, if the first option presented by the bootstrap scenario is selected; or automatically by the browser if the user proceeds with the second option presented by the bootstrap scenario. For this defense to work, it must be the case that the user will tend to use a similar name each time they try to identify the entity they expect to be interacting with.
2.4.6 Disruption
2.4.6.1 Longer Login Ritual
In the typical case, the login ritual is longer than that supported by current password managers or form fillers, but provides some important advantages:
It can be reliably implemented. Today's password managers often succeed at guessing the location of many login fields, but sometimes fail, requiring the user to enter the information afresh. This failure mode is highly susceptible to phishing. It also legitimizes failure, which a phisher can exploit to convince the user that an attack is just a normal implementation failure. Web content types are currently undergoing change with the introduction of new HTML tags, Flash, etc. and should be expected to continue to evolve in the future. To avoid implementation lag, a user interaction that can be reliably and quickly implemented as new web content types are deployed is needed. Any lag in keeping up with new content types provides an opportunity to phishers.
It is reusable for all PII text string types. The same procedure can be used to enter a SSN, credit card number, phone number, etc. The set of possible PII text strings is large and open, so a generic data entry interaction is needed.
The user actively indicates they wish to use the form filler and so the browser need not pop a dialog asking if it is OK to remember the entered text string.
2.4.7 Conformance
2.4.7.1 Selection of a PII text string
The discussed scenarios rely upon user selection of a previously entered PII text string. This section elaborates on the exact requirements for this text string selection user interface.
The PII editor text field supports user entry of a new text string, or auto-completion of a previously entered text string. The editor MUST provide an indication of which of the two actions is being taken. For example, the text field could change the background color or font when a previously entered text string has been entered. The text field MUST NOT provide auto-completion for text strings that have not been previously submitted to the currently displayed web site.
The PII editor history menu supports user selection of a previously entered text string. The menu MUST indicate whether or not an offered selection has been previously submitted to the currently displayed web site. Further, the user action to select a text string previously submitted to the current site MUST be different from that to select a text string previously submitted to some other site. For example, text strings previously submitted to the current site could be displayed in the main menu and other text strings displayed in a sub menu. Consequently, the user would have to click more than once to select a string not previously submitted to the current site, but only once for a string that has been previously submitted.
Both of these selection mechanisms purposely require explicit action by the user. Transmission of a PII string in a particular request represents user consent for use of that PII for the purpose of that request. The user agent MUST NOT subvert this consent by auto-filling form fields with information taken from the PII bar history. Information MUST only be transferred from the history database to the web page as a result of an explicit approval action by the user.
The PII bar MUST be the only form filling feature of the user agent. A competing form filling feature would undermine the security features of the interaction created by the PII bar.
2.4.7.2 On screen masking of a PII string
Some PII strings, such as some passwords, are of such high value that displaying them within the user agent, where they may be seen by an onlooker, is too great a risk. This sub-section specifies a mechanism for marking a PII string as one which should not be displayed by the user agent.
The PII editor history menu MUST provide a means for the user to mark a PII string as one which is not to be displayed on screen. Invoking this command prompts the user for a "display name". Wherever a PII string would be displayed by the PII bar, the provided display name MUST be shown in its place, as well as an indication that the displayed text is a display name, rather than an actual PII string. The auto-completion feature of the PII editor text field MUST match keystrokes against the display name, instead of the named PII string. Whatever way a display name is selected, the named PII string MUST be form filled, not the display name text.
2.4.7.3 Editing the stored history
Each edit of the PII bar history MUST be explicitly made by the user. In particular, a visited web site MUST NOT be able to add, delete, modify or read the PII bar history. A visited web site MUST NOT be able to receive keystrokes sent to the PII bar by the user.
Some PII identifiers change over time. For example, a credit card number may change when the card is re-issued. The PII editor SHOULD provide a means for the user to replace a specified PII string with another. When this action is taken, the PII bar history display shows the replacement PII string as being previously submitted to all web sites that had previously received the replaced PII string. The PII editor SHOULD also provide a means to delete a PII string. Using this feature, the user can reduce interface clutter created by a PII string that is no longer in use. These recommended features are not required because they do not defend against a specific attack, but do support continued use of the PII bar.
Under some circumstances, a relationship between the PII bar and a site may need to be terminated. The PII bar MUST provide a means for a user to mark a site as one which will no longer be recognized. When this command is invoked, the PII bar MUST behave as if the relationship never existed, for all scenarios specified by this specification.
2.4.7.4 Reliable text
To defend against web site impersonation, the PII bar is designed to only display text strings provided by the user, or statically provided by the user agent software. Implementations MUST NOT display a text string, or graphic, from any other source within the PII bar user interface. The Bootstrap scenario message quoting information obtained from a web site's certificate MUST be displayed outside the PII bar. The quoted text, the part of the message after "belongs to", MUST be visually distinguished from the rest of the static text. If the described certificate chain was not issued by one of the user-agent's installed and trusted certificate authorities, the message MUST NOT quote any information from the certificate, instead displaying a message meaning: "This web site's credentials are unrecognized". The same two user actions are still offered by the rest of the message.
2.4.7.5 Associating a history with a web site
The PII bar associates a petname and PII exchange history with a web site. This section specifies the algorithm the user agent MUST use to determine if a visited web site should be considered the same as one in the history database. This algorithm is based solely on a comparison of information provided by X.509 certificate chains. Let the currently visited web site be SiteA and a candidate match in the stored PII bar history be SiteB. For each certificate chain received from SiteB, attempt a match against the one received from SiteA using the following checks:
If both SiteA's and SiteB's certificates are currently valid and they specify the same public key, there is a match; otherwise, continue with the matching algorithm.
If SiteA's certificate was issued by a different certificate authority than SiteB's certificate, there is no match; otherwise, continue with the matching algorithm. Two certificate authorities are considered the same if their certificates are identical, or if they are both installed as trusted certificate chain roots identified by the same name in the Bootstrap scenario message.
If both SiteA's and SiteB's certificates specify the same value for the "CN" field, there is a match; otherwise, continue with the matching algorithm.
If both SiteA's and SiteB's certificates specify the same values for all of the "O", "L", "ST" and "C" fields, there is a match; otherwise, continue with the matching algorithm.
The algorithm ends here with no match.
The user agent MUST retain sufficient information about all the certificate chains used by a web site to find a match in all cases where the above algorithm indicates there is a match.
The first check in the matching algorithm, which compares public keys, provides a means to transparently update the certificate authority used by a web site. To change certificate authorities, a site acquires a certificate for its existing public key from the new certificate authority. The site should continue using its existing public key until its user base has received the new certificate chain through visits to the site.
Both the first check in the matching algorithm and the second to last, which compares the "CN" fields, provide a means to transparently update an organization's name and address. To change this certificate information, an organization acquires a certificate chain that specifies the updated information, but matches against one of these earlier checks.
It is common for an organization to use multiple, unrelated domain names. The final check in the matching algorithm enables sharing of history across all the hostnames used by an organization.
2.4.7.6 No support for non-SSL data exchange
The PII bar supports safe entry of PII by the user into a web site with which a continuous relationship has been established. The user should expect this continuity to be securely enforced and the transmissions protected from eavesdropping and tampering. Currently, these properties can only be supported on the web through the use of SSL. The PII bar MUST NOT be enabled for exchanges that are not protected by SSL. If the user hits the PII bar attention key when visiting a site not protected by SSL, the user agent MUST display a message meaning:
This web page does not support secure information exchange, and so the PII bar cannot be used here. Information entered into this web page may be seen, or tampered with, by others on this network. Click here to see if the web site supports a secure version of this web page.
Selecting the provided option navigates the browser to a URL constructed by changing the current page's URL scheme to a corresponding one that uses SSL. For example, an http: URL is converted to an https: URL.
2.4.7.7 Detecting a possible Man-In-The-Middle attack
If the user navigates to a web site by selecting a hyperlink provided by the Contacts button in the PII bar and the site does not present a certificate chain that can be matched to one of its previously stored certificate chains, the user agent MUST display a message meaning:
This web site is presenting credentials which cannot be securely matched to those provided in the past. You should not continue with your current task until this error has been corrected. Click here to report this error to the web site's administrator.
Selecting the provided option SHOULD send an email to the technical contact for the domain name, as reported by a WHOIS lookup. The email contains the stored certificate chains for the site, the newly received certificate chain and the IP address it was received from.
2.4.8 Security Considerations
2.4.8.1 Secure storage
Like the password managers in today's user agents, the PII bar stores information whose confidentiality must be protected. Implementors should use secure storage techniques that ensure the PII database is only accessed by the user. Specifying appropriate storage techniques is beyond the scope of this recommendation.
2.5 Extended Validation Certificates
2.5.2 Overview
In pre-EV browsers the only visible cue indicating the security status to the user is the presence or absence of the padlock icon. Moreover the semantics of the padlock icon are confused, users are encouraged to believe that the padlock icon tells them that a site is trustworthy, the actual semantics are merely that communication to the site is encrypted.
EV is designed to provide the user with a clearly visible indication of accountability of both the certificate subject and the certificate issuer. While accountability does not guarantee trustworthiness of the subject it is a good control.
In order to become an approved issuer of EV certificates an issuer must be in compliance with the CABForum minimum critera, as demonstrated by a WebTrust audit of the certification practices. Presentation of the Issuer identity within the EV user experience ensures accountability of the certificate issuer above and beyond the minimum criteria.
The EV certificate issue criteria do not by themselves imply or require any special processing by browsers, rather they enable special processing to be performed by providing an accountable source of data that the browser may rely on as being authoritative for the purpose of supporting an enhanced user experience.
Browsers should implement an enhanced EV experience for SSL and for code downloads.
2.5.3 Dependencies
EV depends upon the SSL server certificate chain information and in particular the presence of a certificate issuer specific certificate policy extension OID.
2.5.4 Use Cases
2.5.4.1 Use Cases: 1, 2, 3, 4
In these use cases Alice is visiting her bank's Web site using URLs presented in a variety of modes (typed in, bookmark, etc.). In each case the intended interaction is that Alice recognizes the enhanced EV security experience as the primary cue to tell her that the site she is visiting is trustworthy.
2.5.4.2 Use Cases: 5, 6
In this use cases Doyle is presented with a bogus site on his first attempt to contact the site. EV allows Doyle to recognize that the site he is visiting has not established itself as trustworthy according to the EV criteria.
2.5.4.3 Use Cases: 7
In this use case Frank is presented with a pop-up screen that is not directly associated with the content he is visiting, effectively 'free riding' on the trustworthiness of that site.
Ideally an enhanced EV code authentication mechanism would alert Frank to the fact that he is being asked to download and run code that is not trustworthy.
2.5.5 Expected User Behavior
The expected user behavior is dependent on the level of user experience of the enhanced EV display.
A user who has no previous experience of an enhanced EV display is intended to find that the EV user experience makes it more obvious that they are visiting an accountable and hence more trustworthy site.
A user who has extensive experience with EV is intended to expect the presence of the EUV user experience whenever they engage in a Web transaction requiring a high level of trustworthiness.
2.5.6 Disruption
The level of disruption caused by the EV experience depends on the implementation. Current implementations are considerably more obvious than the previous padlock user experience but do not use pop-ups or other intrusive elements.
2.6 Secure Internet Letterhead
2.6.2 Overview
Secure Internet Letterhead consists of the use of a PKIX Logotype extension within an EV certificate to display the brand of the certificate issuer, subject and/or communit(ies) within a framework that establishes accountability and hence trustworthiness.
2.6.3 Dependencies
Secure Internet Letterhead depends upon the SSL server certificate chain information and in particular the presence of a certificate issuer specific certificate policy extension OID for EV and a PKIX LOGOTYPE extension.
2.6.4 Use Cases
Secure Internet Letterhead addresses essentially the same use cases as for EV. The difference is that Secure Internet Letterhead provides a more direct connection to the frrame of reference in which the typical user evaluates trust decisions (i.e. brands as opposed to names).
As such the presentation of the Secure Internet Letterhead information requires certificate issuers to raise their game and make the utmost effort to ensure the reliability and trustworthiness of the information they present.
2.6.5 Expected User Behavior
The expected user behavior is similar to that of EV except that:
A first time user who decides that they require additional assurance MAY look at the secondary chrome dialogue to determine which community logos are presented. For example Alice may want to know if her bank is FDIC insured on her first visit but is unlikely to require this on subsequent visits.
A frequent visitor to the site MAY be expected to look for the letterhead as the primary indication that the intended site is being visited.
The letterhead concept is intended to be ubiquitous and apply to every mode of Internet communication.
2.6.6 Disruption
As with EV, Secure Internet Letterhead does not mandate a user experience. It is however entirely possible to porovide a non-intrusive user experience.
2.6.7 Accessibility
The information provided by Secure Internet Letterhead is in addition to the information already provided in an X.509v3 certificate and not a substitute. Browsers designed for use by blind and partially sighted users should consider employing the existing X.509v3 subject and issuer information instead. Certificate issuers should provide an accessible means of entering community accreditation information.
Although the PKIX Logotype specification describes the presentation of audio instead of images the use of this information is problematic due to the lack of a consistent and comprehensive use of audible brands.
2.7 Revisiting Past Decisions
2.7.2 Overview
Security decisions made interactively often become persistent, and affect a user's security context. Current web user agent user interfaces do not enable users to understand to what extent their user agent's presentation of security context information depends on decisions that were entered interactively, and which might therefore be more prone to error than trust decisions that are part of software as shipped.
2.7.3 Requirement
User agents MUST enable users to access a history of interactive security decisions that affect the user agent's interpretation of the user's current security context. User agents MUST enable users to revert such decisions using a user interface that is easily accessible.
2.7.4 Implementation
Interactive operation that enable the user to inquire about the reasons for the Web user agent's current assessment of the user's security context.
Distinct presentation of trust states if a trust decision was interactively (or recently) entered by the user, and affects the current security context.
Availability of an overall log of trust decisions entered interactively.
Ability to change security decision.
Ability to reset to default setting.
2.7.5 Dependencies
User agent configuration
Client state, as far as it is affected by user decisions
Note that this suggests adding "user's past trust decisions" to the available context information.
2.7.6 Expected User Behavior
A core assumption of this requirement is that users might make trust decisions interactively, and that these decisions are error-prone. The aim of this scenario is to give users a possibility to find out what trust decisions they -- consciously or inadvertently -- made in the past, and to let them revisit these decisions at a later stage.
2.8 Browser Lock-Down
2.8.2 Overview
The current approach taken by most user agents is to treat the user of the user agent as having complete control (and thus assumed knowledge) over setting the myriad of security and non-security related configuration settings that are possible to be set in modern user agents. While these settings are presented in a number of ways including tabbed dialogs, check-boxes, combo-boxes, and radio-buttons, there are still a vast number of settings for end users of user agents to consider when setting up their user agent. Too often, the terminology for these settings is written more from the point of view of the developer of the user agent than from the user of the user agent.
Furthermore, in many cases, what would constitute a "good" set of configuration settings for one type of usage of the user agent (for example, casual browsing only) would not be considered "safe" for other types of usage (e.g. conducting business transactions using the user agent).
Clearly, there is ample opportunity for improvement in reducing the complexity of setting this multitude of configuration as well as allowing this configuration to vary by site visited as well as "operating mode" in which the user agent is being used.
2.8.3 Applicability
This recommendation is applicable to any user agent which contains configurable settings for security-related processing. The end result of an implementation meeting this requirement would be a user agent which operates according to a configuration and does not allow the user to stray outside of this configuration. There would be no prompting to accept or avoid access to a site - the configuration settings would indicate what the choice should be. There would be no dialogs presented to the user for configuration - ideally a set of "known good" or "known to be trusted" configurations or "profiles" could be loaded and worked from.
For isolated deployments, an organization could choose to deploy a set of profiles or configuration settings such that their organization's users would use the user agent according to the organization's recommended/mandatory terms of use (as defined by the configuration parameters defined to the user agent by some administrative entity).
2.8.4 Requirements
A user agent MUST support a mode of operation whereby the user is unable to view or modify the security-related configuration settings.
A user agent MUST support the configuring of several "profiles" (sets of configuration settings) to be used when visiting different categories of sites.
A user agent MUST support the configuring of different "usage modes" and allow the specification of which profiles are active in which modes.
A user agent SHOULD allow users to view details of why a request or access to a site was blocked based on profile settings, including a description of which configuration setting or settings contributed to the site being blocked (but displayed only on request).
A user agent SHOULD keep a history of blocked sites and the reasons for the block to allow analysis of these at a later date and time (and possibly by a person other than the user).
A user agent SHOULD support a "admin/service" mode in which configuration settings and profiles can be set up and changed, separate from a "usage" mode to be used by what is considered the "user" of the user agent.
2.8.5 Techniques
Implementations may choose to support a multitude of configuration settings called profiles in this description. Implementations may allow a user to act as both an administrator of the user agent and a user of the user agent as a means of transitioning users from current status quo to fully locked down processing.
Organizations and social networking sites could build collaborative works to offer "well tested" or "popular" configuration profiles.
Which profile is employed could be made a factor of usage mode as well as site being visited. Site-specific behavior may be done based on rules about the security indicators the site is providing or based on white-list/black-list type lookups.
2.8.6 Dependencies
All information in the available security indicators (Available security information) could prove useful in determining which profile to employ for a given site visited.
2.8.7 Examples
Internet Explorer has an approximation of some of this with its security mode of "Internet" or "Local" configuration settings. However, the implications of this dialog are not well understood nor documented. Also, the user is still provided far too much disruption (spurious dialogs) and is also assumed to have sufficient knowledge and savvy to understand when a particular configuration setting should be modified.
2.8.8 Use Cases
Applicable use cases (from use cases):
2 - redirection to the unfamiliar site would be blocked by configuration, no chance for Alice to interpret the site incorrectly
3 - download and install would be denied by configuration, no choice for Alice to make.
4 - download and install would be denied by configuration, no choice for Alice to make.
6 - download and install would be denied by configuration and being in "casual browsing" mode, no choice for Doyle to make.
7 - download and install would be denied by configuration and being in "casual browsing" mode, no choice for Frank to make.
9 - which sites were allowed would be controlled through white-list/black-list dependent on operating mode.
12 - no in-flight dialog pop-ups would be displayed. Betty could go back later and get the certificate if accessing that site is of interest, but does so when she is in the frame of mind of changing security configuration. The log of blocked sites (and reason for the blockage) assists in performing this work.
13 - the certificate either accepted or site blocked based on configuration, no choice for Betty to make.
14 - the certificate either accepted or site blocked based on configuration, no choice for Betty to make.
18 - dialog boxes are not displayed, all decisions based on configuration, no dismissing them out of habit.
2.8.9 Attack Resistance and Limitations
Attacks on the integrity of the system on which the user agent is running (and thus the configuration is held) are applicable.
Users may find annoyance in experiencing a large number of blocked sites if the configuration is overly constricting or a large number of sites are operating with what appear to be risky behavior. Also, analyzing past blockages to determine if a change in configuration/profile is warranted could prove to be a difficult debugging task.
More analysis of additional attacks is necessary.
2.8.10 Usability Effect
2.8.10.1 Expected User Behavior
The overall theme of this proposal is to remove the security decisions from the "user" of the user agent altogether - at the time of the suspicious or risky site being visited. Rather, determine all user agent behavior based on configuration and allow blocked sites to occur. Also, allow what are considered to be "more savvy" or "more knowledgeable" administrative users to exert control over the user agent configuration profiles on the end user's behalf. Thus, someone could contract with some other organization to configure their user agent per their guidelines and thus accept that they will be visiting sites that are determined acceptable based on that contracted organization's rules.
User security choices are eliminated at the expense of sites/features not being available while in various operating modes and controlled by certian profiles.
2.9 Page Security Score
2.9.2 Overview
This requirement proposes that all the security context indicators (SCIs) be aggregated into a single page security score (PSS) using a standard formula. Web agents should score pages and make the score available to users. Web agents should also derive primary chrome indicators (padlock, colored bar, thermometer, etc.) from this standard score in order to provide a consistent and trustworthy security context semantic to users.
2.9.3 Applicability
This requirement applies to all HTTP user agents that display web content to humans.
2.9.4 Requirement
The user agent MUST compute a security score for each page rendered, using the Techniques described below.
The user agent MUST make the security score available to the end user, although it need not be displayed as a primary SCI in chrome.
The user agent MUST make available to the end user the formula, or formula standard and version, by which the security score is calculated.
The user agent SHOULD provide a visual indicator in chrome (primary SCI) that is derived from the security score, using the Techniques described below.
2.9.5 Techniques
2.9.5.1 Scoring Techniques
The scoring technique will require discussion and testing before it can be finalized. Even if it becomes a standard, it will likely undergo further iterative refinement under version control. The following scoring technique is offered as an example or starting point:
2.9.5.1.1 Page Security Scoring Formula Version One (PSSFv1)
This proposed formula yields a page security score (PSS) from 0 to 99, with 0 representing the least secure page and 99 representing the most secure.
Inputs
HIST1 = 5 if user visited this domain in the past, else 0;
HIST2 = 5 if user visited this particular page in the past, else 0;
HIST3 = 5 if user has saved credentials for this site in the past or bookmarked this particular page in the past, else 0;
CA1 = 0 if no SSL/TLS, 5 if server X.509 certificate is self-signed, 10 if issued from an untrusted root, 15 if from a trusted root, 20 if it's an Extended Validation (EV) certificate;
CA2 = -5 if server certificate has expired, else 0;
CA3 = 0 if no SSL/TLS, (CA2-CA1) if server certificate has been revoked, 5 if it has not been revoked according to a CRL, 10 if it has not been revoked according to a successful OCSP call or a valid stapled OCSP response, (CA2-CA1)/2 if revocation status indeterminate;
TLS1 = 0 if no SSL/TLS, 5 if SSLv1, 10 if SSLv2, 15 if SSLv3 or TLS 1.0 or higher;
TLS2 = 0 if no SSL/TLS, 5 if null cipher, 15 if AES or Triple DES (3DES-EDE) with proper key length, 10 for any other cipher suite;
TLS3 = 5 if all resources on the page are https, else 0;
DNS1 = 0 if host name resolved from local HOST file, 5 if hard IP address used (no name resolution), 10 if name resolved via DNS, 15 if DNSSEC;
DNS2 = 0 if no SSL/TLS, (CA1)/5 if server certificate name matches URL host name, else -(CA1+DNS1)
Output
PSS = HIST1 + HIST2 + HIST3 + CA1 + CA2 + CA3 + TLS1 + TLS2 + TLS3 + DNS1 + DNS2
Bounds
The highest a page can score under the PSS version 1 formula is 99, which can only be attained if the page uses both EV SSL and DNSSEC among other factors. A typical bookmarked https page on the WWW today, without EV SSL or DNSSEC, would score 88 under the formula if all other security indicators are positive. The highest a page can score without EV SSL is 93. The highest a page can score without DNSSEC is 95. The highest a non-https page can score under the formula is 30, which can only be attained if the page was previously visited and uses DNSSEC. Without DNSSEC the highest a non-https page can score is 25. The lowest a page can score under the formula is zero (0).
2.9.5.2 Primary Display Techniques
User agents that derive a primary chrome SCI from the PSS should allow for at least 4 different gradations. Using the PSSFv1 formula above, the obvious gradations for a 4-level schema would be the ranges 0-24, 25-49, 50-74, 75-99. However the formula should be tested against a broad variety of web sites to determine its true distribution, and this could lead to some adjustments in gradation ranges. Gradations can be rendered visually in various ways, such as colors (red, orange, yellow, green) or images (such as faces - angry, frown, sad, happy). The gradation rendering should be based on an intuitive continuum of images. User agents may choose to present the PSS at full granularity without gradation in the primary SCI. For example, a thermometer bar with 100 different "temperatures". These display techniques can also be combined in various ways. For example, a colored thermometer bar.
2.9.6 Dependencies
This proposal depends upon all the security information described in Page Info Summary. Each piece of information described there is a weighted input to the page security score (PSS) formula.
2.9.9 Usability Effect
2.9.9.1 Expected User Behavior
The less technical but security conscious user is expected to notice the primary SCI and make decisions about online behavior based on the level of security risk. The technically smart user (e.g., sys admin) is expected to reap the same benefits as above, plus gain additional information from the raw page score to guide safe online behavior. The less technical user who is not security diligent is unlikely expected to benefit as much from this requirement.
2.9.10 References
Archived email was the genesis for this requirement, along with subsequent discussions.
Page Info Summary defines the SCIs from which a PSS is derived.
2.10 Page Info Summary
2.10.2 Overview
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 co