Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This Note refines the objectives for the Web Security Context Working Group deliverables. It 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.
This Note also includes an initial collection of use cases that the Group expects will drive its technical work.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a Public Working Draft of "Web Security Experience, Indicators and Trust: Scope and Use Cases", produced by the Web Security Context Working Group, as part of the Security Activity.
The Working Group thanks those who have submitted comments against a previous version of this document. While this iteration includes changes to address some of the issues raised, we do not imply that all have been addressed, yet.
Once all the issues about this document have been addressed, the Working Group intends to issue a Last Call, to work toward publishing a stable version of this document as a W3C Working Group Note.
Please send comments related to this document to public-usable-authentication@w3.org (public archive).
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Overview
2 Goals
2.1 Document the status
quo
2.2 Relevance of security
information
2.3 Consistent presentation of
security information
2.4 User awareness of security
information
2.5 Reliable presentation of
security information
2.6 Reduce the
number of scenarios in which users need to make trust
decisions
2.7 Authoring and deployment
techniques
2.8 Best practices for other
media
3 Non-goals
3.1 Presentation of all
security information
3.2 Non-HTTP Web
interactions
4 In scope
4.1 Web interactions
4.2 User agents
4.3 Entity
identification
4.4 Third-party
recommendation
4.5 Historical browsing
information
5 Out of scope
5.1 Protocols
5.2 non-Web
interactions
5.3 Security context information
for consumption by automated agents
5.4 New security
information
5.5 Content based
detection
5.6 Security information
about the user's computer
5.7 User agent exploits
5.8 User separation
5.9 Content production
exploits
6 Use cases
6.1 Destination site
6.2 User's navigation toward the
destination site
6.3 Intended interaction
6.4 Actual interaction
6.5 Scenarios
7 Security information available to the
user agent
7.1 Provided by HTTP
7.2 Provided by web
content
7.3 Provided by SSL
7.4 Provided by IP or
DNS
7.5 Provided by user
agent
7.6 Provided by user
7.7 Provided by
third-party
8 Merits of the status quo
8.1 Widely deployed, strong
cryptography
8.2 Many deceptive
imitation techniques prevented
8.3 Corrected implementation
errors
8.4 Password
management
9 Problems with the status quo
9.1 Poorly defined area for
chrome
9.1.1 Picture in
picture
9.1.2 Visually
extending the chrome
9.1.3 Removing the
chrome
9.2 Poorly defined role for
chrome
9.2.1 Browser window
title
9.2.2 Back and forward
buttons
9.2.3 URL bar
9.2.4 Padlock
icon
9.2.5 Favicon
9.2.6 Status
bar
9.2.7 Information
bar (aka: notification bar)
9.3 Poor user understanding of
chrome
9.3.1 Padlock
icon
9.3.2 Hostname
9.3.3 Chrome versus
page
9.3.4 Explanations
versus understanding
9.4 Poor usability of
chrome
9.4.1 Out of sight,
out of mind
9.4.2 Assumed
safety
9.4.3 Poor usability of
dialog boxes
10 Process
10.1 Expertise and
experience
10.2 Reliance on
general usability expertise
10.2.1 Affordance
10.2.2 Conceptual
model
10.2.3 Match between
system and the real world
10.2.4 Habit
formation
10.2.5 Single
locus of attention
10.2.6 Aesthetic and
minimalist design
10.2.7 Help users
recognize, diagnose, and recover from errors
10.2.8 Provide explanations,
justifying the advice or information given
10.2.9 Understand the
user
10.2.10 Create task
profiles
10.2.11 Consistency
10.3 Learning from past
efforts
10.3.1 No user categories
in phishing vulnerability
10.3.2 The user must be
aware of the task they are to perform
10.4 Implementation and
testing
11 Acknowledgments
12 References
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.
Security information within the Working Group's scope will be catalogued, along with corresponding presentations and user interpretations reported in user studies.
The Working Group will analyze common use cases to determine what security information the user needs to safely accomplish their current task and recommend security information that should, or should not, be presented in each case.
The Working Group will recommend a set of terms, indicators and metaphors for consistent presentation of security information to users, across all web user agents. For each of these items, the Working Group will describe the intended user interpretation, as well as safe actions the user may respond with in common use cases.
The Working Group will recommend presentation techniques that integrate the consumption of security information by the user into the normal browsing workflow. Presenting security information in a way that is typically ignored by the user is of little value.
The Working Group will recommend presentation techniques that mitigate deceptive imitation, or hiding, of the user agent's presentation of security information.
No matter how well security context information is presented, there will always be users who, in some situations, will behave insecurely even in the face of harsh warnings. Thus, the Working Group will also recommend ways to reduce the number of situations in which users need to make trust decisions.
The Working Group will recommend authoring and deployment techniques that cause appropriate security information to be communicated to users. Techniques already available at authoring and deployment time which reduce the need for communication of security information to the user will be considered in the recommendations.
Users' interpretation of security information on the web will necessarily be affected by experience with other media that are not part of this Working Group's scope; such as email, print, radio or video. The Working Group will provide best practice guidelines for other media to follow so as not to undermine the presentation of security information on the web.
This section outlines a range of work items which the group will not focus on, but which may be covered as beneficial side effects of the group's work. Work items listed here won't be a priority, and the group won't expend collective resources on tackling them.
Web user agents contain a great deal of information relevant to security. This Working Group does not aim to recommend a presentation for all of this information. Recommendations will be narrowly focused on presentations that satisfy the Working Group's use cases.
Access to security information beyond what is available through the recommended presentation may be desireable in many scenarios, such as debugging. User agents are encouraged to provide this access, but in a way that does not interfere with the recommended presentation.
Recommendations that this group makes may or may not be relevant to Web related interactions that use protocols other than HTTP or HTTPS. While the group will aim for its recommendations to be generically useful -- where appropriate --, it considers recommendations specific to other protocols as a Non-Goal.
This section enumerates categories of technology and information that are within this Working Group's scope, as initially defined by the group's charter. A complete enumeration of in scope artifacts is provided by the Security information available to the user agent section.
User interactions on the Web [web-arch], using the HTTP and HTTPS protocols, are at the core of the Working Group's scope. Where Web interactions involve other application-level protocols (including, e.g., SOAP or FTP), the Working Group considers these in its scope and will aim that its recommendations be applicable; however, applicability to non-HTTP Web interactions is a non-goal.
A user agent is software to access Web content, including desktop graphical browsers, text browsers, voice browsers, mobile phones, multimedia players, plug-ins, and some software assistive technologies used in conjunction with browsers such as screen readers, screen magnifiers, and voice recognition software. [WAI-WEBCONTENT]
Use cases considered by this Working Group must involve a web user agent, operated by a human user. In all instances, the use case is only relevant to this Working Group if the presentation of security information should affect the user's interaction with the web resource.
A web browsing session is like a conversation, where the user converses with various entities, some known, and others newly encountered. Each resource the user interacts with is identified by a URI. Through specifics of the underlying protocol, including DNS and SSL, other designators are bound to these resources and the entities that provide them. Recommending a presentation for these designators that helps the user recognize which entity they are currently conversing with, and when they are switching to a different entity, is a primary concern of this Working Group.
A user's perception of an entity is strongly influenced by the opinions of others. The recommendations of certificate authorities, visited web sites or reputation services integrated into the user agent are in scope for this Working Group.
The Working Group may also use information about past interactions between the user and an entity in presentation recommendations. Relevant historical browsing information includes entity designators used in past browsing sessions, as well as information provided by the user to the entity during those sessions.
This section enumerates a number of possible work items that the Working Group will not consider.
The Working Group considers recommendations for lower level protocols (such as SS7, ISDN, or NANP) out of scope.
The Working Group considers recommendations specific to interactions that do not involve the Web (e.g., rich text display in an e-mail user agent) out of its scope. However, where such interactions use Web Technologies, recommendations may turn out to be applicable.
The Working Group will only consider Web interactions in which a human participates in making a trust decision this group is chartered to address. Situations in which all security relevant information is consumed and acted upon only by automated agents are out of scope.
The Working Group will neither create nor extend any protocol or data format, nor create recommendations for protocols or data formats that are not yet widely deployed. Recommendations will only be made for the presentation of currently deployed security information.
Techniques commonly used by intrusion detection systems, virus scanners and spam filters to detect illegitimate requests based on their content are out of scope for this Working Group. These techniques include recognizing known attacks by analyzing the served URLs, graphics or markup. The heuristics used in these tools are a moving target and so not a suitable subject for standardization. The Working Group will not recommend any checks on the content served by web sites.
Security information about the user's computer, such as that provided by virus scanners, or trusted computing infrastructure, is out of scope for this Working Group. No recommendations will rely on such services, or any aspect of trusted computing. As a result, presentation techniques recommended by this Working Group may be undermined by malware that has infected the user's computer.
Attacks that exploit a programming error in the user agent are out of scope. This Working Group's recommendations assume a properly functioning user agent.
Many computers are shared among multiple users, either in the home, or as a kiosk in a public place. In such scenarios, the activity of one user must not be accessible to another. Providing this functionality may be best done by the operating system, or other software, and is out of scope for this Working Group.
Programs that produce HTML, or other web content, commonly suffer from quoting errors that enable Cross-site scripting (XSS) attacks. The web user agent is in a poor position to detect these attacks, since it sees only the output. Web content formats are not currently designed such that the receiver can readily distinguish content that was produced on purpose versus content that was produced by accident. Consequently, this kind of attack is out of scope for this Working Group.
We distinguish a number of properties in the basic use cases that we address.
A user may have interacted with a site before (i.e., the web site is present in the user's browsing history); he may also have submitted forms to that site before. The site might belong to an organization that the user knows of (and intends to interact with), or it might belong to an organization that the user does not know of, and may or may not have an intention to interact with. For a site that has been visited before, the site's appearance might have changed significantly.
The user might have followed a bookmark. He might have followed a web link from a known site, or from a search engine. He might have entered a search term into his browser's address bar and used a feature that directly redirects him to his favorite search engine's top hit.
The user might also have discovered a site in a cinema advert, heard about it over the phone, or jotted down a URI on a napkin -- that he then mis-typed into his web browser.
Finally, a web browser might have been launched by some local or remote application.
A user might be interested in retrieving information from the public Web, and might therefore interact with a web site in some way. He might be interested in engaging in commerce or other activities that make him expect to submit sensitive information -- be it credentials or personal data. He might be interested in downloading software for his local system, fully aware that this implies that he trusts the software provider to behave correctly far beyond the confines of the browser sandbox.
The web site's behavior may correspond to what the user intends, or the site might cause unexpected behavior: An information site asks for sensitive information; a photo download triggers software installation; an innocuous mouse click that is intended to raise a window on the user's viewport causes a pop-up or pop-under window to open. A time-based trigger might cause the interaction without any activity on the user's side. A user interaction (such as closing a window) might unexpectedly expose a pop-under window that has been launched much earlier.
Once a week, Alice pays her bills. She opens her web browser, 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.
prior interaction, known organization
bookmark
submission of sensitive information
submission of sensitive information
Once a week, Alice pays her bills. She opens her web browser, follows the habitual bookmark to her bank's site, and is directed to an unfamiliar site at a new domain, announcing that her bank has recently acquired another one and changed names a bit. She is asked to enter her usual credentials, succeeds, and quickly adapts to the new online banking system.
no prior interaction, known organization
bookmark, then follows a link
submission of sensitive information
submission of sensitive information
Alice has the habit of typing her bank's URL.
Once a week, Alice pays her bills. She opens her web browser, follows the habitual bookmark to her bank's site. Her bank's web site 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 that will be the conduit for her future interactions with the bank.
prior interaction, known organization
bookmark
submission of sensitive information, but site convinces Alice to install software
installation of software
Alice has the habit of typing her bank's URL.
Once a week, Alice pays her bills. She opens her web browser, follows the habitual bookmark to her bank's site. A download process starts, and a pop-up window informs Alice that she needs to install a piece of software locally that will henceforth be her conduit for her future online interactions with her bank.
prior interaction, known organization
bookmark
submission of sensitive information
installation of software
In the advertising leading up to a re-run of the 1970s movie classic "The Sting," Doyle sees an offer for a new-fashioned investment that he can't refuse, offered by a brand that he has heard of before. He memorizes the URL that is given toward the end of the advertising. Coming back home, he mis-types the URI at first, corrects a spelling error, and then reaches a web site that matches the investment firm's branding and name. He's asked for identifying information that he provides.
no prior interaction, known organization
typing
submission of sensitive information
submission of sensitive information
The URI that Doyle typed can be correct or not. Independently of this, he can end up on the web site he intended to interact with, or not. Doyle might also have typed a keyword glanced from the movie screen into a search box.
Watching more cinema advertising, Doyle sees a somewhat irritating, but intriguing movie teaser that ends with a dark screen that has a URL fading away quickly. He mis-memorizes the URL. Coming back home, he types in what he remembers, and gets directed to a web site that immediately causes a software download. A pop-up window informs him (in graphical layout that matches the teaser's last screen) that software will be installed on his system in order to enable him to fully benefit from the web site's multimedial offerings.
no prior interaction, known organization
typing, with error
informal retrieval
software installation
The web site can be the one advertised in the cinema, or not.
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. The advertising is served from an advertising agency's web site, not from the bank's.
no prior interaction, known organization
none
informal retrieval
software installation
pop-under instead of pop-up; also, it's deliberately left open whether Frank's click trigger or a timeout during his absence causes the pop-up to appear. The software could be on the bank's web site, on an advertising agency's, or on a prankster's.
Example Inc. has a popular online service that processes many credit card transactions a day. Betty occasionally uses the service and trusts it with her credit card information. Malcolm is a thief with an idea. He creates an imitation of the Example web site and begins directing users to it. Malcolm contacts victims through email, or even the phone, and links to his imposter site from popular blogs and chat forums. He's also given his imposter site a domain name that is just a typo away from Example's authentic web site, so some victims will arrive by accident. Betty is about to enter her credit card information into a site that looks just like Example's. How is she to know if it's the authentic site, or the imposter?
no prior interaction, unknown organization (but user expects a particular organization)
link or typing
submission of sensitive information
submission of sensitive information
Example Inc. has use of example.com, example.net and example.org. Each is used to manage a different part of the company's online operations. Betty initially found Example at example.com and created her online account through a page hosted at that domain. She has yet to interact with any of Example's other hosts. Sometime later, Betty receives an email claiming to be from Example and alerting her to a pending task that she must attend to. The email provides a hyperlink to a page that will help Betty complete the task. After clicking on the hyperlink, Betty's user agent displays a page from the example.net host. The page asks Betty to enter her username and passphrase before being allowed to access her account. How is Betty to know that her Example credentials can be safely entered into the page?
no prior interaction, known organization
any
submission of sensitive information
submission of sensitive information
Betty's home wireless router has a web interface for making configuration changes. When the router is installed, it generates a self-signed SSL server certificate. Sometime later, Betty attempts to make a configuration change. How does Betty know she's connected to the router she setup earlier, and not her neighbor's?
prior interaction
bookmark
submission of sensitive information
submission of sensitive information
Betty tries to connect to a web site at
<https://www.example.com/>. Her user
agent's SSL implementation detects that the domain name
specified in the certificate differs from
www.example.com. What should the user agent
display?
prior interaction
bookmark
information retrieval
information retrieval
Note: This is actually a variation over use case 1, with an error condition in the SSL security mechanism.
Betty is planning a trip to a foreign country. Searching the web, she finds a widely recommended local travel agency. When she connects to their web site, her user agent does not recognize the certificate authority that issued the travel agency's SSL server certificate. What should the user agent display?
no prior interaction, known organization
following a link
information retrieval or submission of sensitive information
information retrieval or submission of sensitive information
This is a variation over other use cases, with a specific error condition.
Betty occasionally visits the example.com web site. On each connection, Betty's user agent receives an SSL server certificate issued by the same certificate authority. On the current connection, the received certificate was issued by a different certificate authority. What should the user agent display? Can Example Inc. affect this display through the content of the new certificate?
prior interaction, known organization
bookmark
any
same
This use case is a variation of use case 1, with a possible error condition in the SSL security mechanism.
Betty occasionally visits the example.com web site. On each connection, Betty's user agent receives an SSL server certificate with the same Organization name and address. On the current connection, the received certificate specifies different attributes.
prior interaction, known organization
bookmark
any
same
This use case is a variation of use case 1, and spells out a possible error condition in the SSL security mechanism.
Betty clicks on a hyperlink to the web page at
<https://www.example.com/>. The
received HTML page includes content received from
<https://www.example.net/>. Betty's
user agent is unaware of any relationship between the
www.example.com and www.example.net web sites.
This use case spells out a complication in the use of the SSL security mechanism. It is independent of our overall classification of basic interactions.
Steve runs a suite of security software on his machine that regularly upgrades certain components. The typical workflow is that a specific browser window is opened automatically. Steve will then control the selection of software upgrades, will download them from the web, and they will then be installed.
Known, prior visit
no user interaction
software installation
software installation
A pop-up window opens with a web site that visually imitates the legitimate software upgrade behavior, but is inteded to install malicious software.
Betty visits the web page at
<https://www.example.com/>. The
received HTML page includes content received from
<http://www.example.com/>, i.e.,
content received using a different security
context.
This use case spells out a complication in the use of the SSL security mechanism. It is independent of our overall classification of basic interactions.
Like many users, Betty has grown accustomed to quickly clicking through any warning dialogs presented by her user agent. Out of habit, Betty dismisses another one, then quickly becomes suspicious about some of the web page's content.
This use case is separate from the generalizations that were discussed earlier in this section. It suggests practices around the recording and reversibility of past security decisions.
Vicki is interested in finding out more about art auctions in the greater Boston area. She engages a search engine and tries to follow a link there. Her web browser consults a reputation service which has recorded that the link target will attempt to subvert the browser and install malicious software.
This use case is separate from the generalizations that were discussed earlier in this section. It serves to suggest practices around the display of results obtained from reputation services.
Betty has travelled to a foreign country. In a coffee shop, she is reading a political web site from her home country. She wonders whether the information that is displayed to her is authentic, and whether there will be eavesdropping on her interactions.
This use case is separate from the generalizations that were discussed earlier in this section. It serves to suggest practices around the protection against eavesdropping and alteration that deployed security technologies provide.
This section provides an exhaustive enumeration of the security information this Working Group has determined to be in scope and so available for use in recommendations. The Working Group's scope is detailed in the In scope and Out of scope sections of this document. The enumerated information is grouped into sub-sections according to the reference that should be consulted to determine the semantics of the information. For example, the first sub-section lists items defined by the HTTP protocol.
HTTP-Auth handshake [HTTP Auth]
cookies [HTTP Cookie]
Has the page completed loading?
referring page
redirection path
content-type
MIME type of the content
target URI for a hyperlink or form submission
presence of client-side dynamic content
The rendering of a web page composed of only static content has a completion point, after which the rendered view remains constant until the user chooses to navigate to another web page. Dynamic content is anything that changes this interaction or is given additional access to user agent functions. Java and Javascript are two current examples.
Does the content come from multiple domains?
Is the rendered view composed from multiple content sources, such as referenced images or stylesheets?
server hostname
server IP address
localhost versus intranet versus internet
DNSSEC [DNSSEC]
network diagnostic information, such as ping or traceroute
installed certificate authorities
installed search engines
default window layout
default bookmarks
default configuration
Has the user agent completed rendering of the page?
submitted passwords
submitted form values
bookmarks
browsing history
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
user agent customization
Successive generations of web user agents have improved upon past implementations and achieved greater deployment of security relevant infrastructure. This work provides a base upon which this Working Group will build its recommendations. This section calls out the aspects of the currently deployed web infrastructure that have already narrowed the problem space we need to address, or that we intend to learn from or build on.
Since its first deployment, the SSL protocol has undergone multiple revisions, culminating in the current TLS/1.0 protocol. Both client and server implementations are widely deployed, enabling applications to communicate in a way that is designed to prevent eavesdropping, tampering, and message forgery.
The most current generation of desktop web browsers contain several changes aimed at protecting users from the types of spoofing attacks seen in the past. Some of these changes are invisible to users, such as preventing a web site from opening a window which is larger than the visible desktop. Other changes are more noticeable, such as warning dialogs which alert users when they arrive at a website that matches an entry on a list of suspected phishing sites.
Recent web browsers correct many of the security relevant implementation errors in past browsers. Many errors in the implementation and application of the SSL protocol are now corrected.
Modern browsers include a password manager that can autofill the corresponding user login credentials for a web site. This feature provides several usability benefits that can help users notice and avoid web based attempts to steal their passwords. Autofilling provides a presentation cue indicating the credentials have been previously submitted to the web site. The user may then infer that the current operation is simply a repeat of a past trust decision, rather than a new trust decision: the decision to give the web site the corresponding password has already been made. A password manager can also eliminate the step of typing a password into a web page, a step highly vulnerable to phishing.
Though much implementation progress has been made, there remain problems with the basic design for communicating security information to the user, which is the core of the mission of this Working Group. In current user agents, security information is primarily presented through modal dialog boxes and indicators in the browser's chrome. Chrome is the representation through which the user interacts with the user agent itself, as distinct from the web content accessed. In graphical layout terms, chrome is the part of the user agent window outside of the area displaying the current web page. This user interface has a number of inherent problems, as well as problems created by the current realization.
The above definition of chrome reveals a major shortcoming in the concept. Chrome is primarily defined by where it is not, rather than where it is. As a result, there are a number of tricks for confusing the user about which parts of their screen contain browser chrome.
Modern desktop operating systems support overlapping windows of varying sizes. A smaller browser window overlaying a larger browser window can be visually indistinguishable from a larger browser window displaying a picture of a smaller browser window in the web page area. Using dynamic content technology, this picture of a window can be given functionality that closely mimicks that of a real browser window. In this case, the user may treat the web page content as a real browser window and believe the imitation chrome is real chrome.
This level of visual deception may be unnecessary to fool many users. Studies have demonstrated that many users still do not fully grasp the flexibility of the desktop metaphor and wrongly believe the security indicators of one browser window also pertain to another located on top of, or next to it. [Why Phishing Works]
The strongest visual cue the user is given for the boundary between the chrome area and the web page area is a change in background color. The chrome uses the background color for application menus, typically a light grey, and the web page area uses whatever background color it wishes, but typically white. There is nothing preventing the web page from using the same background color as the chrome area for part of the web page area near the chrome. In this case, the chrome area may appear to be extended with additional security indicators specified by the web page. In addition, color only cues often do not work for users who are color blind.
Curiously, recent releases of prominent browsers now use a similar technique to present security information to the user from the web page area. Typically the chrome extension uses a light yellow background. A web page could provide an identical presentation with a message like: "This web page is guaranteed by Example Inc. to be safe for e-commerce."; where the name Example Inc. would instead be a brand name widely trusted by users. Since users have been conditioned by the browser to expect relevant security information to be presented in this way, they may trust the message.
Employing the above visual tricks may be unnecessary for a successful attack, since the browser may support removing the chrome from a browser window, at the discretion of the visited web site. In this event, the vacated area of the browser window becomes additional web page area. Simply depriving the user of the chrome's security indicators may be sufficient, or the attacker could display imitation chrome in the same area the user expects to find real chrome.
Replacing the real chrome with imitation chrome may be unnecessary for a successful attack, since currently all of the indicators in the chrome display information chosen by the attacker. By choosing values for these indicators which are likely to deceive the user, the attacker can produce an imitation of the victim web site using the real chrome, rather than imitation chrome. It is unclear in what way the user should rely on the chrome, when the chrome displays only information chosen by the attacker. Following is an exhaustive list of the indicators found in the chrome of common web browsers, and the corresponding source of the displayed information.
The browser's window title is constructed using the
content of the HTML TITLE element from the
displayed web page. The attacker has full control over
the content of the displayed web page.
In a browser with multiple tabs for viewing multiple
web pages, the tab title also uses the content of the
TITLE element.
Both the back and forward navigation buttons provide a
drop down list of previously viewed pages. Each page is
identified by the content of the corresponding HTML
TITLE element.
The current web page's URL is chosen in tandem by the creator of the referring hyperlink and the web site operator. When an attacker is directing victims to an imposter web site, the attacker is both the creator of the referring hyperlink and the web site operator.
Some browsers provide an additional display of the hostname of the visited web site. The displayed hostname is taken from the current web page's URL. An attacker can choose any hostname that is not already in use, including ones that may deceive users. See the Hostname section for additional discussion.
The padlock icon indicates the use of SSL. The decision to use SSL, or not, is again at the discretion of the creator of the referring hyperlink and the web site operator. In a phishing scenario, the attacker still plays both these roles. When the web site operator is an independent party it may redirect a URL chosen by the attacker to an SSL protected URL; however, this redirect is delivered over the original unprotected connection.
Websites can specify a small graphic to act as an icon that appears in the URL bar in most desktop web browsers and on the tabs in some browsers [favicon] . While the desktop web browsers control this chrome, none place any restrictions on the type of websites or the content of the images that will be displayed. Consequently, an imposter web site can display the icon of an impersonated web site in the web browser's chrome.
A website may also choose to display a favicon that looks exactly like the padlock icon that is displayed in the URL bar by many browsers to indicate an SSL connection. In this case, the user may believe that SSL is being used, when it is not.
By default, the status bar displays messages from the browser, such as the target of the hyperlink under the mouse cursor. The displayed web page can also display any message of its choosing in this area.
Some desktop web browsers use a colored bar called an information bar (or notification bar) across the top of the web content window to communicate with users. These messages are specific to the content of the web content window, and usually alert the user to the fact that a potentially undesirable action has been suspended, such as the automatic installation of software or the opening of a new web content window.
While the content of the information bar is controlled by the web browser, a convincing replica of this interface can easily be created by a malicious web site and placed at the top of their content.
Employing a great deal of deception might also be unnecessary for a successful attack, since studies have shown many users have a poor understanding of the chrome. The current chrome indicators provide a thin summary of raw technical artifacts drawn from the network protocol's current exchange. The full meaning of these protocol artifacts is not necessarily understood by users.
The presence of the padlock icon in the chrome only indicates the current web page was transmitted using the SSL protocol. The icon does not denote a guarantee of trustworthiness, nor is it an indication of legitimacy; an imposter site can be accessed using the SSL protocol. On its own, the fact that SSL was used is not actionable. The fact must first be paired with many others before a warranted decision can be made. Nevertheless, some studies have shown the presence of a padlock icon, when it is noticed, contributes to a user's vague sense of security [Users' conceptions]. Relying on the padlock icon in this way is not supported by the mere use of SSL by a web page.
DNS is a hierarchical name space. Name assignments on upper layers of this name space are controlled by various policy and business processes and often thought of as identifiers for real-world entities; name assignments on the lower layers are typically choosen freely and often thought of as identifiers for individual hosts or services. However, these intricacies are not widely understood. Studies show that users will interpret brand names that occur on any level of a domain name as a signal that allows them to assume some kind of reliable association between the brand and the domain name [Security Toolbars].
Perhaps the most surprising result of user studies is that the distinction between chrome and page area does not exist in the minds of many users. Professional looking content is deemed a more reliable indicator of legitimacy. A padlock icon appearing in the page area has the same significance as one in the chrome [Security Toolbars]. Whether an indicator in the chrome is a security indicator, or a decoration set by the web page is unclear [Why Phishing Works]. Given the reality of the current functionality of the chrome, these user perceptions are quite reasonable. Current chrome is just a decoration whose content is largely, or entirely, determined by the visited web site.
Users come to an understanding of security indicators predominantly through use and direct experience, and somewhat through general awareness (discussions with others, news and other information they might receive). Users knowing about the padlock icon at all, for example, shows that user education does happen over time. Experience and history with education on using computer software indicates that users do not learn and act exactly on what is explicitly taught them (for an example of that in user security, see [Make Up Your Mind]). Explicit user education does not override other problems and consistently alter user behavior.
Even if the chrome was perfectly implemented and fully understood by users, it still might not, as currently designed, provide effective protection.
Browsing the web involves reading text, clicking hyperlinks and filling out forms; all activities which take place entirely within the web page area of the browser window. Consequently, studies have shown that users rarely consult the chrome, instead focusing on the task at hand. Even when the chrome has not been tampered with and is providing the intended presentation, it goes unnoticed by users [Security Toolbars], [Why Phishing Works].
Current chrome decorates web pages that provide security information, and remains silent about those that provide none. This design creates multiple problems.
It is difficult for humans to react to the absence of something. Studies have shown that users do not reliably notice the absence of security indicators [Why Phishing Works].
Users, and even experts, commonly attribute more security than is warranted to a web page that is not protected by SSL. A login form on such a page can be readily modified in transit such that it will send the user's login credentials to an attacker before logging the user into the authentic web site.
Desktop software commonly reports problems through modal pop-up dialog boxes. Such dialog boxes frequently appear during normal software use. Also, the user is frequently given no reasonable course of action other than clicking the OK button. Consequently, users have been conditioned to automatically dismiss such dialog boxes, often without even glancing at their content. User studies confirm this phenomena also holds for security warnings from web browsers [Why Phishing Works].
Making security usable is still a nascent area for research [Security and Usability]. There are no worked examples of standards of usable security to emulate. There are a limited number of worked examples in deployed products to learn from. There are a larger number of attempts with unclear results to learn from. Consequently, this Working Group's recommendations will necessarily contain more innovation than might a traditional standards effort. This section details the process the Working Group will employ to mitigate the significant perils of innovation in a standards effort.
By its very nature, the public reviews of the deliverables of this Working Group via the W3C standards process will provide pertinent and timely input from researchers and practitioners in a variety of disciplines, including usability and design, security, and accessibility. That feedback may be based on experience with other standards efforts, experience prototyping or developing software or devices, experience with deployment or use of software or devices, or other forms of anecdotal evidence. This data represents experience and knowledge that has not been or cannot be captured via document principles, previous studies, or the working group's testing. The Working Group will use such feedback to inform our recommendations.
Though principles and examples of usable security are scarce, expertise on the general usability of software is more plentiful. Principles of usability aim to help the user understand presented information, discover the actions that can be taken, predict the implications of those actions and so learn how the tool can be made to serve the user's needs. These aims are also a prerequisite for usable security. Listed below are design principles, drawn from the research literature, recognized by the Working Group as relevant to usable security.
An element of a user interface should include cues that help the user discover its features [Design of Everyday Things].
A user will develop a personal model of what something does and how it works. The user interface should present cues that assist the formation of this model and ensure that the actual and perceived state of the system are consistent [Design of Everyday Things].
The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order [Ten Usability Heuristics].
Persistent use of any interface will cause the user to develop habits. A user interface should leverage habit formation to shape the user's workflow [Humane Interface].
A user has only a single locus of attention, a feature or an object in the physical world, or an idea, about which they are intently and actively thinking. Humans ignore things that aren't their current locus of attention. The user's locus of attention is only held in short term memory and so will be quickly forgotten once their attention shifts. [Humane Interface].
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility [Ten Usability Heuristics].
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution [Ten Usability Heuristics].
If the user is expected to carry out a task or an action to achieve the desired level of security, they should have access to an explanation that justifies why it is necessary.
Design should begin with an understanding of the intended users. This includes population profiles that reflect training, motivation, and goals [Designing the User Interface].
With the intended user in mind, designers should formally write down user tasks [Designing the User Interface].
The cues should be displayed consistently in location and across sites and web user agents in an attempt to prevent spoofing and user confusion. [Designing the User Interface].
A growing body of research documents presentation techniques that have not proved effective in providing usable security. The results of these studies will be used to judge the expected effectiveness of presentation techniques. The Working Group will keep abreast of ongoing studies and subject potential recommendations to review by usability experts from both inside the Working Group, and from outside.
The Problems with the status quo section contains a summary of much of what has been learned about phishing. Additional results are listed below.
In Why Phishing Works, neither education, age, sex, previous experience, nor hours of computer use showed a statistically significant correlation with vulnerability to phishing.
The user must be aware that a decision is to be made, what information should be used to make the decision, and where to look for the information [Johnny].
Part of a Working Group's activities is developing code and test suites [W3C Process].
Code to demonstrate and test the WG's recommendations on display of security context information will be implemented in one or more web user agents, as extensions to them. The most likely web user agents we will use as implementation platforms are web browsers. To ensure interoperability and generality of the recommendations, they will be implemented in the context of at least two web user agents. Entrance to Proposed Recommendations required two interoperable implementations of each feature of a specification.
We are targetting three types of testing of our recommendations: functional testing, robustness testing, and usability testing [W3C Testing].
All test development and testing is iterative. The recommendations may need to be modified on the basis of all three types of testing. starts when work on the specification starts. Testing planning will include guidelines for developing tests. Test suites are typically developed when the specifications are in a reasonably stable state, such as the first full public working draft. Test development will include test execution instructions. Automation of the tests will be considered but is unlikely, as the tests will require human visual confirmation. Clear descriptions of what to expect and how to judge outcome will be part of each test.
Functional testing against the sample code and appropriate deployment configurations will verify that the recommendations can be translated to web user agent code, with no functional ill effects on the rest of the web user agent. It will show that implementations can conform to the recommendations, and that the specifications clearly define behaviors. This is also called conformance testing.
Robustness testing will verify that the recommendations are robust against spoofing attacks. Existing spoofing attacks will be documented, and new spoofing attacks aimed directly at the recommendations (both required and recommended) will be developed. All of these attacks will take the form of web site content returned to the user agent (most typically DHTML or XML that a web browser GETs).
Usability testing will verify that the recommendations provide usable display of security context information. The type of usability testing we do will depend on both the direction of our recommendations and the resources the team is able to tap into. While members of the Working Group typically develop tests, we require specific outreach in this area. One area for outreach is to parts of WG member organizations not specifically represented by active members of the WG, particularly existing usability testing groups. The other area for outreach is to organizations actively involved in usability testing of security context information, including academic and industry research organizations. At a minimum, we will find the resources to do "lo-fi" prototyping with a modest number of volunteers (10-20) for each recommendation where user feedback appears necessary [Tiny Fingers]. Volunteer participants will be found through WG member organizations. Prototyping at this level will provide feedback in early design phases at a point where needed changes can be made easily. It will also create a more user-centered design process and will help in the realization of our goals that address usability.
In addition, we will pursue resources that allow us to do more extensive usability testing, including:
Incremental testing incorporating feedback from previous iterations
Recruiting participants from broader groups which better represent target user groups, either in size or relevant characteristics
Lab testing of sample code, for example [Johnny 2]
Contextual or "in the wild" testing of sample code [Social Phishing]
More iterative combinations of the above, throughout the specification lifecycle
This note is based on input from Tyler Close, Thomas Roessler, Mary Ellen Zurko, Bill Doyle, Maritza Johnson, Phill Hallam-Baker, Hal Lockhart, Brad Porter, and the members of the Web Security Context Working Group.