Forced action: functionality held hostage for consent
Aliases: bundled consent · forced consent · functionality hostage
What it is
Forced action bundles "using the feature" with "surrendering a right or data": agree to proceed, hand over your contacts to continue, install the app to read the article. Its defining feature is the hostage structure — "disagree" is not steered away but functionally excluded; where the other classes still leave a choice, forced action removes it.
Why it happens
The bundle works by rewriting what the user is evaluating: consent should be an independent judgement of "do I accept this term," and the bundle turns it into "how much do I want this feature" — an answer always inflated by task motivation, so the user says yes to one thing to get another. Bundling also destroys consent's separability: one could have approved only the necessary part; now it is all or nothing. The boundary against the other classes is sharp: interference biases a choice, obstruction punishes a choice, forced action cancels one. The grey zone is "reasonable bundling": a camera app demanding camera permission is functional necessity; a social app demanding contacts to use its core feature is hostage-taking — the test is whether what is demanded is necessary for the function in question, and necessity has an objective answer that does not follow commercial preference.
Studying it
Permission-demand research codes functional dependency: walking mainstream apps and tagging which permissions are core-function-necessary versus value-added collection, with the necessity rate as the base datum of forcedness. Experiments measure bundled consent's effect on agreement rates, post-hoc revocation, and regret; case-law research (GDPR enforcement of "refusal must not cost access") supplies the normative coordinate. Methodological caution: telling lab participants "you may refuse" itself changes behaviour, while real users do not default to knowing they hold a refusal right — measurements must separate "entitled and unused" from "never knew refusal was possible."
Where it stops holding
Business-model dependence is the grey zone: free services trade data for service, and whether that is "harsh terms" or hostage-taking depends on whether a real exit exists — with credible alternatives in the market it is negotiation, with exclusivity it is coercion. Functional necessity moves with technology: once a cheaper mechanism (invite-by-pick replacing contact-book scraping) exists, continued forced demand converts into forced action, so audits must be redone periodically. Legally, forced consent is clearly excluded under GDPR; other jurisdictions enforce unevenly, and compliance cannot substitute for design judgement.
Applying it
- Build a permission-to-function map: tag every demanded permission and consent with "which feature needs it"; anything unmapped may not be bundled — move it to point-of-use requests.
- Preserve a "minimal viable" path: after refusing non-essential authorization, core features stay usable; express consequences through degraded experience, not lockouts.
- Verification: negative-path testing — walk the entire flow with "refuse everything" and log each step; every lockout encountered is a forced-action residue and enters the fix queue.