Privacy and Usable Security Design Guidelines

For designers and engineers: these guidelines are not about whether a product has written a privacy policy, but about whether the user can understand what their data is being used for, whether they can actually refuse, whether they can get it back, whether they can still get into their own account after losing their phone, and how much the person sitting next to them will see.

Privacy and usable security products do one thing in two halves: translate what the system does with user data and accounts into language the user can understand; and translate the user's decisions back into constraints that actually take effect inside the system. The most common design mistake in this domain is not doing nothing — it is building something that merely looks like control: a pop-up appears, a button gets clicked, a toggle gets switched off, yet the purpose is still unparseable, the decline path has three more steps than the accept path, a turned-off recommendation is rebuilt by another signal path, deletion removes only that one row of a record while the profile lives on, and an unworkable account-recovery flow leaves the user guided to call support and read out their birthday over the phone. None of these are a matter of the compliance text not being long enough — they are the product failing to honor the commitment it made to the user.

These guidelines consist of seven principles and 38 rules: principles state the design direction, rules prescribe the applicable situation, behavioral requirements, and verification method. Each rule belongs to exactly one principle, and a rule's number is the principle's number (S3-2 is the second rule under the third principle).

Two sentences in this domain deserve to be written up front, because they shape everything that follows. First: the validity of consent is determined by how it was obtained, not by whether a button was clicked. A click is a fact that occurred, not proof of voluntary, specific, informed agreement; pre-checked boxes, defaults turned on, burying decline in a third-level menu, and making accept a bright color while decline is gray text — none of these obtain consent (S2). Second: a usability defect in the recovery flow is a security defect. An unworkable recovery path does not make the user disappear — it pushes them toward a weaker one: verbal verification by support staff, a friend or family member operating on their behalf, a password written on a sticky note; therefore the abandonment rate of the recovery flow is a security metric, not an experience metric (S5-3).

Scope statementthese guidelines constrain the nature of the experience commitments a product makes to users regarding data purpose, authorization, account, and security prompts, and the mechanisms that honor them; they do not presuppose a single technical architecture. They are not a compliance checklist, not a security architecture document, and not a component library. These guidelines explicitly do not do three things: they do not make legal compliance determinations — GDPR, CCPA, PIPL, and regulations in various jurisdictions appear in these guidelines only as reference sources and scope exclusions; conforming to these guidelines does not mean conforming to the requirements of any jurisdiction. They do not prescribe cryptographic implementation — algorithm choice, key management, protocol design, and storage encryption are out of scope. They do not perform threat modeling or penetration testing — attack-surface enumeration, red-team exercises, and vulnerability rating are carried by dedicated security processes. Adopting these guidelines cannot substitute for the following dedicated assessments: a data protection impact assessment, a security review and penetration test, protection of minors, an accessibility conformance assessment, or a jurisdiction's industry-specific requirements.

Four chapters in all: Chapter 1 is principles, Chapter 2 is how to read the rules and the quick reference, Chapter 3 is the rules in detail, Chapter 4 is terminology; the validation checklist and evidence notes are in Appendices A and B, the complete sources are in reference.md, and configurable items are in Privacy and Usable Security Design Token.

---

1. The seven principles¶

The seven principles divide design responsibility by regulated object: each principle governs the obligations on one class of object, and each rule belongs to the single principle whose object is the direct regulated object of its obligation. Different objects mean the principles do not substitute for one another — this is both the basis for the division and the way to check it.

A single scenario can touch several principles at once — a user opens a budgeting app for the first time on a shared tablet, a contacts-permission request pops up, and after they agree, the app uploads their contacts for "social recommendations," and then the app pushes a lock-screen notification containing a friend's name — this one step simultaneously faces whether the purpose is resolvable (S1-1), how this consent was obtained (S2-1), whether the permission request occurred in the context of use (S3-1), the fact that the people in the contacts never consented themselves (S6-2), and an unclear lock-screen audience (S6-1). This is not a classification error: the five rules constrain obligations on five different regulated objects — one is a purpose declaration, one is the process of obtaining consent, one is permission timing, one is a third-party data boundary, one is the presentation audience. Mutual exclusivity and exhaustiveness are claims this division accepts being tested against, not facts that hold simply by being declared: when a rule is added, removed, or its ownership is in doubt, verify it against the classification check in Appendix A. If the check fails, it is the principle's division that gets revised.

The two boundaries in this division that most need continuous checking are stated here explicitly: S2 and S3 — S2 governs how this particular consent was obtained (voluntariness, symmetry, defaults, visual weight); S3 governs the permission's own timing, granularity, visibility, and the consequences of revocation. Making the "decline" button small gray text has a direct regulated object of how consent is obtained, so it belongs to S2; "why location is asked for at launch" has a direct regulated object of permission-request timing, so it belongs to S3; "still inferring location from the Wi-Fi list after location has been turned off" has a direct regulated object of the actual effect of revocation, so it belongs to S3-4. S5 and S6 — S5 governs the account holder's own holding, proving, and recovery; S6 governs the people who are not the account holder. Monitoring within an intimate relationship touches both sides: which credentials the recovery flow itself permits and where notifications are sent belongs to S5; what others can see under a shared account or family group, and whether the monitored person is aware, belongs to S6. If a dispute over ownership recurs in practice at these two boundaries, the principles should be adjusted rather than adding an intermediate layer.

Principles are used to understand the rules and to adjudicate ownership; they are not themselves a separate judgment item. When the interpretation of a principle conflicts with that of a specific clause, the applicable clause prevails, and the ambiguity needing clarification is recorded.

A rule belonging to exactly one principle does not mean a mechanism cannot be reused. A "list of declared purposes" is both the criterion for collection scope (S1-2) and the source for permission-request copy (S3-1), and also the starting point for deriving deletion scope (S4-3); a single "audience resolution" state both decides how much detail a notification preview shows (S6-1) and decides state isolation on a shared device (S6-3). One mechanism serving multiple uses is normal; which rule it is written under depends on the direct regulated object of the obligation.

2. How to read the rules¶

2.1 The structure of each rule¶

One sentence summarizing the force of each part: the rule text prescribes the requirement; "applies to" and "boundary conditions" together bound the requirement's scope of application; design application, verification examples, counterexamples, and references add no further obligation.

A rule states the nature of a behavior, not its implementation: once consent is withdrawn, the system no longer processes data on its basis — that is product behavior; the engineering method by which this withdrawn state propagates to every downstream consumer is an engineering solution — the two must line up, but they are not the same deliverable.

2.2 Normative terms¶

The rule text uses three levels of normative terms:

• MUST: failure to satisfy it means non-conformance with these guidelines. Without it, some commitment to the user would fail under a foreseeable circumstance — this is the sole basis for labeling something MUST.
• MUST NOT: the reverse expression at the same strength as MUST, identifying behavior that must not occur; in the main text, the phrasings "must not" and "is forbidden" are used equivalently, and both render as MUST NOT here.
• SHOULD: followed by default; when there is genuine reason to deviate, record the reason and the alternative, and accept the same verification. A deviation does not require approval, but it does require a record. "SHOULD NOT" is the reverse expression of SHOULD.

Conformance judgment takes the independent obligation clause in the main text as its unit: a declarative sentence with no normative term carries the strength of the heading of the rule it is in; a clause with an explicit normative term is judged at its own strength — a MUST NOT/forbidden clause inside a SHOULD rule remains a hard constraint (S1-6, S2-6, S3-2, S3-5, S4-5, S5-5, and S7-4 contain such clauses), and the strength annotation on a rule heading or the quick-reference table does not replace a clause's binding force. "Cannot" in the main text is used only for statements of capability or fact, never to express an obligation.

Strength indicates binding force, not importance.

2.3 The two sides of a counterexample¶

Counterexamples come in two sides: "under-delivery" is missing this requirement; "over-delivery" is turning the product into a consent-form recital machine in order to satisfy it. This domain gets done badly densely at both ends: at one end, user data is treated as a raw material that is available by default; at the other end, every page opened pops three layers of authorization explanation first, every click demands a second confirmation, and every setting is turned into a prerequisite exam the user must pass before they can use the product. Handing choice to the user is not the same as shifting the workload onto the user — when the system itself has grounds to make a conservative judgment, letting the user choose instead is itself a dereliction (S7-1). The same is true for security: making the recovery flow unworkable for anyone is not more secure — it is shifting the risk onto the support channel and a sticky note.

2.4 Rule quick reference: 38 rules¶

The table below is a one-line memorable version of every rule; click a rule's name to jump to the full text in Chapter 3. The quick reference does not substitute for each rule's applicability conditions and complete requirements; a few SHOULD rules contain forbidding-level clauses (S1-6, S2-6, S3-2, S3-5, S4-5, S5-5, S7-4); the main text governs the judgment (see 2.2).

S1 Purpose is understandable

S2 Consent is established by how it is obtained

S3 Permission has timing, granularity, and a trace

S4 Withdrawal, export, and deletion each stand on their own

S5 Account and recovery path

S6 Other people present

S7 Security judgment is not outsourced

3. Rules in detail¶

This chapter lays out all 38 rules organized by the seven principles. Each rule's structure and the binding force of its parts are in 2.1; the design applications, verification examples, and counterexamples within it are only explanatory material to help implementation — they specify no single component and require no separate deliverable document.

3.1 S1 Purpose is understandable¶

This principle governs the purpose the system declares for user data, in itself: whether it is specific enough, which data it covers, which recipients it points to, and what happens when it changes. Purpose is the first-class object of this domain — consent is established only against a purpose (S2), a permission has grounds only when it can state its purpose (S3), and deletion works backward from the purpose to derive its scope (S4). Once a purpose is written as a sentence that cannot be falsified, every mechanism downstream loses its criterion along with it.

S1-1A purpose is resolvable into a concrete processMUST¶

In one sentence: "Improve the service" is not a purpose; being able to state what is done, which data is used, and who gets it — that is.

Applies toany product that collects, generates, or receives users' personal data.

Ruleevery purpose MUST resolve to all four of a concrete processing action, the data categories involved, the actual consumer, and the retention period (the retention method is recorded in priv.purpose.retention.ttl). The retention period is part of the purpose declaration, not an implementation detail that can be decided later: being unable to state how long this kind of data is kept and what happens when it expires is equivalent to the purpose not yet being fully declared; processing with no retention MUST explicitly state "use and discard immediately" and the buffer's release time. A period MUST have a starting event, an expiry action, or a determinable ending event; if the ending condition has long failed to occur, there MUST be a review arrangement — "as necessary" must not be used to hide indefinite retention. Unfalsifiable phrases such as "improve the service," "enhance the user experience," "business operations," or "security and compliance purposes" do not constitute a declared purpose; "retained for the necessary period" likewise does not constitute a declared retention period; merging several unrelated processes into one general statement is equivalent to not declaring them. Instant processing, long-term personalization, manual quality review, and training general-purpose models MUST be judged separately by actual purpose; using a single permission for "generating an answer" to cover all subsequent uses is prohibited. The purpose statement MUST be available before the user makes a substantive commitment; it is prohibited for it to exist only in clause text or to require the user to compare historical clauses to discover it.

Boundary conditionsthis rule does not require disclosing internal implementation detail, algorithm structure, or vendor contract terms; what it requires is that a purpose's granularity is fine enough for the user to judge "do I want this or not." Nor does it require repeating the full statement on every screen — one lookup point, reachable from the feature, is sufficient (see S1-6 for where it is presented).

Design applicationtest every purpose against the pair of questions "what is this data used for, and what does the result affect"; if the answers to the two questions differ across different features, split it into two purposes instead of merging them into one sentence. Draw the purpose copy, the permission-request copy, and the settings-item copy from the same source to avoid three inconsistent statements.

Verification examples

• User side: have someone who did not write it read the purpose statement and then answer "who gets my location data and what do they do with it"; being unable to answer means it has not been satisfied.
• Implementation side: check whether every declared purpose maps to a concrete processing task and a list of downstream consumers; any entry that cannot be mapped is non-conforming.

CounterexamplesUnder-delivery — the privacy policy says "we may use your information to improve our products and services"; over-delivery — listing every single database write as its own independent purpose, producing a two-hundred-item list the user still cannot judge.

Basis and referencesGDPR Article 5's purpose-limitation principle and Article 4(11)'s requirement of "specific, informed" (see reference.md R11); the FTC's observation that "users are often not clearly told the actual practice when asked to consent" (R15).

S1-2Collection is bounded by a declared purposeMUST¶

In one sentence: every piece of collection must be able to point to the purpose it was collected for; if it can't, it isn't collected.

Applies toproducts with data-collection capability.

Ruleevery piece of collected data MUST be able to point to which declared purpose it serves; collection that cannot point to a corresponding purpose MUST stop. Data needed by an optional feature MUST NOT be collected while that feature has not been enabled by the user. When a declared purpose ends or a feature is retired, the corresponding collection MUST stop accordingly, and existing data is handled per S4-3. Expanding the scope of collection and expanding the purpose are two different things; expanding either does not automatically bring about the other.

