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 - Track Recipients
Luigi Lo Iacono, Peter Nehren
January 18, 2016
Track Recipients
| Name | Track Recipients |
| Sources | (Garfinkel, 2005) |
| Synonyms | None |
| Context | Although most Internet users can receive and decode S/MIME-signed mail, but not all of them can do it properly. |
| Problem | How to ensure that emails can be decoded by any recipient? |
| Solution | Ensure that cryptographically protected email can be appropriately processed by the intended recipient. |
| Examples | Many organizations already keep a database of “mail preferences” stating whether customers wish to receive no mail, ASCII email, or HTML email. These databases can be extended to include other security properties.  Source: (Garfinkel, 2005) |
| Implementation | Keep a database of each mail recipient and the cryptographic capabilities of their mail clients. This database should include what was observed about each recipient, rather than the conclusions drawn from those observations. (i.e., retain the mail header that established the user had Outlook Express, rather than a database entry that says “Outlook Express”.) Give mail recipients the ability to override these settings with per-user mail preferences. |
| Consequences | Using rules and a database of exceptions, it is possible to dramatically reduce the chance of sending signed mail to an individual who cannot decode it. |
| Dependencies | None |
| Relationships | [Send S/MIME-Signed Email] |
| Principles | [No External Burden] |
| Guidelines | None |
| Check lists | None |
| Use cases | None |
| Tags | Track Recipients, Trust |
| Log history | [01/18/2016]: Added to repository |
References
Garfinkel, S.L., 2005. Design principles and patterns for computer systems that are simultaneously secure and usable (PhD thesis). Massachusetts Institute of Technology.