Patterns
- Active Warnings
- Attractive Options
- Complete Delete
- Conveying Threats & Consequences
- Create a Security Lexicon
- Create Keys When Needed
- Delayed Unrecoverable Action
- Detailed Notifications About Security
- Direct Access to UI Components
- Disable by Default
- Disable of Services
- Disclose Significant Deviations
- Distinguish Between Run and Open
- Distinguish Internal Senders
- Distinguish Security Levels
- Email-Based Identification and Authentication
- Explicit Item Delete
- Explicit User Audit
- Failing Safely
- General Notifications About Security
- Immediate Notifications
- Immediate Options
- Indirect Access to UI Components
- Informative Dialogues
- Install Before Execute
- Key Continuity Management
- Levels of Severity
- Leverage Existing Identification
- Localization of Specific Areas
- Migrate and Backup Keys
- Noticeable Contextual Indicators
- Providing Recommendations
- Quick Description of UI Components
- Redundant Notifications
- Reset to Installation
- Restricted Areas Notification
- Security Features Used by the System
- Security Features Used by the User
- Send S/MIME-Signed Email
- Separating Content
- Sequential Access to UI Components
- Suggestive Dialogues
- System’s Security Tasks
- The Absence of Indicators
- Track Received Keys
- Track Recipients
- Warn When Unsafe
Patterns are based on scientific sources.
Usable Security Pattern - Failing Safely
Luigi Lo Iacono, Peter Nehren
December 21, 2015
Failing Safely
| Name | Failing Safely |
| Sources | (Egelman, 2009) |
| Synonyms | None |
| Context | The recommended action should be made apparent as soon as the warning loads, and before the user is expected to read any of the other warning text. |
| Problem | If a user does not attempt to comprehend a warning and instead opts to take whatever action he or she believes will simply dismiss the warning, the warning will not serve its purpose. |
| Solution | This can be prevented by designing warnings such that if the user does not comprehend the recommended action, the warning performs a safe default action. Likewise, the default option should be the most prominent one so that it is obvious what the user should do. |
| Examples | The active phishing warning solves this problem by making the recommended option appear more prominent than the riskier alternative. Source: (Egelman, 2009) |
| Implementation | The recommended action should be the most prominent of all the possible choices presented to the user. This can occur through the use of colors (e.g. the recommended action is colored green, whereas all the others are colored black or red), text size (e.g. the recommended action appears bigger than the other choices), affordances (e.g. clicking a familiar icon results in the recommended action), etc. |
| Consequences | If a user has no interest in learning why a warning was presented, he or she may attempt to execute the quickest action to dismiss the warning, thereby continuing the primary task. If the recommended action appears to the user as the quickest way of responding to the warning, he or she will likely take this action. |
| Dependencies | None |
| Relationships | [Attractive Options] [Active Warnings] [General Notifications About Security] [Immediate Options] [Providing Recommendations] |
| Principles | [Understandability] |
| Guidelines | None |
| Check lists | None |
| Use cases | None |
| Tags | Failing Safely, Attractive Options, Active Warnings, Warnings, Notifications, Fail Safety, Fault Tolerance |
| Log history | [12/21/2015]: Added to repository |
References
Egelman, S., 2009. Trust me: Design patterns for constructing trustworthy trust indicators. ProQuest.