W3C

Web Security Experience, Indicators and Trust: Scope and Use Cases

W3C Working Draft 25 May 2007

This version:
http://www.w3.org/TR/2007/WD-wsc-usecases-20070525/
Latest version:
http://www.w3.org/TR/wsc-usecases/
Previous version:
http://www.w3.org/TR/2007/WD-wsc-usecases-20070302/
Editor:
Tyler Close, Hewlett-Packard

Abstract

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.

Status of this Document

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.

Table of Contents

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


1 Overview

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 Goals

2.1 Document the status quo

Security information within the Working Group's scope will be catalogued, along with corresponding presentations and user interpretations reported in user studies.

2.2 Relevance of security information

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.

2.3 Consistent presentation of security information

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.

2.4 User awareness of security information

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.

2.5 Reliable presentation of security information

The Working Group will recommend presentation techniques that mitigate deceptive imitation, or hiding, of the user agent's presentation of security information.

2.6 Reduce the number of scenarios in which users need to make trust decisions

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.

2.7 Authoring and deployment techniques

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.

2.8 Best practices for other media

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.

3 Non-goals

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.

3.1 Presentation of all security information

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.

3.2 Non-HTTP Web interactions

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.

4 In scope

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.

4.1 Web interactions

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.

4.2 User agents

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.

4.3 Entity identification

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.

4.4 Third-party recommendation

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.

4.5 Historical browsing information

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.

5 Out of scope

This section enumerates a number of possible work items that the Working Group will not consider.

5.1 Protocols

The Working Group considers recommendations for lower level protocols (such as SS7, ISDN, or NANP) out of scope.

5.2 non-Web interactions

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.

5.3 Security context information for consumption by automated agents

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.

5.4 New security information

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.

5.5 Content based detection

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.

5.6 Security information about the user's computer

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.

5.7 User agent exploits

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.

5.8 User separation

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.

5.9 Content production exploits

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.

6 Use cases

We distinguish a number of properties in the basic use cases that we address.

6.1 Destination site

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.

6.2 User's navigation toward the destination site

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.

6.3 Intended interaction

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.

6.4 Actual interaction

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.

6.5 Scenarios

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

    Destination site

    prior interaction, known organization

    Navigation

    bookmark

    Intended interaction

    submission of sensitive information

    Actual interaction

    submission of sensitive information

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

    Destination site

    no prior interaction, known organization

    Navigation

    bookmark, then follows a link

    Intended interaction

    submission of sensitive information

    Actual interaction

    submission of sensitive information

    Variation

    Alice has the habit of typing her bank's URL.

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

    Destination site

    prior interaction, known organization

    Navigation

    bookmark

    Intended interaction

    submission of sensitive information, but site convinces Alice to install software

    Actual interaction

    installation of software

    Variation

    Alice has the habit of typing her bank's URL.

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

    Destination site

    prior interaction, known organization

    Navigation

    bookmark

    Intended interaction

    submission of sensitive information

    Actual interaction

    installation of software

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

    Destination site

    no prior interaction, known organization

    Navigation

    typing

    Intended interaction

    submission of sensitive information

    Actual interaction

    submission of sensitive information

    Variations

    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.

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

    Destination site

    no prior interaction, known organization

    Navigation

    typing, with error

    Intended interaction

    informal retrieval

    Actual interaction

    software installation

    Variations

    The web site can be the one advertised in the cinema, or not.

  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. The advertising is served from an advertising agency's web site, not from the bank's.

    Destination site

    no prior interaction, known organization

    Navigation

    none

    Intended interaction

    informal retrieval

    Actual interaction

    software installation

    Variations

    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.

  8. 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?

    Destination site

    no prior interaction, unknown organization (but user expects a particular organization)

    Navigation

    link or typing

    Intended interaction

    submission of sensitive information

    Actual interaction

    submission of sensitive information

  9. 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?

    Destination site

    no prior interaction, known organization

    Navigation

    any

    Intended interaction

    submission of sensitive information

    Actual interaction

    submission of sensitive information

  10. 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?

    Destination site

    prior interaction

    Navigation

    bookmark

    Intended interaction

    submission of sensitive information

    Actual interaction

    submission of sensitive information

  11. 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?

    Destination site

    prior interaction

    Navigation

    bookmark

    Intended interaction

    information retrieval

    Actual interaction

    information retrieval

    Note

    Note: This is actually a variation over use case 1, with an error condition in the SSL security mechanism.

  12. 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?

    Destination site

    no prior interaction, known organization

    Navigation

    following a link

    Intended interaction

    information retrieval or submission of sensitive information

    Actual interaction

    information retrieval or submission of sensitive information

    Note

    This is a variation over other use cases, with a specific error condition.

  13. 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?

    Destination site

    prior interaction, known organization

    Navigation

    bookmark

    Intended interaction

    any

    Actual interaction

    same

    Note

    This use case is a variation of use case 1, with a possible error condition in the SSL security mechanism.

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

    Destination site

    prior interaction, known organization

    Navigation

    bookmark

    Intended interaction

    any

    Actual interaction

    same

    Note

    This use case is a variation of use case 1, and spells out a possible error condition in the SSL security mechanism.

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

    Note

    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.

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

    Destination site

    Known, prior visit

    Navigation

    no user interaction

    Intended interaction

    software installation

    Actual interaction

    software installation

    Variations

    A pop-up window opens with a web site that visually imitates the legitimate software upgrade behavior, but is inteded to install malicious software.

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

    Note

    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.

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

    Note

    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.

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

    Note

    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.

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

    Note

    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.

