Dark-pattern consent

Problem Context

• The surface asks for optional data use, marketing, research contact, AI training, partner sharing, personalization, sensitive-data use, non-essential cookies, local storage, advertising tags, analytics tags, or similar tracking.
• Consent may be presented during onboarding, checkout, account creation, cookie banners, cookie settings, preference centers, privacy settings, app permission explanations, beta enrollment, or legal-acceptance-adjacent flows.
• Users may face misleading hierarchy, disabled-looking refusal, confirmshaming copy, repeated prompts, bundled terms, preselected choices, unavailable service after refusal, or a mismatch between visible choice and runtime processing.
• The organization may later rely on the record as evidence, so the design must prove what the user saw, whether refusal was reachable, and whether optional processing was blocked until consent.

Selection Rules

• Flag this anti-pattern when accepting optional consent is one click but declining, customizing, or withdrawing requires extra pages, hidden links, confusing labels, or repeated confirmation.
• Flag it when optional purposes are preselected, bundled into terms, bundled together despite separable purposes, or hidden behind a broad agree and continue action.
• Flag it when refusal is visually de-emphasized, disabled-looking, below the fold, delayed, shamed, worded as a negative consequence, or absent from the same decision level.
• Flag it when optional processing, tracking, sharing, marketing, AI training, or personalization starts before the user has made the matching choice.
• Flag it when the product blocks eligible service access, repeats prompts, or makes core tasks harder after refusal for an optional purpose.
• Use consent prompt for the corrected active opt-in pattern for optional non-cookie data use.
• Use cookie consent for the corrected purpose-level runtime model for cookies, pixels, tags, SDKs, local storage, and similar technologies.
• Use cookie banner for the first-layer cookie choice surface; a cookie banner can itself contain dark-pattern consent if reject, manage, or withdrawal is manipulated.
• Use legal acceptance for required terms, conditions, policies, or contracts; do not hide optional consent inside legal acceptance.
• Use preference center or privacy settings when users later manage durable choices, withdrawal, purpose toggles, account privacy, or browser signal consequences.

Required States

• Accept-dominant state where accept is easier or more visually prominent than reject.
• Hidden reject state where decline is behind another layer, link, scroll, or misleading label.
• Preselected optional purpose state.
• Bundled purposes state for marketing, research, AI training, personalization, partner sharing, or analytics.
• Consent wall or refusal punishment state.
• Processing-before-choice state where optional tags, sharing, or training start before consent.
• Repeated prompt or nag state after refusal.
• Hard-to-withdraw state where revocation is harder than accepting.
• Corrected equal-choice state with accept, reject, and manage at the same decision level.
• Corrected granular purpose state with optional purposes off until selected.
• Corrected withdrawal state that stops future processing and records the change.
• Mobile compact state where reject, manage, purpose, and withdrawal path remain visible.

Interaction Contract

• Acceptance, rejection, customization, and withdrawal must be reachable with comparable effort for optional purposes.
• Optional purposes start off unless a current valid record exists for the same purpose, version, requester, region, and user.
• Consent is not inferred from scrolling, closing, continuing to browse, inactivity, account creation, payment, or unrelated legal acceptance.
• Separate purposes are split into separate choices unless they are truly inseparable.
• Refusal preserves eligible service access and task progress when the purpose is optional.
• Optional processing, tracking, sharing, or training is blocked until the matching consent state exists.
• Withdrawal changes the same runtime and record used by the original prompt.
• The record preserves purpose, copy version, requester or controller, data involved, user, timestamp, source surface, refusal or withdrawal state, and runtime enforcement outcome.

Implementation Checklist

• Inventory every consent surface and record accept path, reject path, manage path, withdrawal path, default state, processing start time, and stored evidence.
• Compare the number of steps, visual prominence, wording, keyboard order, and mobile visibility of accept, reject, customize, and withdraw actions.
• Turn off optional purposes by default and split independent purposes into separate choices.
• Remove consent walls, forced acceptance, repeated nags, confirmshaming, deceptive contrast, hidden reject links, preselected options, and bundled legal or marketing choices.
• Block optional cookies, pixels, tags, SDKs, sharing, marketing, AI training, and personalization until the matching purpose is accepted.
• Record accept, reject, customize, withdrawal, renewal, stale, and failed-write outcomes with purpose and version.
• Test accept, reject, customize, withdrawal, renewal, mobile compact, keyboard order, screen-reader labels, browser privacy signal, no-JavaScript, and runtime proof that optional processing is blocked.

Common Generated-UI Mistakes

• Showing Accept all as the only button and hiding Reject all inside Manage settings.
• Preselecting optional marketing, analytics, personalization, or partner-sharing toggles.
• Treating continued browsing, closing, scrolling, swiping, or inactivity as consent.
• Using shame copy such as No, I do not want privacy or I prefer worse service for refusal.
• Bundling optional marketing or partner sharing inside required terms acceptance.
• Starting tracking, sharing, or AI training before consent is captured.
• Making withdrawal harder to find or complete than the original acceptance.
• Repeating a prompt after refusal until the user accepts.

Critique Questions

• Can users reject or customize with effort comparable to accepting?
• Are any optional purposes preselected or bundled into legal terms or another purpose?
• Does the product process, track, share, market, or train before the matching consent exists?
• Does refusal preserve eligible service access and task progress?
• Can users withdraw later from a stable route using the same purpose labels?
• Does the evidence record prove what prompt version, choices, and runtime behavior existed at the time of the decision?
• Is this a dark-pattern consent issue, or should the corrected surface be consent prompt, cookie consent, cookie banner, legal acceptance, preference center, or privacy settings?