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

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 (see 7 Security information available to the user agent) 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.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, see 6 Use cases.

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

User interactions on the Web (see Architecture of the World Wide Web [WEBARCH]), 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 (see 3.2 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. This definition is in line with Web Content Accessibility Guidelines 1.0 [WCAG].

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

5.10 Other security challenges

As stated in the charter, the mission of the Web Security Context Working Group is to specify a baseline set of security context information that should be accessible to Web users, and practices for the secure and usable presentation of this information, to enable users to come to a better understanding of the context that they are operating in when making trust decisions on the Web. While the work this group does may have a positive and beneficial effect on other security challenges on the web, directly addressing such challenges is out of scope. This section lists several specific challenges, but the list may not be exhaustive.

6.1 User decisions

6.2 Navigation

A hyperlink is navigated from a source to a destination. Information about each may be relevant to a trust decision the user makes on the destination web page, but this information is not always available. Even when available, this information may not be meaningful to the user. The identification provided by either source or destination may not correspond to any entity known to the user.

6.3 User agent type

The use-cases address two different kinds of user agent, each distinguished by characteristic I/O features.

6.4 Accessibility

The use cases in this document make no particular assumptions about the capabilities and cultural background of the user in question. [WCAG]

• They may not be able to see, hear, move, or may not be able to process some types of information easily or at all.

• They may have difficulty reading or comprehending text.

• They may not have or be able to use a keyboard or mouse.

• They may have a text-only screen, a small screen, or a slow Internet connection.

• They may not speak or understand fluently the language in which the document is written.

• They may be in a situation where their eyes, ears, or hands are busy or interfered with (e.g., driving to work, working in a loud environment, etc.)

• They may have an early version of a browser, a different browser entirely, a voice browser, or a different operating system.

6.5 Scenarios

	Providing	Believing	Installing
Identified source, Identified destination	any any	any any	any
Identified source, Unidentified destination	any	any	any any
Unidentified source, Identified destination	any any smartphone		any any
Unidentified source, Unidentified destination	any	any any any any	any

• Identified source, Identified destination, Providing

  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.

• Identified source, Identified destination, Providing

  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?

• Identified source, Unidentified destination, Providing

  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.

• Unidentified source, Identified destination, Providing

  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.

• Unidentified source, Identified destination, Providing

  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?

• Unidentified source, Identified destination, Providing

  While on the move, Alice suddenly remembers she has to make an urgent banking transaction. She has used her mobile browser previously for retrieving information from the web, but this time she decides to use her phone due to the urgency. She starts her mobile phone browser and enters a URL that she recalls having seen on her home desktop browser. After some delay, longer than usual, the phone starts showing a page. Due to screen size, Alice notices that the layout is somewhat familiar, but still not the same as the one in her dekstop. She can't see the full URL either. Alice scrolls and spots the link that takes her to the transaction page and clicks on it. After some delay, the phone displays a page asking her to enter her usual bank credentials. How is Alice to know that her bank credentials can be safely entered into the page?

• Unidentified source, Unidentified destination, Providing

  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?

• Identified source, Identified destination, Believing

  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?

• Identified source, Identified destination, Believing

  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.

• Identified source, Unidentified destination, Believing

  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.

• Unidentified source, Unidentified destination, Believing

  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?

• Unidentified source, Unidentified destination, Believing

  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?

• Unidentified source, Unidentified destination, Believing

  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.

• Unidentified source, Unidentified destination, Believing

  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.

• Identified source, Identified destination, Installing

  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.

• Identified source, Unidentified destination, Installing

  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.

• Identified source, Unidentified destination, Installing

  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.

• Unidentified source, Identified destination, Installing

  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.

• Unidentified source, Identified destination, Installing

  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.

• Unidentified source, Unidentified destination, Installing

  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.

• Identified source, Identified destination, No interaction

  Betty tries to connect to a web site at <http://www.example.com/>. She visits this site frequently to read various news and articles. Since her last visit, the site example.com has been compromised by some method, and visitors are now being infected with malware. At the time of the current request, Betty's user agent now has information saying that example.com is a known bad site. What interaction, if any, should occur?

• Unidentified source, Unidentified destination, No interaction

  Frank regularly reads his email in the morning. This morning he receives an email that purports to be from his bank and asks him to verify a recent transaction by clicking on the link embedded in the email. The link does not display the usual URL that he types to get to his bank's website, but it does have his bank's name in it. He clicks on the link and is directed to a phishing site. The phishing site has been shut down as a known fraudulent site, so when Frank clicks on the link he receives the generic Error 404: File Not Found page. Frank is not sure what has occurred.

6.6 Threats

The scenarios provided above are vulnerable to a wide range of threats. Threats which are in scope for this Working Group are further discussed in 4 In scope. Section 5 Out of scope covers threats which, though dangerous and important, will not be directly addressed by this Working Group. A comprehensive threat tree, for both in scope and out of scope threats, is work in progress; see Web User Interaction: Threat Trees [WSC-THREATS].

7.1 Defined by web content specifications

• MIME type

  The reported MIME type, along with other information the user agent may collect, such as filename extension, affect what user agent features are triggered by the receipt of web content.

• target URI

  The target URI for an HTTP request is constructed according to the instructions provided by the web content from which the request was produced. The target URI determines the recipient of the request.

• 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, as is an HTML META tag specifying a page refresh.

• Is the rendered view composed from multiple resources, such as referenced images or stylesheets?

  The message communicated by a web page may be significantly affected by partial rendering. The web content specifies what resources the web page's author considered part of the rendered view.

• Is the rendered view composed from resources from distinct hosts?

  When a web page includes by reference a resource from another host, the rendered view may be significantly different than the page author expected. For example, the HTML IMG tag can lead to such surprises.

7.2 Defined by SSL related specifications

• 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

• revocation status

  Both CRLs [PKIX] and OCSP [OCSP] provide information about the revocation status of a certificate.

7.3 Defined by HTTP related specifications

• HTTP redirect [HTTP]

• HTTP-Auth handshake [HTTP Auth]

• cookie handling [HTTP Cookie]

• Must requests be transmitted using SSL? [HTTPS]

7.4 Defined by IP related specifications

• server IP address

• localhost versus intranet versus internet

• network diagnostic information, such as provided by ping or traceroute

7.5 Defined by DNS related specifications

• server hostname

• DNSSEC protection of hostname lookup [DNSSEC]

7.6 Defined by user agent

• installed certificate authorities

• installed search engines

• default window layout

• default bookmarks

• default configuration

7.7 State that may be collected by a user agent

• Has rendering of a page completed?

• referring page

• SSL session [TLS], if any, that protected content transmission

• 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 agent customization

• user response to prompts

7.8 Defined by a third-party

• reputation service

• other visited web pages that link to the current page

• search engine results

8.1 Widely deployed, strong cryptography

Since its first deployment, the SSL protocol has undergone multiple revisions, culminating in the current TLS/1.1 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.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.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.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.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.

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

Section 9 Problems with the status quo contains a summary of much of what has been learned about phishing. Additional results are listed below.

10.4 Implementation and testing

Part of a Working Group's activities is developing code and test suites [W3C Process].

The Working Group aims to demonstrate and test the WG's recommendations on usable and robust communication of security context information through implementations within the framework of one or more web user agents. The most likely web user agents to serve as platforms for such implementations are web browsers. To demonstrate that recommendations are sufficiently general and interoperable, we expect implementation in the context of at least two web user agents.

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. Test development starts when work on the specification starts. Test 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 Working Group is able to tap into. The Working Group aims to perform lo fidelity prototyping and testing with a modest number of test subjects (10 - 20) for each proposed practice that involves user feedback [Tiny Fingers]. This will be reflected in Candidate Recommendation exit criteria. 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.

More extensive user testing will be desirable, and is expected to contribute to higher-quality outcomes. More extensive tests may include:

• 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