7 Security information available to the user agent

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.

7.1 Provided by HTTP

  • HTTP-Auth handshake [HTTP Auth]

  • cookies [HTTP Cookie]

  • Has the page completed loading?

  • referring page

  • redirection path

  • content-type

7.2 Provided by web content

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

7.3 Provided by SSL

  • Was the content transmitted using SSL? [HTTPS] [TLS]

  • SSL server certificate chain [PKIX]

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

  • OSCP [OCSP]

7.4 Provided by IP or DNS

  • server hostname

  • server IP address

  • localhost versus intranet versus internet

  • DNSSEC [DNSSEC]

  • network diagnostic information, such as ping or traceroute

7.5 Provided by user agent

  • installed certificate authorities

  • installed search engines

  • default window layout

  • default bookmarks

  • default configuration

  • Has the user agent completed rendering of the page?

7.6 Provided by user

  • 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

7.7 Provided by third-party

  • reputation service

  • hyperlinks on visited web pages

    • introductions from friends

  • search engine results

8 Merits of the status quo

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.

8.1 Widely deployed, strong cryptography

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.

8.2 Many deceptive imitation techniques prevented

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.

8.3 Corrected implementation errors

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.

8.4 Password management

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.

9 Problems with the status quo

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.

9.1 Poorly defined area for chrome

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.

9.1.1 Picture in picture

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]

9.1.2 Visually extending the chrome

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.

9.1.3 Removing the chrome

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.

9.2 Poorly defined role for 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.

9.2.1 Browser window title

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.

9.2.2 Back and forward buttons

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.

9.2.3 URL bar

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.

9.2.4 Padlock icon

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.

9.2.5 Favicon

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.

9.2.6 Status bar

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.

9.2.7 Information bar (aka: notification bar)

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.

9.3 Poor user understanding of chrome

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.

9.3.1 Padlock icon

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.

9.3.2 Hostname

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

9.3.3 Chrome versus page

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.

9.3.4 Explanations versus understanding

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.

9.4 Poor usability of chrome

Even if the chrome was perfectly implemented and fully understood by users, it still might not, as currently designed, provide effective protection.

9.4.1 Out of sight, out of mind

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

9.4.2 Assumed safety

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.

9.4.3 Poor usability of dialog boxes

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

10 Process

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.

10.1 Expertise and experience

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.

10.2 Reliance on general usability expertise

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.

10.2.1 Affordance

An element of a user interface should include cues that help the user discover its features [Design of Everyday Things].

10.2.2 Conceptual model

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

10.2.3 Match between system and the real world

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

10.2.4 Habit formation

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

10.2.5 Single locus of attention

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

10.2.6 Aesthetic and minimalist design

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

10.2.7 Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution [Ten Usability Heuristics].

10.2.8 Provide explanations, justifying the advice or information given

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.

10.2.9 Understand the user

Design should begin with an understanding of the intended users. This includes population profiles that reflect training, motivation, and goals [Designing the User Interface].

10.2.10 Create task profiles

With the intended user in mind, designers should formally write down user tasks [Designing the User Interface].

10.2.11 Consistency

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

10.3 Learning from past efforts

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.

