Security Protocol Error Presentation
- This recommendation supports the following WSC 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
- Web agents regularly encounter error conditions at the protocol layers (HTTP, SSL/TLS, X.509, etc.) that alter the risk profile and security context of a particular resource. Due to the highly technical nature of these errors (often related to cryptographic issues) the details are generally useful only to sys admins, web developers, security professionals, or the most technical end users. For the majority of web users the technical details actually lead to confusion and risky behavior. For most users the overall security context should be adjusted intuitively while hiding the details of the error condition.
- A number of security anti-patterns are observed today in the presentation of security protocol errors:
- Technical jargon is used including terms unknown to the averge user. Examples include "certificate", "SHA hash", "root authority", etc.
- User is asked to choose from among two or more possible actions without any explanation provided of the risks or consequences.
- Agent gives the user advice that is not actionable.
- User told to contact the site for help but only contact info given for the site is the URL or domain that the user is already attempting to access.
- Web agents should follow these recommendations when presenting security protocol errors:
- Allow technical user to access details of the error in a secondary user interface (UI) but hide them in the primary UI.
- Primary UI security context indictors should not reflect the specific error, but should simply indicate a failure.
- Confine technical jargon to the secondary UI.
- When user is asked to make a decision, explain the risks of each option presented.
- Do not refer the user to the destination URL or domain for assistance.
- This recommendation relies on security information primarily provided through the SSL (TLS) protocol. However it also incorporates information obtained from HTTP, DNS, and web agent.
This recommendation addresses all the WSC use cases because they all have unhappy paths that can be triggered by an error in the protocol layers.
Expected User behavior
Detailed test cases for expected user behavior could be developed by identifying every combination of a protocol error and a use case. For example, What if use case #1 is disrupted by a revoked SSL certificate? In that case the expected user behavior is for Alice to cancel her entry to the bank's web site.
Absent such exhaustive analysis, at a high level we can say the expected user behavior in all error cases is to proceed or not proceed to access the offending web resource with an appropriate understanding that an error condition was encountered that indicates an increased level of risk.
- The status quo handling of security protocol errors includes several undesirable agent behaviors (see Anti Patterns). These disrupt the web browsing experience for many users and render it confusing or unsafe. The causes of such disruptions include:
- Users ignore incomprehensible errors and enter unwittingly enter risky areas.
- Users become desensitized to all security error messages.
- Users pick among actions presented without understanding risk consequences.
- Users forced to enter a suspect site just to contact the site administrator for help.
- This recommendation was discussed by the group on 2 May 2007. See meeting minutes.
- This recommendation fulfilled ACTION-210. See the action item for details.
- This recommendation was discussed in various emails. See archive links in the action item.