Consent, access, and disposition evidence are also data processing: the record fields, readable roles, retention period, and expiry action MUST be bounded; copying complete original content to prove deletion has occurred is prohibited, and writing authentication secrets into logs is prohibited. Session recording, diagnostic reporting, and third-party analytics components MUST be included in the same review scope (priv.purpose.audit.policy; R28).

Being able to point to a purpose is only the floor, not the whole of it: for every declared purpose, the product SHOULD choose, among the options that equally accomplish that purpose, the one with fewer fields, lower precision, shorter retention, or one that can be done locally; when a broader option is chosen, record the necessity, the alternative protection, and the verification basis; a deviation from this SHOULD item is recorded per 2.2, and "a narrower option is not feasible" is not treated as the sole acceptable reason (recorded in priv.purpose.minimization.record). A very broad purpose declaration together with a matching collection map can pass the previous paragraph's check but fails this one — "there is a corresponding purpose" does not mean "this precision is necessary."

Boundary conditionsthis rule does not prohibit collecting data for security protection, fault diagnosis, or statutory obligations — but these are likewise purposes, and MUST likewise be declared per S1-1; being "technical" does not exempt them from declaration.

Design applicationbuild the mapping from collected items to purposes as an auditable table, rather than scattering it across each module's tracking-event definitions; require a newly added tracking event to state the declared purpose it corresponds to — if it cannot state one, route it through the purpose-addition flow (S1-5).

Verification examples

• Implementation side: extract the list of fields currently actually being reported and trace each one back to a declared purpose; a field that was "added historically, and nobody uses it now" is non-conforming.
• User side: after turning off an optional feature, check whether the data unique to that feature is still being reported.

CounterexamplesUnder-delivery — the contacts and precise location are requested at sign-up, even though both are only needed once an optional social feature is enabled; over-delivery — to comply strictly, copying the same log into five separately stored copies by purpose, which actually expands the data surface.

S1-3Derived data is bound by the same purposeMUST¶

In one sentence: what's computed and what's inferred are governed the same as what's collected.

Applies toproducts that infer, aggregate, profile, extract features from, or vectorize user data.

Ruleinferences, profile labels, ranking weights, embedding vectors, and aggregated features derived from user data MUST be bound by the same purpose declaration as their source data, or separately declared as an independent purpose per S1-1; excluding derived data from the governance of purpose, withdrawal, and deletion on the grounds that "this isn't data the user provided" is prohibited. The scope in which derived data may flow must not be broader than that of its source data.

Boundary conditionsthis rule does not prohibit generating derived data, nor does it require showing the user the technical form of every piece of derived data; what it requires is that derived data stays consistent with its source in purpose, sharing scope, and deletion scope, or is separately declared.

Design applicationin the data dictionary, tag every derived field with its source field and the purpose it inherits, so that deletion and withdrawal can be executed along that chain; do not treat a "feature store" as an ungoverned intermediate layer.

Verification examples

• Implementation side: after deleting a category of source data, check whether the user-level features, labels, and recommendation weights trained or generated from it become invalid at the same time.
• User side: after a user withdraws a purpose, observe whether features that depend on labels derived under that purpose stop using those labels.

CounterexamplesUnder-delivery — the user deletes their browsing history, but the interest labels generated from it remain in the profile and continue to be used for targeting; over-delivery — treating every model parameter as personal derived data, and demanding a retrain of the entire model because of one user's deletion request, so that no deletion can ever actually be carried out.

S1-4A data destination names a resolvable partyMUST¶

In one sentence: "partners" is not a destination; a list is.

Applies toproducts that transmit user data to a party outside the product, including embedded third-party SDKs.

Rulea data recipient MUST resolve to a specific party or to a risk-determinable category of party plus a queryable list; "partners," "affiliated companies," "third-party service providers," or "vendors necessary to provide the service," appearing alone, do not constitute a resolvable destination. The list MUST be queryable, marked with its last-updated time, and MUST cover transmissions initiated by third-party components embedded in the product. Adding a recipient is handled per S1-5.

Boundary conditionsthis rule does not require disclosing commercial contract terms, settlement methods, or technical interface detail; nor does it require listing a destination for every single network request. What it requires is that the user can judge, on this basis, "where will my data leave this company and go."

Design applicationinclude embedded third-party SDKs' data behavior in the same list, rather than logging only in-house service calls; a transmission change caused by an SDK update is handled as a change.

Verification examples

• Implementation side: capture the outbound requests of one typical session and trace each destination back to a list entry; any destination not listed is non-conforming.
• User side: the user can look up the current recipient list without contacting support.

CounterexamplesUnder-delivery — the privacy policy says "we may share information with partners to provide a better service," while eleven advertising and analytics services are actually integrated; over-delivery — listing CDN nodes, log proxies, and other infrastructure that carries no personal data one by one, bloating the list until users cannot finish reading it.

Basis and referencesApple's requirement that apps disclose third-party SDK data-collection behavior, with privacy manifests improving accuracy (R16); the FTC's record of vague wording used to mask the actual scope of sharing (R15).

S1-5A purpose change must not silently expandMUST¶

In one sentence: a new purpose needs a newly obtained basis; old data does not automatically follow along.

Applies toa product already live with a declared purpose that subsequently adds, expands, or changes its data purpose.

Rulewhen adding a purpose or expanding the scope of an existing one, the product MUST re-establish the processing basis for that purpose — one based on consent re-obtains consent per S2, one based on another basis re-confirms and records it per that basis's own conditions for establishment (recorded in the basis.ref of priv.consent.basis) — and MUST give notice before it takes effect. The fact that the original basis no longer holds MUST NOT itself be used as a reason to switch to another basis: when consent is missing, has lapsed, or has been withdrawn, processing that relied on that consent stops, rather than being relabeled under another basis (see S4-1 and the Token's capability-dependency table). Data collected under the old purpose does not enter the new purpose by default; for it to do so requires a separate statement and a separately obtained basis. The change notice MUST state what changed, when it takes effect, and what it affects for existing data; using "terms have been updated, continued use constitutes acceptance" as a method of obtaining consent is prohibited (see S2-1).

Boundary conditionsthis rule does not constrain narrowing a purpose — stopping a purpose or shrinking the range of recipients does not require re-obtaining a basis, but notice should still be given. Fixing a defect or changing a vendor without changing the purpose or data category may still count as the same purpose, but the recipient and processing boundary MUST be re-checked; the same purpose does not exempt recipient notice or a basis-applicability assessment.

Design applicationmake "does this change alter the purpose, data category, or recipient" a launch-checklist item, rather than judging it only during a legal review; when a change notice is merged with a product-update note, do not bury it as the seventh bullet in a feature list.

Verification examples

• Implementation side: pull the last three change records involving data processing and check whether a purpose determination was made and recorded for each.
• User side: after a change takes effect, check whether old data has entered a new purpose without the user being separately notified.

CounterexamplesUnder-delivery — a shipping address originally used for order fulfillment is used, after a feature adjustment, for in-store advertising targeting, noted only as "improved recommendations" in the changelog; over-delivery — triggering a full re-authorization for every minor interface-copy tweak, training the user to just click "agree" every time.

S1-6A user can look up the currently effective purpose and destinationSHOULD¶

In one sentence: let people see "what it's being used for right now," instead of having to compare historical clauses.

Applies toproducts with multiple data purposes or multiple recipients.

Rulethe product SHOULD provide one queryable place for "the currently effective purposes and destinations," presenting the purposes actually enabled on this account right now, the corresponding data categories and recipients, and marking the most recent update time. Making this information's only form a diff the user must derive by comparing historical clauses themselves is prohibited. This entry point SHOULD be mutually reachable with the withdrawal, export, and deletion entry points (S4-1).

Boundary conditionsthis rule does not require showing every data access in real time; nor does it require a new dedicated page for this — embedding it in the existing account and settings area is sufficient. If a product has only a single purpose with no outward transmission, recording "not applicable" is sufficient.

Design applicationorganize this page around "this account's current state" rather than "things we might do"; point the toggle next to each purpose directly to the withdrawal action in S4-1, avoiding a state the user can see but cannot change.

Verification examples

• User side: have the user state within three minutes "what I turned off and what's still on."
• Implementation side: check whether the set of purposes shown on this page and the actually effective processing configuration come from the same data source.

CounterexamplesUnder-delivery — there is only a thirty-page privacy policy and an "update summary," and the user has to compare the two to find out what's new; over-delivery — building a technical dashboard that lists every background job, where the user sees queue names instead of purposes.

3.2 S2 Consent is established by how it is obtained¶

This principle governs exactly one thing: the single interaction of obtaining consent and authorization. It does not govern what the data is used for (that is S1), nor how the permission is used after authorization (that is S3). What it governs is — when asking, was there room left to genuinely say no. The default, path length, the color and position of the button, how many more times it asks after being declined — all of these are part of how it was obtained; whether consent is established is judged by these, not by the click record in a log.

S2-1The validity of consent is determined by how it was obtainedMUST¶

In one sentence: clicking does not mean consenting; a pre-checked box and "continuing to use means you agree" are both invalid.

Applies toscenarios that use user consent as the processing basis, including permission authorization, data-sharing authorization, marketing authorization, and personalization authorization.

Ruleconsent MUST be expressed by the user's explicit, affirmative act, and that act MUST target a resolvable, specific purpose (see S1-1). The following methods of obtaining consent are prohibited from being recorded as consent: a pre-checked option, a toggle on by default, silence or inaction, "continuing to use means you agree," bundling several unrelated purposes into one toggle, and a click obtained under conditions where the user cannot read it or cannot exit. A click is a fact that occurred, not proof of voluntary, specific, informed agreement; the burden of proof lies on the product's side, and the method of obtaining it MUST be reproducible and auditable.

Boundary conditionsthis rule does not require that all processing rely on consent as its basis — processing under contract performance, statutory obligation, or another lawful basis is not subject to this rule, but the product MUST be able to state what basis it relies on, and MUST NOT fabricate a consent "just to be safer" for processing that did not need one. This rule makes no jurisdictional determination (see the scope statement).

Design applicationuse "purpose" as the unit of consent, not "the pop-up"; record the outcome obtained for each of several purposes in the same pop-up separately. When saving a consent record, save a snapshot of the copy and interface shown at the time along with it, or the method of obtaining it cannot be proven afterward.

Verification examples

• User side: complete the first-run flow without clicking any "agree," and check whether processing that depends on that consent has already begun; other processing MUST have an independently established basis beforehand.
• Implementation side: pull the consent record and check whether it contains the purpose identifier, time, copy snapshot, and method of obtaining it; a boolean value alone is non-conforming.

CounterexamplesUnder-delivery — a small line of text at the bottom of the sign-up page reads "by clicking register, you confirm you have read and agree to the Privacy Policy and Personalization Rules," which includes sharing with third parties; over-delivery — turning every single purpose into a flow that must be read clause by clause and confirmed by typing a confirmation word, so the user starts clicking mechanically after the fourth one, which likewise does not obtain informed consent.

Basis and referencesGDPR Article 4(11)'s definition of consent (freely given, specific, informed, an unambiguous affirmative act) and Article 7's requirements for the conditions of obtaining it (R11, R12); the EDPB's classification of deceptive design patterns files this kind of obtaining method under "skipping" and "left in the dark" (R14); the FTC recorded the pattern of "appearing to offer choice while the choice is actually illusory" (R15). W3C's Privacy Principles (the W3C Statement) further notes that consent mechanisms are often used to avoid the judgment of "which processing is appropriate," thereby shifting privacy labor onto the person using the system (R22) — this is one of the reasons these guidelines place the obligation on the purpose declaration (S1) rather than on the consent flow.

S2-2Accept and decline paths are symmetricMUST¶

In one sentence: declining cannot be farther away, harder to find, or less visible than accepting.

Applies toan authorization interface that offers the user an accept/decline choice (or a multiple choice).

Rulethe decline path's step count and entry depth MUST NOT exceed the accept path's, and its discoverability MUST NOT be lower than the accept path's — the "better" direction differs across these three, so they cannot be judged with the same comparison word. Recording a difference between the two paths and its reason serves only to explain a measured difference; it does not exempt this rule's MUST-level requirement for decline reachability. Offering only a combination of "accept all" and "manage settings" with no same-level "decline all" is prohibited; placing decline somewhere that requires scrolling, expanding, or navigating away, while accept sits on the first screen, is prohibited. If accept can be completed in one tap, decline MUST also be completable in one tap.

Boundary conditionswhat this rule requires is path symmetry, not that the two options be semantically equivalent — a product may explain what will be lost after declining, provided that explanation is truthful and does not constitute the conditioning prohibited by S2-4. Nor does it require the two buttons to have identical visual styling (visual weight is covered by S2-6); what it requires is symmetric reachability.

Design applicationcompare item by item "how many clicks, scrolls, and navigations it takes to complete a decline" against the accept path, and record the difference; if the difference is not zero, a reason must be given.

