Repeated permission dialogs are a dark pattern

What it is

After someone has refused or deferred a permission, showing the system authorization alert again—or an equivalent full-screen gate—without a new task reason, until they Allow, is permission nagging. It is not the whole dark-pattern catalogue: not visual bias toward one button, not hidden prices, not a fake system window. It covers only this cross-time asymmetry: refusal has to be restated again and again, while a single Allow is remembered.

Why it happens

A system permission dialog interrupts the current action; dismissing it costs a burst of attention. Binding the same ask to every launch, every refresh, or every tap turns Don't Allow into a standing tax and Allow into the only way to stop the tax. That final tap means both "make the sheet go away" and "grant the capability," so it cannot be read as preference. A "remind me later" with a tiny cooldown does the same job: deferral is implemented as "come back next foreground." After platforms block a second system dialog, the equivalent harassment moves to in-app full screens, badges, or fake system chrome. The mechanism is unchanged; only the API is bypassed.

Studying it

Use multi-session tasks, not a single-dialog experiment. After a refusal, let people continue ordinary work and log the gap to the next permission interruption, the trigger, and whether the choice changes.

Independent variables: re-prompt interval, whether a fresh user action is required, whether an in-app full screen counts as a "dialog." Dependent variables: time from denial to allow, self-report that they allowed only to stop the interruption, number of task breaks, later uninstall.

A single lab session misses cumulative pressure. Interviews have to split "changed my mind," "mis-tap," and "I just wanted it to stop." Do not treat final allow rate as a positive metric—nagging strategies inflate it; that is fatigue, not consent.

Where it stops holding

If purpose, scope, or risk actually changed (one-shot location becoming continuous background location), asking again after explaining the change is not nagging—but the change has to be named. Someone tapping "Enable" themselves, or re-entering a feature that plainly needs the capability, is a new user action, not harassment. Security alerts (a broken certificate, a device-management change) are out of scope. A short "later" that was never stored as a refusal should still have a predictable interval and a way to stop reminders.

Applying it

• Store denial as stable state: within the same install, do not call the system permission API and do not show a full-screen gate until a new feature action appears.
• "Later" needs an explicit cooldown during which the main path is silent. After the cooldown, only a dismissible in-app reminder is allowed; the system dialog fires only after a tap.
• Do not recycle the same denial with badge counts, fake system alerts, or a full screen on every cold start.
• Verify by refusing, then using the main task across at least three sessions, including kill-and-relaunch. Any permission interruption without a new action is a defect. If Allow events sit immediately after those interruptions, grant rate must not be treated as willingness.

Related

• Within the group: H4.03.1 After a denial, the rest of the product must still work · H4.03.2 The fallback has to be stated, not implied
• Adjacent: O2.06 Consent Interface Design and Abuse · O4.02 A taxonomy of dark patterns · H4.04 Revocable Permissions
• Search terms: permission nagging · repeated permission prompt · consent nagging