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 - Conveying Threats & Consequences
Luigi Lo Iacono, Peter Nehren
December 21, 2015
Conveying Threats & Consequences
| Name | Conveying Threats & Consequences |
| Sources | (Egelman, 2009) |
| Synonyms | None |
| Context | In the case of critical warnings, the description text in the warning should at a minimum explain why the user is seeing the warning and what the possible consequences of ignoring the warning are. |
| Problem | Users may ignore the indicator because they do not believe it applies to them. |
| Solution | The indicator should succinctly convey the threat it is representing as well as the potential consequences of ignoring it. |
| Examples | This new SSL warning presents the unsafe option, “ignore this warning”, in very small text and away from the user’s focus of attention so that it is not immediately obvious how to dismiss the warning Source: (Egelman, 2009) |
| Implementation | The wording to describe threat details, consequences, and how to mitigate those consequences should be written succinctly without using jargon. This text should appear between the heading and options of the warning to increase the likelihood that it will be read. |
| Consequences | If users notice the indicator, but do not understand why it is appearing, they may be unwilling to follow the indicator’s suggestions. Likewise, if users notice the indicator, understand the indicator, understand the actions that the indicator wants them to take, and believe the indicator, they still may not take those actions because they may not believe that the consequences apply to them. |
| Dependencies | None |
| Relationships | [Attractive Options] [Immediate Notifications] [Active Warnings] [Warn When Unsafe] [General Notifications About Security] [Immediate Options] [Separating Content] |
| Principles | [Clarity] |
| Guidelines | [Warning Design Guidelines (Item 1)] [Guidelines used to redesign warnings (Item 2)] |
| Check lists | None |
| Use cases | None |
| Tags | Conveying Threats & Consequences, Warnings |
| Log history | [12/21/2015]: Added to repository |
References
Egelman, S., 2009. Trust me: Design patterns for constructing trustworthy trust indicators. ProQuest.