Verification examples

• User side: time how long a new user takes to complete "accept all" versus "decline all."
• Implementation side: check whether the decline entry remains reachable on the first screen on a small mobile screen, at low resolution, and with enlarged text.

CounterexamplesUnder-delivery — on a cookie banner, "accept all" is one button, while "decline all" requires first clicking "manage preferences," then turning off twelve toggles one by one, then clicking "save"; over-delivery — for the sake of symmetry, also making "accept" require enabling items one by one, so a user who wants the feature cannot finish the configuration.

Basis and referencesthe EDPB classifies this kind of design as an "obstructing" category of deceptive design pattern (R14); the FTC recorded the pattern of "deliberately hiding privacy choices, making them hard to access" (R15); Nouwens et al.'s field experiment on consent-management interfaces reports that the decline entry and option granularity affect user choice (R10, a historical single-scenario study, not adopted as a universal effect size).

S2-3The default takes the most conservative tierMUST¶

In one sentence: before a choice is made, treat it as no collection, no sharing, no personalization.

Applies toprivacy and authorization settings that have a default value.

Rulebefore the user has made a choice, the system MUST operate at the most conservative tier: no non-essential data collection, no outward sharing, no personalization, no public visibility. Unknown circumstances are resolved conservatively — an unknown audience is treated as visible to others (S6-1); an unknown age does not expand optional processing, and identity proof is not additionally collected merely to eliminate the unknown; when the jurisdiction is unknown, first narrow optional processing, and if the basis for necessary processing cannot be confirmed, pause that path and hand it to the owner to decide, rather than assembling some self-styled "stricter" rule on one's own. Setting the default to on on the grounds that "the user can turn it off at any time" is prohibited. Changing a default value is equivalent to a configuration change and is notified per S1-5.

Boundary conditionsthis rule does not require turning off the product's core functionality by default — processing necessary to complete a task the user has already chosen does not fall within the "non-essential" scope this rule constrains. The basis for judging necessity MUST be recorded and reviewable, not self-declared by the feature owner.

Design applicationtreat the "list of default values" as an independently auditable configuration, rather than scattering it across each feature's initialization code; every change to a default value requires stating its basis.

Verification examples

• Implementation side: run a typical session on a brand-new account with no settings made, and record the collection and sharing that actually occurs.
• User side: check the state of a setting the user has never opened.

CounterexamplesUnder-delivery — a new account defaults to "show my activity to friends" and "use for personalized ads" both on; over-delivery — defaulting privacy-unrelated preferences such as language, time zone, and dark mode to empty as well, so a first-time user is confronted with a blank configuration form.

S2-4Trading functional availability for consent is forbiddenMUST¶

In one sentence: "no consent, no use" is not a choice.

Applies toproducts that request authorization for non-essential processing.

Ruleprocessing unrelated to the requested feature is prohibited from being made a condition for using that feature or service. After the user declines, the core feature MUST NOT be degraded, MUST NOT have extra waiting inserted, and MUST NOT be repeatedly prompted about being in a restricted state. Inducing the user to consent to non-essential processing with rewards, points, unlocked content, or a lottery is prohibited. If some processing is genuinely necessary to provide the feature, the product MUST be able to state that necessity and declare it per S1-1.

Boundary conditionsthis rule does not require a product to provide a feature that cannot be implemented — map navigation genuinely needs location, a camera genuinely needs the camera; processing that is intrinsically necessary to the feature does not fall under the "trading" this rule prohibits. The distinction is: after declining, is what is lost the feature itself, or some other, unrelated capability. Whether a business model in which payment substitutes for free personalized advertising is valid is a jurisdictional determination, outside the scope of these guidelines.

Design applicationfor every feature that becomes "unavailable after declining," write one sentence: "because this feature needs it to do X"; if that sentence cannot be written, it is not necessary.

Verification examples

• User side: after declining all optional authorizations, walk through the product's core task path and record which steps are blocked.
• Implementation side: check whether the blocked steps genuinely depend on the declined processing.

CounterexamplesUnder-delivery — after declining "personalized ads," the app's order-history lookup now requires re-logging-in every time; over-delivery — to avoid any suspicion of "trading," making a navigation feature that genuinely needs location work with no location available, resulting in a wrong route.

Basis and referencesApple explicitly requires that an app must not restrict functionality or trade an incentive for consent after a user declines a tracking request (R16); GDPR Article 7(4) requires assessing whether a service was made conditional on non-essential processing (R12).

S2-5Do not ask repeatedly after a declineMUST¶

In one sentence: once asked is asked; asking again through a different entry point is still the same ask.

Applies toproducts where an authorization can be declined by the user.

Rulea repeated request for the same authorization after it has been declined MUST have a cap on frequency and a new reason; re-initiating it through a different entry point, different copy, or different timing counts toward the same authorization's repeat count. Popping it up again every time the user enters the related feature is prohibited, as is disguising a repeated request as a feature tip, a red dot, or a must-read announcement. Once the user has explicitly indicated "don't ask again," the system MUST NOT proactively initiate that request again, retaining only a settings entry the user can find on their own.

Boundary conditionsthis rule does not prohibit asking again when the user proactively tries to use a feature that requires that authorization — that is user-initiated and does not count toward repeated asking. Nor does it prohibit re-requesting when the actual use of the authorization has substantively changed, but the change MUST be explained per S1-5.

Design applicationbuild the counting and cap for repeated requests as a mechanism-layer constraint rather than having each feature module judge it independently; the cap and window are defined by the product with a recorded rationale — these guidelines give no numeric value.

Verification examples

• User side: after declining an authorization, use the product continuously for two weeks and record how many times and in what scenarios the request reappears.
• Implementation side: check whether the same authorization request, initiated from different entry points, shares the same counter.