10.3.1 No user categories in phishing vulnerability

In Why Phishing Works, neither education, age, sex, previous experience, nor hours of computer use showed a statistically significant correlation with vulnerability to phishing.

10.3.2 The user must be aware of the task they are to perform

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

10.4 Implementation and testing

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

11 Acknowledgments

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.

12 References

Why Phishing Works
Why Phishing Works; Rachna Dhamija, J.D. Tygar and Marti Hearst; Conference on Human Factors in Computing Systems (CHI 2006); 2006.
Security Toolbars
Do Security Toolbars Actually Prevent Phishing Attacks?; Min Wu, Robert C. Miller and Simson L. Garfinkel; Conference on Human Factors in Computing Systems (CHI 2006); 2006.
Users' conceptions
Users' Conceptions of Web Security: A Comparative Study; B. Friedman, D. Hurley, D.C. Howe, E. Felten, H. Nissenbaum; Conference on Human Factors in Computing Systems (CHI 2002); 2002.
Security and Usability
Security and Usability: Designing Secure Systems that People Can Use; Lorrie Faith Cranor, Simson Garfinkel; O'Reilly; 2005.
Humane Interface
The Humane Interface: New Directions for Designing Interactive Systems; Jef Raskin; 2000.
Designing the User Interface
Designing the User Interface; Ben Shneiderman; Addison Wesley; 2005.
Ten Usability Heuristics
Ten Usability Heuristics; Jakob Nielsen; useit.com; 1994.
Design of Everyday Things
The Design of Everyday Things; Donald Norman; Doubleday; 1988.
Johnny
Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0; Alma Whitten and John D Tygar; Usenix; 1999.
HTTP Auth
HTTP Authentication: Basic and Digest Access Authentication; J. Franks, P. Hallam-Backer, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, L. Stewart; IETF RFC 2617; 1999.
HTTP Cookie
HTTP State Management Mechanism; D. Kristol, L. Montulli; IETF RFC 2965; 2000.
PKIX
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile; R. Housley, W. Polk, W. Ford, D.Solo; IETF RFC 3280; 2002.
HTTPS
HTTP Over TLS; E. Rescorla; IETF RFC 2818; 2000.
TLS
The TLS Protocol Version 1.0; T. Dierks, C. Allen; IETF RFC 2246; 1999.
EV Cert
Extended Validation SSL Certificates - A New, Higher Standard for Internet Security; CA/Browser Forum; 2006.
OCSP
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP; M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams; IETF RFC 2560; 1999.
DNSSEC
DNS Security Introduction and Requirements; R. Arends, R. Austein, M. Larson, D. Massey, S. Rose; IETF RFC 4033; 2005.
favicon
How to Add a Favicon to your Site; Karl Dubost; W3C Quality Assurance; 2006.
W3C Process
World Wide Web Consortium Process Document; Ian Jacobs; W3C; 2005.
W3C Testing
Test Development FAQ; W3C Quality Assurance; 2005.
Johnny 2
Johnny 2: A User Test of Key Continuity Management with S/MIME and Outlook Express; Simson L. Garfinkel, Robert C. Miller; Symposium On Usable Privacy and Security; 2005.
Social Phishing
Social Phishing; Tom Jagatic, Nathaniel Johnson, Markus Jakobsson, and Filippo Menczer; School of Informatics Indiana University, Bloomington; 2005.
Make Up Your Mind
Did You Ever Have To Make Up Your Mind? What Notes Users Do When Faced With A Security Decision; Mary Ellen Zurko, Charlie Kaufman, Katherine Spanbauer, Chuck Bassett; Proceedings of the 18th Annual Computer Security Applications Conference; 2002.
Designing Trust
Designing Systems That People Will Trust; Andrew S. Patrick, Pamela Briggs, and Stephen Marsh; Security and Usability: Designing Secure Systems that People Can Use, ed. Lorrie Faith Cranor and Simson Garfinkel; 2005.
web-arch
Architecture of the World Wide Web, Volume One; Ian Jacobs, Norman Walsh; W3C Recommendation; 2004.
Tiny Fingers
Prototyping for tiny fingers; M. Rettig; Communications of the ACM, April, Vol.37, No.4.; 1994.
WAI-WEBCONTENT
Web Content Accessibility Guidelines 1.0; Wendy Chisholm, Gregg Vanderheiden, Ian Jacobs; W3C Recommendation; 1999.