ux-safety-privacy
Skill21 starsChanged 5 months agoMITView on GitHub
Safety and privacy UX: biometric authentication, passkeys, permission prompts, 2FA, GDPR compliance, data protection, and multi-device management. Use when designing or auditing authentication, data handling, permissions, or any security-sensitive flow.
In this repository17 other files it gives its agents.
- ux-accessibilitySkill
- ux-ai-automationSkill
- ux-contentSkill
- ux-error-handlingSkill
- ux-formsSkill
- ux-generalSkill
- ux-help-onboardingSkill
- ux-information-architectureSkill
- ux-navigationSkill
- ux-networkSkill
- ux-notificationsSkill
- ux-reviewSkill
- ux-searchSkill
- ux-settingsSkill
- ux-user-accountSkill
- ux-utilitySkill
- ux-visual-designSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 37
Ask for permissions in context, not on launch.
- Distinctive: line 41
Before the system permission dialog appears, show a pre-permission screen that explains what you are asking for and why.
- Distinctive: line 45
If a user denies a permission, always provide a recovery path.
- Distinctive: line 66
Use as the primary option where supported.
- Distinctive: line 80
When applying this checklist to a screen, flow, or codebase:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Safety and Privacy UX
Privacy is a user right. Security is a promise. Both must be designed for explicitly — users should not have to choose between convenience and protection.
Checklist
| Item | Guidance |
| Biometric authentication | Face ID and fingerprint are available for app re-entry and sensitive actions. |
| Storage permission prompt | Asked at the moment of use, not on launch. Explains why access is needed. |
| Location permission prompt | Request "While Using" first. Upgrade to "Always" only when strictly necessary. |
| Permissions listed | All required permissions are explained before the system dialog appears. |
| Data protection | Data is encrypted at rest and in transit. Sensitive fields are masked. |
| Multi-device management | User can view all signed-in devices and revoke access remotely from Settings. |
| Notification management | Per-type notification toggles (transactional, promotional, security). See ux-notifications. |
| Two-factor authentication | TOTP (authenticator app) available with SMS as fallback and backup codes for recovery. |
| Privacy policy link | Accessible from Settings > About and during account creation. A link, not a buried PDF. |
| GDPR compliance | Data export, data deletion, and consent management are implemented. |
| Analytics disclosure | Analytics providers are listed in the privacy policy. |
Permission Best Practices
Ask for permissions in context, not on launch. Requesting camera access when the user first opens the app feels invasive. Asking when the user taps the camera icon feels natural and logical.
Before the system permission dialog appears, show a pre-permission screen that explains what you are asking for and why. This dramatically improves the acceptance rate and reduces the chance the user denies and never comes back.
If a user denies a permission, always provide a recovery path. Show a message like "Enable in Settings > [App] > Camera" rather than silently disabling the feature.
GDPR Requirements and UX Implications
| Requirement | UX implementation |
| Right to access | "Download your data" option in Account settings |
| Right to erasure | "Delete account and all data" flow with confirmation |
| Right to portability | Data exported in a machine-readable format (JSON or CSV) |
| Consent | Separate opt-in for marketing. Pre-ticked checkboxes are not valid consent. |
| Data minimization | Collect only what is used. Delete what is no longer needed. |
| Privacy by default | The most private settings are the default, not the most permissive. |
Authentication Security Patterns
Passkeys (FIDO2): Most secure with the best UX. Resistant to phishing. Use as the primary option where supported.
TOTP 2FA: Authenticator app (Google Authenticator, Authy). 6-digit rotating codes.
SMS OTP: More accessible but vulnerable to SIM swap. Use as a fallback, not a primary.
Magic links: Passwordless email login. Single-use and expire after 15 minutes.
Biometrics: Local authentication only. Biometric data never leaves the device.
How to Review
When applying this checklist to a screen, flow, or codebase:
- Go through every checklist item and mark it Pass, Fail, or N/A — never skip items silently.
- Cite specific evidence for each finding: the screen, component, file, or line it applies to.
- Tag each failure with a severity: Blocker (breaks the experience), Major (hurts usability), or Minor (polish).
- End the review with the top 3 recommended fixes, ranked by user impact.
Related Skills
ux-user-account— login, session management, and account deletion flowsux-notifications— notification permission timing and granularityux-settings— where privacy controls liveux-accessibility— accessible authentication (WCAG 3.3.8)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.