CounterexamplesUnder-delivery — a notification-authorization pop-up appears every time the app is opened, and starting on the third time the "later" button is turned into small gray text; over-delivery — after the user declines once, the system permanently never offers any entry point again, so the user later wants to turn it on but cannot find where (this violates S4-1's requirement of separately executable actions).

Basis and referencesAndroid's permission guidelines explicitly state "don't continually pester the user to reconsider after they decline," and note that repeated denials may cause the system to stop showing the permission dialog again; the applicable conditions MUST be checked against the target platform (R17); the FTC recorded the pattern of "repeatedly prompting users to choose a setting they wish to avoid" (R15).

S2-6Do not create a bias through visual or verbal weightSHOULD¶

In one sentence: two options need to look like two options.

Applies tointerfaces presenting privacy and authorization choices.

Rulean option's visual weight and verbal weight SHOULD be proportionate to its consequence, and SHOULD NOT be designed to bias the user toward one side. The following are prohibited: making the favored side a solid, high-contrast button while making the other side a low-contrast text link; using guilt- or fear-inducing copy on the decline side ("No, I don't care about my safety"); using double negatives or vague wording that makes an option's meaning hard to discern; using the completion pressure of another task to ask for an optional authorization unrelated to that step (for example, inserting an ad-personalization choice right before order submission); and applying time pressure via a countdown or a scarcity prompt.

Boundary conditionsa permission request necessary to complete the step the user actively chose may appear at that step — a user tapping "take photo to submit" and a camera-permission prompt then appearing is exactly the in-context request S3-1 requires; what this rule prohibits is an optional authorization unrelated to that step riding on this moment. In either case, the path to decline and exit MUST be preserved. This rule does not require identical styling on both sides — following platform convention by making the primary action the primary button is acceptable, provided the judgment of "primary action" is not based on the product's data gain. Nor does it prohibit explaining the actual consequence of declining, as long as that explanation is truthful (see S2-4).

Design applicationtabulate the contrast, area, position, and copy tendency of the two sides, and hand it to someone not involved in the design to judge "which one does this interface want me to pick"; if the answer is consistent and aligned with the product's interest, a bias exists.

Verification examples

• User side: show interface screenshots to someone not involved in the design and have them point out "which one the designer wants the user to click."
• Implementation side: check the contrast, clickable area, and focus order of the two buttons.

CounterexamplesUnder-delivery — "turn on smart recommendations, get content that understands you better" is paired with a large bright button, next to small gray text reading "maybe later"; over-delivery — making both options identical gray text and randomizing their position, so the user can neither see the consequence nor find the one they wanted.

Basis and referencesthe EDPB classifies this kind of practice under "stirring," covering emotional manipulation and visual obscuring (R14); the FTC recorded "highlighting options that lead to more data collection while downplaying options that limit such behavior" (R15); Utz et al. observed in a large-scale field experiment that notification position and how options are presented have a considerable effect on user choice (R09, the sample limited to a single site, no fixed layout is adopted on this basis).

3.3 S3 Permission has timing, granularity, and a trace¶

This principle governs the system's access permission to device capability and account resources: when to ask, how fine a tier can be granted, whether it is visible while in use, and what happens after revocation. Its division of labor with S2 is clear — S2 governs whether that one ask left room to say no; S3 governs the permission itself as an object. A product can make its pop-up entirely free of inducement (satisfying S2), yet still ask for six permissions all at once on the very first launch screen, and still compute the same thing back from other signals after they are turned off (violating S3). The smallest unit of a permission is not "grant or not," but for how long, at what granularity, and visible to whom.

S3-1The request occurs in the context of useMUST¶

In one sentence: ask for it when it's used, and state clearly what this instance will do with it.

Applies toproducts that request device-capability permission or account-resource access permission.

Rulea permission request MUST occur in the scenario where the permission is about to actually be used, stating what this instance will use it for and what the result affects. Requesting a batch of permissions unrelated to the current step at first launch, during sign-up, or on a welcome screen is prohibited. The request copy MUST be drawn from the same source as the purpose declared in S1-1; saying one thing at request time and writing another in the privacy policy is prohibited. One request corresponds to one purpose; when several purposes are merged into one system permission dialog, each purpose MUST be separately explained before it is initiated (whether consent is obtained is still judged per S2-1).

Boundary conditionsthis rule does not prohibit explaining in advance, at a feature's entry point, "what permission will be needed next" — a preview and a request are two different things, and a preview that does not trigger the system dialog is not bound by this rule's timing requirement. When a product genuinely needs a permission at install or first configuration (such as notification permission for an instant-messaging product), it may request it when the corresponding feature first becomes available, without needing to wait for the first message to arrive.

Design applicationwrite one sentence for every permission: "what the user is doing right now, and so it's asked now"; if that sentence cannot be written, it means the request timing is wrong, not that the copy needs another polish. The system dialog's copy space is usually limited, so put the rationale in a lead-in screen in the product's own interface, leaving the system dialog to carry only the authorization itself.

Verification examples

• User side: walk through the first three minutes on a fresh install and record how many permission dialogs appear and what the user was doing when each one did.
• Implementation side: check whether every permission-request point sits on the call path of the corresponding feature; any request point unrelated to the call path is non-conforming.

CounterexamplesUnder-delivery — a budgeting app pops up four system dialogs in a row for contacts, location, notifications, and photos on its launch screen, before the user has seen any feature; over-delivery — turning the explanation into a five-screen tutorial that must be read screen by screen, blocking the user in the tutorial flow right when they genuinely need to take a photo to log an expense.

Basis and referencesAndroid's permissions documentation states "request the permission in context, when the user starts to use a feature that requires it," and recommends deferring the request as late as possible in the use-case flow where feasible (R17). Apple's documentation permits a pre-explanation screen before the system tracking-authorization dialog, but the material read so far does not prescribe "requesting in context" as a requirement (R16) — this rule's timing requirement is these guidelines' own design position, not a restatement of any one platform's clause.

S3-2Offer a tier smaller than "always allow"SHOULD¶

In one sentence: only this once, only while in use, or a vague location — these should all be options.

Applies topermissions that can be requested at graduated levels (location, microphone, camera, photo library, contacts, health data, etc.).

Rulewhen the platform or product is able to offer a finer-grained authorization tier, it SHOULD offer it as a user-selectable tier, rather than offering only "always allow" and "deny." Available smaller tiers include, but are not limited to: this time only, only while in use, approximate rather than precise, a partial selection rather than full access. Presenting the smaller tier in the interface with negative phrasing such as "restricted mode" or "incomplete feature" to push the user toward the larger tier is prohibited (this is also governed by S2-6). When the product's own capability is sufficient to work under a smaller tier, offering only the largest tier on the grounds of "implementation complexity" is prohibited.

Boundary conditionswhen the platform does not offer graduated capability, this rule does not require the product to simulate a fake tier that cannot be enforced at the mechanism level — that would give a stronger protection promise than actually exists. This limitation should be recorded in that case. This rule does not require defaulting to a behavioral constraint beyond selecting the smallest tier; defaults are covered separately in S2-3.

Design applicationtake "can this feature still complete its core task at the smallest tier" as the design starting point, rather than implementing at the largest tier first and considering degradation afterward; the latter leaves the smallest tier permanently in a "poor experience" state, effectively discouraging users from choosing it.

Verification examples

• User side: complete a typical task after selecting the smallest tier, and record any steps that are blocked or noticeably degraded.
• Implementation side: check whether the code's handling of the permission result covers every platform tier, rather than distinguishing only "granted" versus "not granted."

CounterexamplesUnder-delivery — a weather app accepts only "always allow precise location," and shows "cannot provide service" when approximate location is chosen; over-delivery — turning every single read into its own separate authorization, so a user tidying their photo library is asked to confirm forty times.

Basis and referencesstarting with Android 11 (API 30), the location, microphone, and camera permission dialogs offer an "Only this time" option (R17). The equivalent tiers on other platforms were not individually verified this time; uniformity across platforms is not claimed on this basis.

S3-3Visible while it is being usedMUST¶

In one sentence: the user needs to be able to see the fact that the microphone is on.

Applies toproducts that access the microphone, camera, location, screen content, or other sensitive sensors in the foreground or background.

Rulewhile a sensitive capability is being actively accessed, the user MUST be able to know this fact. When visibility is carried by a platform indicator, the product MUST NOT obscure, disguise, or evade that indicator with an overlay; when the platform provides no indicator, the product MUST provide an equivalent active-state presentation within its own interface. Background access MUST have clearer visibility and a queryable record than foreground access. Once access ends, the state presentation MUST end accordingly — continuing to show an indicator that does not correspond to actual access is just as wrong as showing none.

Boundary conditionsthis rule does not require presenting the technical detail of every single data read in real time, nor does it require an indicator for ordinary network requests that do not involve a sensitive sensor. When a product adds its own indicator in addition to a platform-mandated one, it must not thereby claim to offer a stronger guarantee than the platform.

Design applicationtreat "active access" as an explicit product state, rather than sensor handles scattered everywhere; with this state, the indicator, the log, and revocation (S3-4) can then read from the same source.

Verification examples

• User side: in each of the call, recording, and background-location scenarios, check whether the user can judge "it is currently capturing" without entering settings.
• Implementation side: check whether the active state turning on and off matches the actual sensor session's lifecycle, and whether there is a window where capture continues after it turns off.

CounterexamplesUnder-delivery — an app continuously collects location in the background, and the user can only discover it afterward in the system's battery-usage statistics; over-delivery — during recording, covering the content the user is currently filling in with a red warning layer spanning half the screen, making the normal task impossible to complete.

S3-4Behavior genuinely changes after a decline or a withdrawalMUST¶

In one sentence: turning it off means it's no longer used — it can't be computed back through a different path.

Applies toproducts that provide the capability to decline or revoke a permission.

Rulethis rule constrains device-capability access. After a user declines or revokes a permission, the system MUST stop the affected new access; when handling in-flight collection, it MUST block access not yet completed and state the scope of data already obtained. Covertly restoring the declined capability or precision through another sensor, a fingerprint, or a network cue is prohibited. Revocation MUST take effect at the actual access checkpoint, not merely change an interface toggle; accepting a revocation request and the actual stopping at each execution point are two different things and MUST be reported separately. When an external processor has not yet confirmed stopping, the not-yet-completed scope MUST be retained; a product-side toggle must not be used to infer backward that all copies or already-issued access credentials have become invalid. Revoking a device permission by itself does not delete historical data, nor does it automatically withdraw an independent data-processing consent; if the interface promises "stop location-based recommendations," the purpose deactivation in S4-1 MUST also be carried out. The system MUST let the user identify the object of this action, when it took effect, and what scope has not yet taken effect.

Boundary conditionswhen the user proactively chooses a substitute path, their input may be used per a declared purpose: manually selecting a city to check the weather after turning off location is a legitimate path; covertly recovering precise tracking via IP in the background is a bypass. Existing historical data continues to be used only while the original processing basis still holds and the purpose and period have not been exceeded; a "historical copy" must not be used to continue a purpose the user has already deactivated.

Design applicationverify every access against the authoritative authorization state; caches, background tasks, and third-party components honor the propagation of a revocation, and when contact is lost, do not continue affected new access. The interface presents both "location access has been stopped" and "historical records are still retained, and can be deleted separately."

Verification examples

• User side: turn off location, and identify which features stop and which historical content is still retained; the weather can still be checked after manually selecting a city.
• Implementation side: revoke the permission during collection, covering at minimum the current connection, the offline queue, already-issued access eligibility, and third-party processing paths; check sensor access, background queues, and substitute signals; check only the affected scope, and do not uniformly judge historical data that has an independent basis as non-conforming.

CounterexamplesUnder-delivery — after turning off precise location, the product switches to continuously computing precise location from a network fingerprint instead; over-delivery — turning off location deletes all saved places and refuses a user's manually entered city.

Basis and referencesAndroid's permission guidelines require checking the permission when it is used, and providing a usable fallback for a decline (R17). The semantic separation of stopping access, deactivating a purpose, and deleting history is a design requirement these guidelines impose to avoid false control.

S3-5A long-unused authorization automatically narrowsSHOULD¶

In one sentence: a long-idle authorization should narrow, with a deadline set by actual use.

Applies toproducts that hold a long-lived authorization.

Rulean authorization that has gone unused, in practice, for a period the product defines with a recorded rationale, SHOULD automatically narrow or be revoked, and re-requested the next time it is used. When the platform already provides automatic reset capability, the product is prohibited from maintaining the authorization through an evasion mechanism (such as a background task that periodically triggers an access with no actual purpose). When an authorization has been narrowed or revoked and is then re-requested, the timing requirement of S3-1 applies, and it does not count toward S2-5's repeat-request count. Narrowing SHOULD be visible to the user, and must not leave the user thinking the feature is broken.

Boundary conditionsthis rule does not apply to a permission the product's core feature continuously depends on — an app that continuously logs an exercise route should not lose its background-location authorization just because the user has not opened the interface in three months, but such an exception MUST be listed with its rationale stated. Nor does it require the product to reimplement its own narrowing logic when the platform has already implemented automatic reset.

Design applicationrecord "the most recent actual use" against every authorization, rather than recording only "whether authorized"; without this timestamp, this rule cannot be executed or verified.

Verification examples

• Implementation side: pull the distribution of most-recent-use times across authorizations, and check for any that are long empty but still in the authorized state.
• User side: re-enter a feature after not using it for a long time, and check whether the system re-explains the purpose rather than silently using it directly.

CounterexamplesUnder-delivery — the user authorized contacts once three years ago, has never used that feature since, and the authorization has remained valid the whole time; over-delivery — reclaiming authorization for a feature the user uses once a week as "infrequently used," forcing the user to re-authorize every single time they use it.

Basis and referencesAndroid app hibernation resets permissions when platform conditions are met, and has device preconditions and exemptions (R25); a product MUST verify this against its target environment. Platform reclamation can carry this mechanism; it does not require re-implementing a timer, nor does it support deriving a uniform idle-day count from it.

3.4 S4 Withdrawal, export, and deletion each stand on their own¶

This principle governs the disposition a user exercises over data already handed over. Three things MUST be kept separate: withdrawal makes the system stop processing under a given purpose going forward; export gives the user a copy they can actually use; deletion makes the data disappear along with everything produced from it. Turn them into the same button, and a user who only wants to stop recommendations will lose three years of favorites, or a user who wants to wipe everything clean will end up merely switching off one toggle. The most common failure in this domain is not the absence of an entry point, but that the entry point was provided, execution was incomplete, and the state could not be clearly stated — the user clicks delete, sees "your request has been submitted," and never hears anything again.

S4-1Withdrawal and deletion are two different thingsMUST¶

In one sentence: stopping continued use and wiping out what already exists must be doable, and statable, separately.

Applies toproducts that store user data or process it based on user authorization.

Ruleevery control MUST make clear which class of object it acts on — device-capability access, processing under a specific purpose, or data within a specified scope. The product MUST provide separate controls for the applicable objects and state each one's consequence:

• Revoking capability access: immediately stop the corresponding new access (S3-4); historical data is not automatically deleted.
• Deactivating a purpose: stop that purpose's subsequent processing, and prohibit continuing that deactivated purpose using historical copies or substitute signals; existing data is not automatically deleted.
• Deleting data: remove data within the specified scope, and its user-level derived data, from use; it does not automatically permanently deactivate other, independent purposes — whether the purpose that the deleted data supported continues, and whether new data continues to be collected, MUST be clearly explained to the user as part of that operation.

Passing off any one of these as another, or forcing the user to perform an unrelated operation at the same time, is prohibited; a combined action that clearly explains the consequences may be offered, while preserving individual control. After a user withdraws, the continued state of existing data MUST be queryable; if there is no longer an independently valid retention basis or the period has expired, disposition MUST be arranged, and retaining it indefinitely on the grounds that the user has not separately clicked delete is prohibited. The three may share the same settings page and the same state infrastructure — what this rule requires is that the action, the instance it acts on, and the consequence are distinct, not a fixed number of buttons; the entry points SHOULD be mutually reachable, and connected to S1-6's purpose-lookup page.

Boundary conditionsthis rule does not require providing three separate paths for every item of data — grouping by purpose or by data category is an acceptable granularity; nor does it require putting them on three different pages. If a product stores no data at all (processing is use-and-discard), recording "deletion not applicable" with a stated rationale is sufficient.

Design applicationpresent the two actions side by side on the same page, each with one line stating its consequence: "stop using for personalized recommendations (existing browsing history is retained)" and "delete browsing history (recommendations will no longer use these records)"; let the user see the difference rather than making them guess.

Verification examples

• User side: have the user accomplish the intent "I don't want to be recommended things anymore, but keep the history for now," and record what they actually clicked.
• Implementation side: separately execute revoking a permission, deactivating a purpose, and deleting, and check the new access, the consumption under the specific purpose, the deletion scope, and the remaining record; deletion must not covertly and permanently shut off an unrelated purpose.

CounterexamplesUnder-delivery — settings has only one "clear and turn off personalization" button, so a user who wants to pause recommendations must lose three years of favorites at the same time; over-delivery — splitting withdrawal and deletion for every category of data into sixteen toggles, so the user cannot find "stop everything" among them.

Basis and referencesthe EDPB, in the context of consent, distinguishes stopping related processing from retention for other purposes on an independent basis, and requires the basis to be determined in advance (R29). The three classes of control and their interface feedback are design requirements of these guidelines.

S4-2Withdrawal is no harder than givingMUST¶

In one sentence: if it was given in two steps, it cannot now take seven steps to take back.

Applies toproducts that use user consent or authorization as a processing basis.

Rulethe step count, entry depth, and required channel for withdrawing consent or authorization MUST NOT exceed those for giving it. If it could originally be given in-app with one tap, withdrawal is prohibited from requiring sending an email, making a phone call, submitting a ticket, or visiting a physical location. The withdrawal entry MUST be findable by the user without resorting to a search engine. Inserting retention steps, a second or third confirmation, or persuasion such as "are you sure you want to lose these benefits" during withdrawal is prohibited; a single confirmation that is genuinely necessary still counts toward the total path cost, and must not make withdrawal harder than giving.

Boundary conditionswhat this rule requires is that the path is no harder than giving; it does not prohibit truthfully stating what feature will be lost after withdrawal — the difference between an explanation and a retention tactic is whether it blocks continuing the operation. For a deletion-type operation with genuinely irreversible consequences, one clear consequence statement and confirmation does not count as the retention tactic this rule prohibits (deletion's confirmation is covered further in S4-6).

Design applicationput "the step count of the giving path" and "the step count of the withdrawal path" into the same review table as a launch-checklist item; if the difference is not zero, a reason MUST be given.

Verification examples

• User side: time how long and how many clicks "turning on" versus "turning off" the same authorization takes.
• Implementation side: check whether withdrawal can be completed at the same interface level as authorization, and whether there is an item with only a support-channel path.

CounterexamplesUnder-delivery — checking a box at sign-up is enough to agree to marketing pushes, but unsubscribing requires logging into the web version, going four menu levels deep, and re-entering the account password; over-delivery — turning every marketing opt-out into a high-risk deletion-like flow that requires re-authentication and typing a confirmation word.

Basis and referencesGDPR Article 7(3) requires that withdrawing consent be as easy as giving it (R12); the EDPB classifies adding obstacles as an "obstructing" category of deceptive design (R14).

S4-3Deletion reaches derived dataMUST¶

In one sentence: it's only deletion when the profile, weights, index, and cache disappear together.

Applies toproducts that carry out deletion of user data.

Ruledeletion MUST reach the derived data produced from the deleted data: user-level profile labels, personalization weights, retrieval indexes, recommendation candidate sets, cached copies, and locatable records within backups. After deletion completes, the system is prohibited from reconstructing an equivalent user-level result from logs, generated content, embedding vectors, or other residue. If part of the deletion scope genuinely cannot be cleared immediately for technical reasons (such as cold backups within a rotation cycle), its existence, when it will take effect, and the isolation measures during that period MUST be stated; using "it's still in the backup" as a reason to postpone the actual effect of deletion indefinitely is prohibited. A deletion request sent to a third-party recipient is carried out per the list in S1-4, and its limits are stated. After a backup restore, the deletion and withdrawal records MUST be replayed before it is reopened to the business; a restored backup must not revive content that has already been disposed of. When a third party has only confirmed receiving the request, its deletion must not be claimed as complete.

Boundary conditionsthis rule does not require retraining an entire model for a single user's deletion request — a statistic or model parameter aggregated to the point where it can no longer be linked to an individual does not fall under the user-level derived data this rule requires, but the product MUST be able to state the basis on which it judged that a piece of derived data can no longer be linked to an individual, and record that basis. A record whose retention is required by statutory obligation is not within the deletion scope, but MUST be declared as an independent purpose per S1-1, and must not continue to be used for its original purpose.

Design applicationtag every derived field in the data dictionary with its source and inheritance relationship (see S1-3), and execute deletion along that chain; build "which systems hold locatable data for this user" as an auditable list, rather than relying on each team's memory.

Verification examples

• Implementation side: after deleting a test account, check retrieval, recommendation, cache, backup restoration, and third-party receipts; list any remaining item separately under a declared retention exception and check that it is not being used for the original purpose.
• User side: after deleting browsing history, check the scope, derived data, and exception receipt; whether recommendations look similar is only an experiential cue, not evidence of deletion.

CounterexamplesUnder-delivery — the user deletes all chat history, but the interest vectors and retrieval indexes used for personalization remain unchanged, and recommendations continue as before; over-delivery — rolling back even anonymized aggregate statistics, so the product can no longer state its own baseline usage.

Basis and referencesGDPR Article 17 sets out the right to erasure and its exceptions (R13).

S4-4An export is usable, not just obtainableMUST¶

In one sentence: an export needs to be understandable and usable, not an archive that won't open.

Applies toproducts that provide data export or portability capability.

Rulethe export result MUST be in a form that the user or their chosen recipient can actually use: structured, in a commonly used format, with fields that have understandable names or accompanying documentation. The export MUST cover content the user actively provided and records generated through their use; parts not exported (such as inference results, internal scores) MUST be explicitly listed with a stated reason, and silently omitting them to narrow the scope is prohibited. The retrieval path and waiting time for the export MUST be stated before it is initiated, and once complete there MUST be an actual downloadable or transferable artifact. Delivery MUST verify the recipient's access eligibility, provide a controlled retrieval path, an explicit download validity period, and a method for cleaning up the server-side export copy; defaulting to a permanent public link, or sending sensitive attachments to an unverified address, is prohibited. Once download eligibility changes, subsequent retrieval MUST be refused. A copy the user has already downloaded themselves should not be promised as remotely recallable. Using export as a substitute for deletion is prohibited, as is making export a precondition for deletion.

Boundary conditionsthis rule does not require the product to achieve direct interoperability with an arbitrary competing product, nor does it require exporting internal identifiers, algorithmic intermediate state, or another user's data. When an export contains another person's information (such as the other party's messages in a chat history), the product SHOULD state that limit; the handling method is covered further in S6-2.

Design applicationtest the format choice with "if this export were handed to another product or another person, what could they do with it"; if the answer is "only manually read a CSV, row by row, with no header," it has not yet been satisfied.

Verification examples

• User side: have someone not involved in development open the exported file and answer "what categories of content are in here, and when is the most recent entry from."
• Implementation side: check the export's coverage against the declared list of data categories, marking each item as exported, not exported, and why.

CounterexamplesUnder-delivery — "download my data" produces an archive containing hundreds of randomly named JSON files, with no index and no explanation; over-delivery — exporting the entirety of the raw logs in pursuit of completeness, producing tens of gigabytes of content the user can neither download nor read.

Basis and referencesGDPR Article 20 requires providing data in a structured, commonly used, and machine-readable format (R13).

S4-5Personal data can be viewed, corrected, and objected toSHOULD¶

In one sentence: there's somewhere to fix data that was entered wrong, and somewhere to raise an objection to an inference.

Applies toproducts that store user personal data or account information, or that form inferences and profiles about the user.

Rulethe user SHOULD be able to view the specific personal data the product stores about them, not merely view a list of purposes — S1-6's purpose lookup addresses "what is this data being used for," while this rule addresses "what is this data itself," and the two do not substitute for each other. For records that can be directly edited (account data, contact information, user-entered content), a correction entry SHOULD be provided; after a correction, inferences and profiles that depend on that data MUST be re-verified, and only updating the displayed text while letting downstream consumers continue using the old value is prohibited.

For inference conclusions that cannot be directly edited (risk scores, interest profiles, risk labels), at least one of three feasible paths SHOULD be provided: raising an objection and receiving a processing outcome, requesting a check of the source the conclusion is based on, or stopping the conclusion's use for a specified purpose. The product MUST NOT close off all three paths on the grounds that "the algorithm is not explainable."

Boundary conditionsthis rule does not require every record to be directly editable by the user — transaction records, logs, and content provided by others clearly cannot be edited by the individual; these records are subject to the objection and source-check paths. This rule does not require disclosing the risk-control algorithm or model parameters; what it requires is that a conclusion can be challenged, its source can be checked, and its use can be stopped. This rule makes no compliance determination for the personal-information rights of any jurisdiction (see the scope statement).

Design applicationdesign "the user sees an incorrect piece of information about themselves" as a normal path, not a fallback branch of a support ticket. Keep the correction entry and the objection entry separate: the former addresses "this value was entered wrong," the latter addresses "I don't agree with this judgment."

Verification examples

• User side: have the user find and correct one piece of incorrect account data, then have them raise an objection to an inference label they disagree with, recording the path length and the time to a result.
• Implementation side: after correcting a piece of data, check whether recommendation, risk control, and personalization that depend on it are re-verified, rather than only the display layer being updated.

CounterexamplesUnder-delivery — the user finds a "has a car" label in their profile is wrong, but the product offers only "contact support," and support replies that it cannot be changed; over-delivery — opening up all internal feature vectors as-is for the user to edit item by item, letting a user edit their way into an unusable state and also giving an entry point for gaming risk control.

Basis and referencesW3C Privacy Principles §2.5 discusses access and correction, and §2.2 discusses minimization; this is a principle reference from the W3C Statement, and does not substitute for the rights checklist of any jurisdiction.

S4-6Disposition has a receipt and a deadlineMUST¶

In one sentence: what stage it's at, what the final outcome was, and what's left unfinished are three separate questions.

Applies toproducts that provide withdrawal, correction, objection, export, deletion, or account closure.

Ruleevery disposition request MUST have a queryable state that comes from the execution mechanism, recording at least the following dimensions separately:

• Phase (phase): accepted / executing / ended; submitted does not mean it has taken effect.
• Outcome (outcome): pending verification / fully complete / partially complete / failed. The outcome can be updated during execution; "failed" is used only once the phase has ended and it has been verified that no target was completed at all; "fully complete" is used only once the phase has ended and evidence covers the requested scope.
• Scope: the requested object, the scope verified complete, the incomplete or unknown scope, and any retention exception declared in advance; the cancellation or termination reason is recorded separately.
• Evidence and timestamp: the authoritative source, the observation time, the most recent progress, and the estimated deadline. An older snapshot must not override a newer disposition fact.

Disposition MUST be bound to the correct subject, object, and request, and the verification method proportionate to the operational risk. When an existing session or a controlled unsubscribe token is sufficient to complete a low-risk withdrawal, additional ID or forced contact with support should not be required.

The requested scope must not be narrowed after the fact to flatter the outcome. When a downstream receipt is lost, it MUST be marked pending verification, and the real state checked first; a successful submission or retry does not prove disposition is complete, and repeatedly initiating a request must not repeat an already-completed action. Backup isolation and physical erasure are presented separately; while an unverified scope remains, "all deleted" must not be displayed.

The estimated completion deadline and the contact or verification path after an overrun MUST be stated when the request is initiated. When the deadline becomes unknown or delayed, this MUST be shown truthfully with a designated responsible party, and the product must not refuse an existing request or fabricate a date. When partially complete, the remaining scope and next step MUST be stated; the user observing a change in recommendations cannot substitute for evidence of deletion. An irreversible operation may take one clear confirmation; when a revocable window exists, its length, deadline, and the boundary of the part already executed that cannot be undone MUST be stated, and using the window for repeated retention prompts is prohibited.

Boundary conditionsthis rule does not require building a separate receipt system for a disposition that takes effect instantly (such as turning off collection controlled purely by a local mechanism) — an instantly visible change confirmed by an authoritative state is itself the receipt, and no ticket needs to be created for it. Nor does this rule require disclosing the internal ticket number or processing chain of a disposition.

Design applicationshare the same state model for disposition status as other long-running tasks within the product, avoiding a vocabulary that appears only here and nowhere else.

Verification examples

• User side: initiate an account-deletion request, and check its state on day two and day seven, recording whether the user can determine "what stage it is at."
• Implementation side: construct partial failure, total failure, a lost receipt, a duplicate submission, and a delayed receipt; check whether the interface state, scope, and evidence are consistent, and check the real state before deciding whether to retry when it is unknown.

CounterexamplesUnder-delivery — clicking delete shows "your request has been submitted, we will process it within a reasonable time," with no follow-up afterward; over-delivery — turning the deletion flow into a wizard that requires the user to confirm seventeen subsystems one by one, so the user gives up at step five.

3.5 S5 Account and recovery path¶

This principle governs the user's holding, proving, and recovering of their account and identity. There is a counterintuitive core here: a usability defect in the recovery flow is a security defect. Making recovery extremely hard does not make an account more secure — it only pushes a user who cannot get through toward a weaker path: verbal verification by support staff, a friend or family member acting on their behalf, writing the password on a sticky note, switching to the same weak password on a memorable different email. So the abandonment rate of the recovery flow is a security metric. This principle also carries one of these guidelines' fixed bottom lines: secrets flow only within a defined trusted path; assisted autofill can reduce burden, but an ordinary assistant and logs must not obtain a reusable secret.

S5-1Sensitive input only travels through a trusted pathMUST¶

In one sentence: secrets flow only through a trusted authentication, payment, or verification path; an ordinary assistant and logs never touch them.

Applies toproducts involving sign-in, payment, or identity-document input, including agent products with the capability to act on the user's behalf.

Rulethe product MUST define a trusted input path for authentication, payment, and identity verification, recording the participating components, the value received, necessary retention, and the user's exit or takeover entry point (priv.account.credential.entry). Classify sensitive values by actual capability, not by name:

• Authentication or transaction secrets: passwords, verification codes, private keys, access tokens, and any token that, once held, can directly initiate a payment — these may only be processed by trusted components carrying the corresponding responsibility. When adopting platform biometric authentication, only the necessary authentication result SHOULD be received; requesting raw biometric data unrelated to the task merely because authentication was integrated is prohibited.
• Identity attributes: bank account numbers, ID numbers, and the like are still sensitive personal data; verification and business form-filling each separately bound their recipient and purpose, and are not allowed to flow into ordinary conversation just because they are not a password.
• Display or restricted references: a display identifier such as the last four digits is not the same as payment authorization; only a reference that cannot be used by mere possession alone, and that is controlled server-side in scope, may be used per a declared purpose in the corresponding business interface.

Ordinary assistants, model context, conversation records, analytics reporting, session recording, and debug logs are prohibited from receiving authentication or transaction secrets, or sensitive identity plaintext not scoped to necessity. Requiring the user to send a secret in ordinary chat or having an assistant relay it is prohibited. A trusted verifier, the user's chosen credential manager, and platform authentication and payment components may process it within their necessary responsibility; autofill does not violate this on that basis. Defaulting to enrolling in credential custody the user did not choose, on the grounds of "more convenient," is prohibited. When a trusted path cannot be provided, that sensitive step MUST stop and be handed back to the user, not degraded into ordinary text collection.

Boundary conditionsa business form receiving a necessary identity attribute per a declared purpose is not the same as custodial credential handling. Displaying an identifier, authorizing payment, and saving a payment method are different actions; showing the last four digits does not by default grant charging permission. This rule does not specify encryption, tokenization, or an authentication protocol.

Design applicationmake "which components does the secret pass through on this path, which of them are defined trusted components, and which would leave behind reusable plaintext" a fixed question in design review; if there is a step it should not pass through, change the path rather than adding a layer of masked display. Write down the authentication verifier, credential manager, and payment component one by one: what each receives, how long each retains it, and how the user takes over.

Verification examples

• Implementation side: check logs, crash reports, session recordings, and analytics reports for the possible appearance of credential-type fields.
• User side: have an agent product carry out a task that requires sign-in, and check whether it asks the user for the credential or hands control back to the user to complete authentication.

CounterexamplesUnder-delivery — an assistant prompts, in conversation, "send me your card number and I'll help you fill it in"; over-delivery — to avoid any assisted filling whatsoever, also blocking the user's own password manager's autofill, so the user is forced to type a twenty-character random password by hand and ends up switching to a weak one.

Basis and referencesNIST requires that verifiers permit password managers and autofill, and recommends against restricting pasting (R20); a trusted path does not mean manual entry only. The boundary for sensitive values in logs references OWASP Logging (R28).

S5-2The recovery path is designed around the attack surfaceMUST¶

In one sentence: the recovery door cannot be easier to push open than the front door; an answer an acquaintance can guess is not a credential.

Applies toproducts that provide account recovery, password reset, or identity re-verification.

Rulethe verification strength of the recovery path MUST be proportionate to the normal sign-in path, and an unassessed weak recovery backdoor is prohibited; the strength comparison is based on account consequence, the conditions for a successful attack, and compensating measures, not compared by step count or time spent. Using a fact that an acquaintance could know, or that can be inferred from public information, as the sole credential is prohibited — date of birth, mother's maiden name, school attended, pet's name, and common address all fall into this category. The recovery path MUST account for a close-proximity attacker: information and channels available to someone sharing a room, sharing a device, or in possession of the user's device MUST be counted into the attack surface. During recovery, showing the initiator account information that is visible without verification (such as a complete bound phone number, complete email, or historical address) is prohibited; only when eligible to see it should the minimum identifiable fragment be shown. An unverified recovery request MUST NOT reveal whether an account exists through wording, status codes, or a noticeable difference in time taken; recovery messages and attempts MUST be protected against bulk abuse, and once a rate limit is hit, a legitimate next step MUST be provided; the victim's account must not be locked merely because a stranger initiated a request. An issued recovery link or verification code MUST be scoped to its purpose, have a validity period, and invalidate after use.

Boundary conditionsthis rule does not require every product to adopt the same strength of recovery mechanism — the strength being proportionate to the consequences the account carries is sufficient; a local note-taking app and a payment account need not be treated the same. This rule does not prescribe specific authentication-factor combinations or cryptographic implementation (see the scope statement).

Design applicationwrite out concretely "who might want to take over this account" — a stranger attacker, a former partner, a co-resident, a family member — and then check the recovery path against each one in turn; a recovery flow designed only against a remote stranger attacker offers almost no resistance to takeover within an intimate relationship.

Verification examples

• Implementation side: try to complete the recovery flow under the assumption of "possessing all of the user's public social profile and brief access to their device."
• User side: check whether any step of the recovery flow leaks the account's bound information to an unverified initiator.

CounterexamplesUnder-delivery — "forgot password" needs only answering "your first elementary school," and the answer is written on the user's public profile; over-delivery — designing recovery to require three factors simultaneously with any one missing causing permanent lockout, so a user who changed phone numbers loses their account entirely (this violates S5-3).

Basis and referencesa security question can be both guessable and hard to recall (R05, historical research). OWASP's Forgot Password guide provides a mechanism reference for consistent responses, abuse-rate limiting, and one-time recovery credentials (R27); these guidelines also bring foreseeable acquaintance attacks into the assessment (R06, R07).

S5-3A usability defect in the recovery flow is a security defectMUST¶

In one sentence: an unworkable recovery path pushes the user down a more dangerous one.

Applies toproducts that provide account recovery.

Rulethe recovery flow's completion rate and abandonment rate MUST be measured and brought into review as a security metric, not merely an experience metric. When a user is stuck in the recovery flow, there MUST be either a clear next step or a clear statement of failure; leaving the user on a screen that neither lets them continue nor tells them why is prohibited. The recovery path is prohibited from pushing the final decision entirely onto a manual channel with no established verification standard — when a manual channel exists, its verification basis MUST be defined and auditable, or it becomes the weakest link in the entire account system. The product SHOULD design paths in advance for foreseeable common failure scenarios (a changed phone number, a lost second factor, an unavailable email), rather than leaving them to case-by-case handling.

Boundary conditionsthis rule does not require every account to have a completable recovery path — for a product where the user's local key is the sole credential, "unrecoverable" is a valid design choice, but it MUST be clearly disclosed when the user sets up the account, and must not be partially broken afterward through a manual process.

Design applicationview the recovery funnel and the sign-in funnel on the same chart; a large drop-off in the recovery funnel should be diagnosed by stratifying legitimate users, attack traffic, and voluntary exit, not dismissed as "users weren't careful enough."

Verification examples

• Implementation side: pull the per-step completion rate and final abandonment rate of the recovery flow over a recent measurement period, and check whether an owner reviews it.
• User side: simulate a user who "changed phone numbers and forgot their password" completing the entire flow, and record whether they reach an executable outcome.

CounterexamplesUnder-delivery — after losing the second factor, the only way out is "contact support," and support verifies by having the user recite their birth date and most recent transaction amount out loud; over-delivery — lowering the recovery bar to only an email verification code to boost completion rate, effectively turning the email into a master key for every account (this violates S5-2).

Basis and referencesusability and security are not a trade-off; blocking the user out of a flow creates a new failure path — this stance traces back to Whitten and Tygar's definition of security software usability (R01). NIST SP 800-63A-4 recommends that credential service providers encourage users to bind at least two independent authenticators, reducing the need for account recovery (R21) — this handles a foreseeable failure upstream, rather than designing the flow only after the failure occurs.

S5-4Account and authentication events are notified independentlyMUST¶

In one sentence: if someone added a key to your account, you need to find out through a different path.

Applies toproducts with an account system.

Rulewhen the following events occur, the account holder MUST be notified through an independent channel that does not depend on the item being changed itself: a new device signing in, an authentication factor added or removed, a password or recovery email/phone number changed, account recovery initiated or completed, and an operation that grants someone else access. The notification MUST include what happened, when, and the next step for "this wasn't me." Sending the change notification only to the address or number that was just changed is prohibited. Notification is prohibited from being entirely turned off by the product's notification preference settings — the user may adjust how it is presented, but must not be able to make this class of event completely silent.

Boundary conditionsthis rule does not require sending a notification for every routine sign-in — the criterion is whether the event changes the account's accessibility. Channel independence does not mean channel security: when there is reason to suspect an old number, a shared email, or a notification mirror is under someone else's control, the possible exposure consequence MUST be assessed, a verified alternative channel or an already-authenticated safety center used, and the choice and delivery limitations recorded; mechanically sending all detail back to a possibly compromised old address is prohibited, and turning off the security notice entirely is prohibited. When no usable independent channel exists, explicitly restrict and limit high-risk account changes, and provide a defined remediation path. A product may merge same-type events within a short time, but must not lose any one item's specific content by merging.

Design applicationsplit "account security event" and "product notification" into two categories; the former does not enter the frequency budget of marketing and recommendations, nor can it be suppressed into invisibility by a do-not-disturb policy.

Verification examples

• Implementation side: trigger each of the above events one by one, and check whether the notice is sent and where; specifically check that a contact-information change notice reaches a safe, independent, already-verified channel, rather than being sent mechanically to the old number.
• User side: repeat the above test on an account with all notification preferences turned off.

CounterexamplesUnder-delivery — after an attacker changes the bound email, the change-confirmation letter is sent only to the new email; over-delivery — pushing a security alert for every routine sign-in on the same device, so the user turns off all security notifications after two weeks (this also touches S7-2).

S5-5Do not convert an authentication burden into a memory burdenSHOULD¶

In one sentence: no more forced password changes, imposed composition rules, or bans on pasting.

Applies toauthentication flows that use a password, verification code, or interactive challenge.

Rulethe product SHOULD NOT force users to periodically change their password, SHOULD NOT impose a specific character-composition rule, and SHOULD NOT set an overly short maximum password length. Blocking pasting, disabling a password manager's autofill, and silently truncating a user's entered password are prohibited. When there is evidence a password has been compromised, a change SHOULD be required — this is an evidence-triggered case, and is not the same thing as periodic forced changes. Password-strength hints SHOULD be based on actual guessability, not a count of character classes. Authentication and recovery SHOULD provide assistive mechanisms or reachable alternative paths that reduce memory, transcription, or puzzle-solving burden; support completion via keyboard and assistive technology, and state the remaining options after one authentication method is declined. A verification code's validity period and which code remains valid after a resend SHOULD be clear; resending must not repeatedly trap the user in not knowing which message to use (R24).

Boundary conditionsthis rule does not object to setting a minimum password length, nor to disallowing known, frequently breached passwords. When a specific industry or jurisdiction mandates periodic changes, follow that requirement and record the source of that deviation (this rule is a SHOULD, and a deviation requires a record).

Design applicationmake "what will users actually do to satisfy this rule" the criterion for rule design — the actual result of forcing a change every 90 days is usually incrementing a digit at the end of the old password and writing it on a sticky note.

Verification examples

• User side: try pasting a 40-character random password on the sign-up and sign-in pages, and check whether it is rejected or silently truncated.
• Implementation side: check whether every restriction in the password policy corresponds to a concrete threat; one that does not is a pure memory burden.

CounterexamplesUnder-delivery — requiring a password 8 to 16 characters long, with mandatory upper and lower case and special characters, changed every 90 days and not repeating any of the last five; over-delivery — completely removing any length or breached-password check, accepting "123456" without objection.

Basis and referencesfor the subjects it applies to, NIST prohibits unjustified periodic password changes and composition requirements, requires permitting password managers and autofill, and recommends allowing pasting (R20). These guidelines adopt SHOULD for periodic changes and composition requirements, and MUST NOT for blocking pasting, disabling autofill, and silent truncation; the text of this rule governs, and the source's strength is not carried over wholesale.

S5-6A lost device has an executable dispositionMUST¶

In one sentence: if a phone is lost, it can be kicked offline from another device.

Applies toproducts whose accounts can stay signed in across multiple devices.

Rulethe user MUST be able, from another device, to view the sessions and devices currently signed in and individually terminate any one of them. A termination request MUST first revoke that device's subsequent access and refresh eligibility at a service-controlled authorization checkpoint; merely removing the entry from the list while the token remains valid is prohibited. Client-side sign-out, cache clearing, and the invalidation of offline verification credentials each present their own time of effect and limitation separately. While a client-side action is still pending, online-resource access eligibility must not be retained alongside it — a device being offline does not constitute a reason to keep accepting its old credentials for online-resource access. When a terminated device reconnects, the revocation state MUST be checked first, and reviving an old session is prohibited. The session list MUST include enough information for the user to identify the device (device type, most recent activity time, approximate location or network), while it must not include information precise enough to be used to locate the device's current holder.

Boundary conditionsthis rule does not require the product to provide remote-wipe capability for device data — that is a platform-level capability, and an ordinary app does not gain that permission because of this rule. Nor does this rule require every offline credential to invalidate instantly — what it requires is stating the checkpoint and the remaining window: the product MUST declare at which checkpoint subsequent access is denied, the scope of local capability still usable during the offline period, and how long that window can be at most. When a terminated device is offline, it is acceptable for client-side clearing to become pending, but the user MUST be able to see which part has taken effect and which part has not.

Design applicationpresent "server-side revocation has taken effect" and "this device's local data has not yet been cleared" as two lines of state, not one "pending." Present "terminate session" and "change password" separately and state the effect of each — many users assume changing the password automatically kicks others out, and whether that is true depends on whether the product invalidates tokens accordingly; this MUST be stated explicitly, and the user must not have to guess.

Verification examples

• User side: terminate device B's session from device A, continue operating on device B, and record how long it takes to lose access.
• Implementation side: check whether what is revoked upon termination includes the refresh token and long-lived credential, not only the current access token.

CounterexamplesUnder-delivery — settings has a "signed-in devices" list but no termination action at all, and the user's only recourse is changing the password, which does not invalidate the old session; over-delivery — showing each device's precise location and street address in the session list, letting a co-resident use it to confirm the other person's whereabouts (this violates the intent of S6-4).

Basis and referencesOWASP's Session Management guide requires server-side session invalidation (R26). Client-side clearing, the offline scope, and truthful feedback are experience boundaries these guidelines further specify.

3.6 S6 Other people present¶

This principle governs people who are not this session's account holder but are affected by this interaction. These people never clicked any consent button: the person standing behind the user who can see the screen, the coworker recorded in an audio clip, the family member sharing a tablet, the person being continuously located by a parent or partner through a "caring" feature, the contact whose number was uploaded from the address book. The consent was given by the account holder, but the impact falls on them — this is the step most easily skipped by an entire privacy-design process, because every interaction object of the product is the account holder, and the affected person has no place in the system. The boundary between S5 and S6: the account holder's own holding, proving, and recovery belongs to S5; the people who are not the account holder belong to S6.

S6-1The person on the same screen is not the authorized audienceMUST¶

In one sentence: when the audience is unclear, treat it as visible to others.

Applies toproducts that may present content on a lock screen, in notifications, via screen mirroring, through speaker output, on a shared interface, or in a public setting.

Rulethe current audience MUST be resolved before presenting private content; when the audience is unclear, treat it as potentially visible to others — hide the specific content and provide a path into a private view. Under a lock-screen notification, spoken output through a speaker, or screen mirroring, message body, verification codes, health and financial data, identity information, and content from which a sensitive situation could be inferred MUST NOT be expanded by default. Expanding it by default on the grounds that "the user will notice" is prohibited. A user may proactively relax this default, but the relaxation MUST be an explicit setting, and MUST NOT be inferred by the product on its own from device type or frequency of use.

Boundary conditionsthe sender, event type, avatar, title, and thumbnail can also expose a sensitive situation and MUST be judged together with the body text; "you have a new message" is presented only when it does not itself leak anything. When the product cannot obtain any audience cue at all, operating at the most conservative tier satisfies this rule; it does not require the product to implement audience-recognition capability.

Design applicationtreat "privacy level" as a property of the content, multiplied against the contextual property of "audience," to decide how much detail is shown; do not rewrite this judgment logic separately at every notification construction point.

Verification examples

• User side: trigger a message containing a verification code under each of lock-screen, in-car screen-mirroring, and spoken-output states, and record how much is presented.
• Implementation side: check whether the privacy-level annotation covers every notification type, and whether there is any item that is missing and defaults to public.

CounterexamplesUnder-delivery — the lock screen fully displays "Your bank verification code is 481920" and "Test results are in: elevated blood sugar"; over-delivery — even after the user has proactively chosen to publicly display a non-sensitive calendar, every notification is still turned into "you have a new notification," forcing the user to unlock and check each one just to know whether it's spam, eventually leading them to turn off all notifications.

S6-2A recorded third party has an independent boundaryMUST¶

In one sentence: the user's consent cannot stand in for the consent of another person in the recording.

Applies toproducts that collect or process data containing information about a third party who is not the user: audio and video recording, contact upload, chat-log analysis, faces in photos, meeting transcription, and so on.

Rulethe account holder's consent does not constitute a processing basis for a third party within the content. Data containing third-party information MUST be limited in purpose to what is necessary to complete the user's current task; using it to expand the product's own social graph, identity store, ad targeting, or cross-user recommendations is prohibited. Another person's information within contacts, call logs, or photos is prohibited from being uploaded while the user has not used the related feature (see S1-2), and prohibited from being retained as "someone else's data" after the user has deleted it. Recording and transcription features SHOULD provide a perceivable in-progress indicator to other people present, when technically and contextually feasible.

Boundary conditionsthis rule does not prohibit a user saving and using content containing another person's information themselves — a group photo the user took is still the user's photo. The criterion is whether the product converts this third-party information into an asset it can reuse across users. This rule makes no jurisdictional determination on a recording-notice obligation (see the scope statement).

Design applicationfor every piece of data containing third-party information, write out "if that person asked, could we clearly say what happened to their information"; if this cannot be answered, it means the purpose has exceeded the user's current task.

Verification examples

• Implementation side: check whether data from an uploaded address book participates in cross-account relationship inference or a "people you may know" computation.
• User side: after a user deletes their account, check whether the other people's numbers they uploaded can still be matched within the system.

CounterexamplesUnder-delivery — a utility app uploads the entire address book and builds a profile for every number based on it, including people who never installed the app; over-delivery — to avoid any third-party data processing whatsoever, refusing to even save locally the notes a user wrote for their own contacts, making the feature unusable.

Basis and referencesNissenbaum's contextual integrity (the 2004 text) proposes that information flow is constrained by two kinds of contextual norms — norms of appropriateness and norms of flow — and that violating either constitutes a breach of contextual integrity; the text explicitly rebuts the view that "once a person enters a public setting, no norms apply" (R08). This provides an analytical framework for "the user's consent does not change the context the third party is in," but it is an analytical framework, not a directly applicable decision rule; the five-parameter model often cited alongside it comes from a later work, not this text.

S6-3A shared device and a shared account do not share private stateMUST¶

In one sentence: two people on one device should not inherit each other's history and inferences.

Applies todevices or accounts that may be used by multiple people: a family tablet, a shared computer, a smart speaker, an in-car system, a family shared account.

Rulewhen a device or account is used by multiple people, the product MUST provide a mechanism by which private state is not inherited across users: separate history, recommendation basis, search suggestions, autofill, and personalization configuration. When users cannot be distinguished, take the most conservative tier per S2-3, and do not present history-based personalized content. Treating the mere fact that multiple people already use the device as sharing permission is prohibited — the presence of two people's usage traces on one device does not constitute either party's consent to show their own record to the other. A path to switch users or sign out MUST be reachable, and no interface state that could be used to reconstruct the previous user's behavior may remain after signing out.

Boundary conditionsthis rule does not require every product to implement a complete multi-user system — providing a usable "guest" or "don't record this" mode, so that signing out does not expose private state to the next user, satisfies this rule; if a declared security log or server-side retention still exists, it MUST be stated, and claiming end-to-end "no trace left" is prohibited. Content a user proactively shares under a joint account (a shared album, a joint list) does not fall under the private state this rule constrains.

Design applicationuse "what visible trace did the previous user leave" as the acceptance checklist for a shared scenario: search-box history, input-method suggestions, autofill, the notification shade, recently opened items, the recommendation homepage — check each one individually, rather than only clearing one "browsing history."

Verification examples

• User side: use the same device as two users in sequence, and record which traces of the first the second one can see.
• Implementation side: after exiting guest mode, check whether the local cache, recommendation candidates, and input suggestions still contain content from the previous session.

CounterexamplesUnder-delivery — a video app on a family tablet uses one family member's watch history directly as the whole family's recommendation basis, and shows "continue watching" on the home screen; over-delivery — isolating even a shared family photo album as private state, so a family member cannot see shared content they have already been invited to.

S6-4A feature with monitoring capability must let the monitored person knowMUST¶

In one sentence: a feature that can see where someone else is cannot have a hidden mode.

Applies toproducts that provide location sharing, activity visibility, usage-time reporting, content review, or device management that can be used to continuously observe another person, including family-safety, child-monitoring, and enterprise device-management features.

Rulea feature capable of continuously observing another person MUST have a continuously perceivable presentation on the observed person's device or account; providing a hidden icon, hidden operation, disguising itself as another app, or a mode that leaves the observed person unable to learn that observation is taking place is prohibited. The observed person MUST be able to look up who is observing, what is being observed, and since when. An expansion of observation scope MUST be re-notified. In cases where the observed person does not have full autonomy (a minor, an enterprise device), they still MUST be made aware of the existence and scope of the observation — being informed and having the right to turn it off are two different things, and the former must not be canceled because the latter does not hold.

Boundary conditionsthis rule does not prohibit parental-control or enterprise-device-management features themselves, nor does it require granting the observed person the right to turn it off. This rule makes no jurisdictional determination on the legality of monitoring (see the scope statement). When the product has no account or app on the observed person's side (such as one implemented only at the router level), it MUST separately provide an equivalent disclosure mechanism actually reachable by the observed person, and verify its coverage — for example a mandatory notice page on connecting, a visible marker on that network, or a posted notice reachable within that space; notifying only the person who set it up does not satisfy this rule, because the person who set it up is precisely the party against whom the observed person's need to be informed is directed. If this cannot be achieved, stop offering that monitoring capability rather than substituting the person who set it up as the notified party. Notifying the person who set it up of the presentation's limits is an additional requirement, not a substitute path.

Design applicationwhen designing this kind of feature, write down "if the observed person were the designer themselves, what would they want to know," then check whether the product provides it. Abuse within an intimate relationship often uses exactly the product's normal features rather than a breach — so visibility MUST be guaranteed by the product, and cannot depend on the observed person discovering it themselves.

Verification examples

• User side: check the observed person's device and account as that person, and record whether they can discover the existence and scope of the observation without external tools.
• Implementation side: check for any configuration combination that can hide the icon, a notification, or a status item.

CounterexamplesUnder-delivery — a "family safety" app offers a "stealth mode" that, once installed, shows no icon and sends no notification on the installed device, while continuously reporting location; over-delivery — popping a full-screen alert on the observed person's device for every single location read, making the feature unusable in its designed scenario (a lost child).

Basis and referencesresearch on intimate-partner-violence scenarios shows the attacker is often already an authenticated party operating through the standard interface, and existing systems' threat models do not cover this kind of adversary (R06); most software used for monitoring is dual-use, marketed as child safety or anti-theft, rather than openly sold spyware (R07). An industry coalition's definition of this kind of software centers on "remotely monitoring a device's activity without the monitored person's consent and without a clear, persistent indicator," and notes that mere physical access, unlocking the device, or signing in with an account password does not constitute the monitored person's consent (R19).

S6-5The account holder is not the same as the data subjectMUST¶

In one sentence: the person who pays, the person who bought the device, the person who manages the account does not automatically gain the right to read.

Applies toproducts where the account owner and the actual user are different people: a family group, an enterprise account, a custodial account, a service opened in someone else's name, a device that was gifted or configured by someone else.

Ruleaccount ownership, a payment relationship, or a device purchase relationship does not automatically constitute a basis for reading the actual user's personal data. The scope of information an administrator can obtain MUST be explicitly defined, visible to the managed person, and limited to what is necessary for their administrative responsibility; defaulting to opening conversation content, browsing history, location trails, health data, and private communications to the administrator is prohibited. An administrator's disposition of a managed person's account (removal, reset, export, deletion) MUST be disclosed to the managed person, and any emergency exception MUST be listed with its basis stated. When a managed person exits the management relationship, the destination of their personal data MUST be clear, and defaulting to handing it over to the administrator is prohibited.

Boundary conditionsthis rule does not deny that a genuine legitimate need can exist within a management relationship — an enterprise's access to work data, a parent's necessary protection of a minor. The criterion is whether the data accessed falls within the declared scope of administrative responsibility, and whether the managed person is informed (see S6-4). This rule makes no legal determination related to labor law or the guardianship of minors (see the scope statement).

Design applicationwhen designing an administrator view, annotate item by item "can the administrator see this, why, and does the managed person know"; make this annotation into a statement the managed person can look up, not something that exists only in the admin console's feature list.

Verification examples

• User side: as the managed person, ask "what can my administrator see about me," and record whether a concrete answer is obtained.
• Implementation side: check whether the field set returned by the administrator interface matches the declared scope of administrative responsibility.

CounterexamplesUnder-delivery — a family group's organizer can view every member's complete app-usage record and location history, and members were never told; over-delivery — an enterprise administrator cannot view any device compliance state at all, so when a device is lost, it cannot be confirmed whether it was encrypted (this conflicts with S5-6's disposition capability).

3.7 S7 Security judgment is not outsourced¶

This principle governs the security warnings the system issues to the user, and the security judgments it asks the user to make. Its starting point is a repeatedly documented phenomenon: repeated warnings can cause habituation, and its impact depends on the risk type, timing, and presentation. So this principle's first rule is not "write the warning clearly," but first remove what should not become a warning at all — a risk the system can already judge for itself SHOULD be intercepted or handled by default, not turned into a multiple-choice question the user has no basis to answer. Every warning that remains must be worth the user's attention: it must be able to state the consequence, state the next step, and a bypass must leave a trace and not be permanent. Pushing a security decision onto the user looks like respecting their choice, but is actually writing a problem the system could not solve into the user's responsibility.

S7-1What can be blocked is not turned into a warningMUST¶

In one sentence: a risk the system can already judge for itself should not become the user's multiple-choice question.

Applies toproducts that present a security, privacy, or risk prompt to the user.

Rulewhen the system already has sufficient grounds to determine that a behavior carries a clear risk, it MUST intercept it directly or handle it conservatively; turning that judgment into a multiple-choice question the user must answer is prohibited. A choice is presented to the user only when the system genuinely cannot make the determination, and the user holds information the system does not. When a choice is presented, what the system knows and does not know MUST be stated. Using "the user was informed" as a means of shifting responsibility onto the user is prohibited — whether informing was effective is determined by whether the user could make a judgment from it, not by whether it was displayed.

Conservative handling MUST distinguish two consequences: blocking a new threat, versus removing existing monitoring. Both require assessing the visible consequence; the latter especially may be noticed by the installer — the Coalition Against Stalkerware's response guidance notes that removal can be discovered by the installer, and therefore the device holder must be the one to choose whether to remove it (this guidance is not a legal standard). Therefore: the default action is limited to blocking new threats; actions such as removing existing monitoring, resetting shared credentials, or sending a security notice to a historical contact method — which might be noticed by the other party — MUST first have their visible consequence assessed, and the choice and a safe contact path handed to the affected person. Concealing the existence of monitoring from the monitored person on the grounds of "protecting the victim's safety" is prohibited — S6-4's disclosure obligation is not diminished by this rule; what this rule restricts is the product taking an action, on the affected person's behalf, that might expose their seeking help.

Boundary conditionsthis rule does not require turning every uncertain case into a silent block — the cost of a false block is equally real, especially in scenarios where blocking interrupts the user's legitimate work. The criterion is whether the user holds the information needed to make this judgment: the user knows which link they just clicked (the user has the information), but does not know whether a middle link in some certificate chain has been substituted (the user does not have the information).

Design applicationfor every existing warning, ask "what does the user use to answer this question"; if the answer is "guess" or "only find out after clicking," it should be changed to a block, or changed to provide the information the user actually needs.

Verification examples

• Implementation side: inventory every security-type prompt in the product, and annotate each one with the system's basis for judgment and the judgment the user is asked to provide; any item where the two are the same is one that should be intercepted instead.
• User side: show a warning to someone not involved in the design, and have them explain "what would you base your decision to continue or go back on."

CounterexamplesUnder-delivery — after detecting a clear credential-phishing page, a pop-up asks "this site may be risky, continue?" with an equally prominent "continue" option; over-delivery — silently blocking every self-signed certificate with no exception path whatsoever, making all internal-network operations tools inaccessible.

Basis and referencessecurity-usability research emphasizes enabling users to understand and complete necessary security tasks (R01); browser-warning research shows effectiveness varies by design and context (R02, R03). These sources do not prove that "one more warning is necessarily worse," nor do they provide a cross-product threshold. The disposition risk for existing monitoring references industry-coalition guidance (R19).

S7-2The number of warnings is budgeted by effectivenessMUST¶

In one sentence: check the cause before repeating a prompt; even an exhausted budget must not let a critical risk through.

Applies toproducts that issue an interrupting security prompt to the user.

Rulesecurity warnings MUST be managed as a finite resource: the product MUST define under what conditions an interrupting warning is issued at all, and set a cap on its frequency. Substituting increased visual intensity (bigger, redder, more exclamation marks) for diagnosing the cause is prohibited. When a warning is being ignored, first check four things — repetition and deduplication (is the same risk recurring), timing (is it appearing at a moment the user cannot act on), comprehensibility (can the user make a judgment from it), and whether the risk composition has changed (a newly appearing risk category, or a quantitative change within the same category); on this basis, a presentation fix backed by validation evidence may be adopted, including a presentation change measured to reduce habituation. A recurring warning of the same type MUST be merged or converted into a one-time setting. Hitting the frequency cap must not cancel the handling of a critical risk: the legitimate response upon reaching the cap is to merge, deduplicate, or convert to a direct block per S7-1 — not to leave that risk unhandled. The warning's actual effectiveness SHOULD be measured and brought into review; the measurement MUST be stratified by explicit risk category and user group, and observe false interception, incorrect pass-through, and task completion at the same time; it must not substitute a single "behavior-change rate" for a security outcome. The measurement method and threshold are defined by the product with a recorded rationale; these guidelines give no numeric value.

Boundary conditionsthis rule does not require reducing non-interrupting state presentation (such as S3-3's active indicator) — that does not consume the same attention budget. A prompt mandated by a jurisdiction or platform does not count toward this rule's frequency cap, but should still be counted toward the total interruption the user actually experiences and explained accordingly.

Design applicationmake "how many interrupting security prompts we sent users this year" a reportable number. When this number rises while the behavior-change rate falls, the count is the first suspect to check, but it is not yet the confirmed cause — a change in the same period's risk composition, audience, copy readability, or interception strategy could produce the same curve; separate these out first before drawing a conclusion.

Verification examples

• Implementation side: measure the number and type distribution of interrupting security prompts a typical user encounters in one month.
• User side: observe how long it actually takes the user to act after the third consecutive occurrence of the same type of warning.

CounterexamplesUnder-delivery — a full-screen security prompt pops up every time public Wi-Fi is connected, every time an external link is opened, and every time any permission is granted, and by the second week the user forms the habit of clicking "continue" without reading; over-delivery — to control the count, merging even a genuine high-risk block into a weekly digest, so the user gets no prompt at all when the incident actually occurs.

Basis and referencesR02's publisher abstract supports the finding that warning effectiveness varies significantly; R04's abstract discusses habituation and presentation changes. These guidelines require diagnosing the cause and validating the effect of a change, not deriving a specific frequency or an effect guarantee from an abstract.

S7-3A warning states the consequence and the next stepMUST¶

In one sentence: what was blocked, what it affects, and what can be done next.

Applies toproducts that present a security or privacy warning to the user.

Ruleevery warning that remains MUST state three things: what happened, what the consequence would be if it continues, and what can be done now. Giving only an error code, technical jargon, or "operation has been blocked" with no executable next step is prohibited. The consequence MUST be stated as a concrete loss the user can understand; phrasing such as "there may be a security risk," which gives no basis for judgment, MUST NOT be used. The next step provided in the warning MUST actually be executable — pointing to a setting that is not actually provided, or an action that requires administrator permission the user does not have, is equivalent to having no next step. The warning's wording MUST NOT be exaggerated to push the user toward the side the product prefers (see S2-6).

Boundary conditionsthis rule does not require disclosing the complete technical diagnostic information to the user — that neither helps the judgment nor might it be exploited by an attacker. What it requires is information sufficient to support this particular decision; technical detail can be placed in an expandable secondary position.

Design applicationwrite every warning using the three-part structure "what happened / what will happen / what to do"; if it cannot fill all three parts, that means this warning should not have been issued at all (return to S7-1).

Verification examples

• User side: have someone not involved in the design read the warning, then answer "what's the worst that happens if I click continue."
• Implementation side: check, for each warning, whether the action entry it offers is actually reachable under the current user's permission.

CounterexamplesUnder-delivery — "NET::ERR_CERT_AUTHORITY_INVALID" plus a collapsed "advanced" item; over-delivery — three paragraphs explaining certificate-chain validation in detail, and the user still doesn't know which button to click after reading it.

Basis and referencesFelt et al.'s report on redesigning browser SSL warnings found that compliance rose significantly while users' understanding of the threat did not improve accordingly, and rewriting the copy alone had little effect (R03). On this basis, this rule's three elements are a necessary condition, not a sufficient one: stating the consequence and the next step clearly does not guarantee user comprehension, but without it the user does not even have an executable action — this inference is these guidelines' own design judgment.

S7-4The bypass path has friction, a record, and is reversibleSHOULD¶

In one sentence: bypassing should be one deliberate action, and not a permanent one.

Applies toproducts that allow the user to bypass a security block or lower a security setting.

Rulebypassing a security block or lowering a security tier SHOULD satisfy three things: it requires a deliberate action distinct from routine operation (must not be completable by an accidental tap or repeatedly tapping the same spot); it leaves a record the user can look up (what was done, when, and the scope of effect); and it has a deadline by default and can be reversed with one tap. Setting the bypass to be permanently in effect by default with no notice whatsoever is prohibited, as is stopping subsequent detection of the same type of risk after the user bypasses it. The bypass's scope of effect SHOULD be limited to the specific object, not expanded into a global turn-off.

Boundary conditionsthis rule does not require making the bypass difficult to complete — the purpose of the friction is to make it a deliberate choice, not to obstruct a user with a legitimate reason. When an enterprise or development scenario genuinely needs a long-term exception, it SHOULD be expressed as an explicit exception list, not expressed by turning off the entire protection.

Design applicationturn "what the user has bypassed" into a queryable list, showing each item's expiry time within it; without this list, neither the product nor the user knows what security state they are actually in.

Verification examples

• User side: after bypassing a block once, check whether the user can later find "what I once allowed."
• Implementation side: check whether the bypass is scoped to the specific object, and whether an expiry or recovery mechanism exists.

CounterexamplesUnder-delivery — clicking "continue anyway" permanently adds the site to a trust list, and the user never receives another prompt and has nowhere to view that list; over-delivery — requiring a full multi-step bypass every single time the same known internal-network address is visited, until the user eventually turns off that protection entirely.

4. Terminology and definitions¶

This chapter defines only terms used within these guidelines that could easily cause ambiguity.

Appendix A: Fault-injection verification checklist and classification check¶

This checklist is used to verify whether a clause has actually taken effect; it adds no new obligation. It inherits, item by item, the main text's applicability conditions, exceptions, and the rules for SHOULD-item deviations; "not applicable" MUST have a reason, and "not tested" does not mean passed. The timestamps and durations below are use-case context, not universal thresholds.

A.1 Purpose and collection

A.2 Method of obtaining consent

A.3 Permission timing and revocation

A.4 Disposition execution and receipt

A.5 Account and recovery

A.6 Bystanders and third parties

A.7 Warnings and security judgment

A.8 Classification check

Used to verify whether Chapter 1's division holds: take 10 to 15 concrete requirements (which may come from this guideline's clauses, or from real review comments), and have at least three reviewers not involved in writing it independently judge which principle each belongs to. If disagreement over ownership clusters between two particular principles, that means the regulated objects of those two principles have not actually been separated — at that point, the principles should be adjusted, rather than adding an intermediate layer or a mapping explanation. The two places known to need priority checking are stated explicitly in Chapter 1 (S2 and S3, S5 and S6). The number of reviewers and the disagreement criterion in this check are this guideline's suggested internal method, not a literature-validated standard method.

A.9 Supplementary boundary use cases and judgment record

Every conclusion records: the applicable rule and clause, the product's capability and environment, the initial facts, the user action, mechanism evidence, interface feedback, the difference between expected and actual, and the owner. The result uses "pass / fail / not applicable (reason) / not tested"; a SHOULD-item deviation additionally attaches a reason, an alternative measure, and verification. Documentation-structure checks, implementation checks, and user-task verification are recorded separately and cannot substitute for one another; this checklist having been written out must not be treated as the product having passed.

Appendix B: Evidence boundaries and source types¶

B.1 The criterion for normative terms

The sole basis for labeling something MUST is: without it, some commitment to the user would fail under a foreseeable circumstance. The following three categories of evidence provide different kinds of support; they are not three independent mandatory sources, and a failure record or an implementation reference alone is not sufficient to decide a MUST label —

The seven rules labeled SHOULD (S1-6, S2-6, S3-2, S3-5, S4-5, S5-5, S7-4) permit an argued deviation from their SHOULD item: a deviation may have a legitimate reason, but it must be recorded and subject to the same verification. Among these, S2-6, S3-2, S3-5, S5-5, S7-4, S4-5, and S1-6 each contain at least one prohibition-level clause, and those clauses are not downgraded merely because the rule heading is SHOULD (see 2.2).

B.2 The three thinnest points of evidence in these guidelines

Stated explicitly, not masked by normative phrasing:

1. S7-2 has no portable threshold for the number of warnings. There is no cross-product recognized criterion for "how many warnings is too many." Existing research documents the phenomenon of warnings being ignored, and the change in compliance rate after redesigning presentation, but those numbers come from a specific browser and a specific warning type, and cannot be taken as a cap for any arbitrary product. These guidelines therefore only require that "the cap be explicitly defined; effectiveness SHOULD be measured, and a deviation requires alternative verification; and the owner be clear," without giving a number. This is the rule most likely to be satisfied merely in form within these guidelines.
2. S4-3's "cannot be reconstructed" lacks an actionable determination method. Judging whether an aggregate result or a model parameter can still be linked to an individual has no simple engineering answer; what these guidelines give is a requirement (the product MUST be able to state its basis for the determination, and record it), not a determination method. The related technical approaches (such as removing the influence of specific training data from a model) did not, in this pass, yield a verified conclusion able to support a product-level commitment.
3. S6-3's "private state" boundary depends on product judgment. Which states count as private and which are normal sharing within a joint account does not align across family, office, and public-device scenarios. What these guidelines give is a method for constructing the checklist (enumerating visible traces item by item), not a universal field table of private state. Cross-cultural differences in expectations around family data sharing likewise did not yield a directly citable conclusion in this round of research.

B.3 What these guidelines do not do

They make no legal compliance determination (GDPR, CCPA, PIPL, and the like appear in these guidelines only as sources and scope exclusions), they do not prescribe cryptographic implementation or protocol choice, they do not perform threat modeling or attack-surface enumeration, they do not give a recommended combination of authentication factors, they do not give a universal standard for data classification tiers, and they do not give an age threshold for minors. These are decisions for legal, dedicated security processes, and the product; these guidelines only require that these decisions be made, be verifiable, and state which values are not permitted.

B.4 Sources

The complete source cross-reference and verification scope are in reference.md. A clause in these guidelines does not hold merely because some product has done it that way; platform practice is evidence that "this kind of mechanism is feasible in a real product," not a basis for "this SHOULD be required." Regulatory text proves that a requirement exists within some jurisdiction; it does not prove that these guidelines' wording matches that jurisdiction's applicability determination.

---

Implementation acceptance scenarios¶

The scenarios below convert existing clauses into reviewable acceptance input; they do not set an additional universal performance threshold. Select by the product's applicable capability, and supplement with real devices, users, input sequences, and evidence; record the reason when not applicable, and an unexecuted item must not be recorded as passed.

Every scenario separately checks the configuration's effective value, the execution record, and a result the user can understand. Retain the version, target, event timestamp, failure scope, and recovery result; an unknown external result is not filled in as success or failure.