Forced action · European Union
Forced disclosure or excessive data request
The label “Forced disclosure or excessive data request” describes this recurring design mechanism: access or progression is conditioned on disclosing personal information that appears unnecessary, excessive or used for an insufficiently explained secondary purpose. It is a design and research taxonomy, not a standalone legal conclusion. Depending on the complete journey and likely effect, current EU consumer or sector rules may require separate assessment. No published Digital Fairness Act proposal currently creates a pattern-specific prohibition or duty under this label.
- Family
- Forced action
- Also known as
- Journey stages
Definition
What is this pattern?
Access or progression is conditioned on disclosing personal information that appears unnecessary, excessive or used for an insufficiently explained secondary purpose. The label describes a recurring design mechanism; whether a particular implementation is harmful or unlawful depends on the complete journey, audience, evidence and rules within scope.
How it works
Access or progression is conditioned on disclosing personal information that appears unnecessary, excessive or used for an insufficiently explained secondary purpose. The interface makes apparently disproportionate personal information a prerequisite and withholds the selected result when a field or permission is refused.
Warning signs
- Personal data is mandatory or refusal blocks a desired goal.
- Necessity is apparently unrelated, disproportionate or unexplained.
- The requested data creates a plausible privacy or choice detriment.
Potential harms
- The visitor must disclose identity and contact information that is unrelated to a preliminary delivery-availability check.
- The user may disclose more personal information than the preliminary comparison reasonably needs.
Learn by comparison
What does this look like?
These fictional examples make the design mechanism easier to recognise. They do not depict a real company and do not establish that an individual interface is unlawful.
Illustrative example 1 · Furniture delivery estimate
A fictional furniture shop requires a visitor to disclose an exact birth date and mobile number before showing whether delivery is available to the entered postcode.
Potential consumer harm: The visitor must disclose identity and contact information that is unrelated to a preliminary delivery-availability check.
Illustrative example 2 · Insurance comparison
A fictional comparison tool requires occupation, exact birth date, mobile number and marketing preference before showing the plans that are available in a postcode.
Potential consumer harm: The user may disclose more personal information than the preliminary comparison reasonably needs.
Exact birth date required for a delivery estimate
A fictional furniture shop requires a visitor to disclose an exact birth date and mobile number before showing whether delivery is available to the entered postcode.
Tell us who you are first. Birth date and mobile number block a postcode-based availability estimate.. Exact date of birth: Enter exact date of birth. Mobile number: Enter mobile number. Delivery postcode: Enter delivery postcode. Submit personal details
Check delivery availability. The estimate uses the postcode; contact details remain optional until booking.. Delivery postcode: Enter delivery postcode. Show delivery estimate. Purpose and refusal effect, expanded: The form explains why “Show delivery estimate” is requested and what happens if it is not used.
Why the first version can mislead: The additional dependency controls access to the pricing goal. The panel states: “Birth date and mobile number block a postcode-based availability estimate.” Reviewers need to establish whether “Submit personal details” is necessary for the selected task or pressures the user into a separable action. The visitor must disclose identity and contact information that is unrelated to a preliminary delivery-availability check.
What a fairer design does: Use the postcode for the estimate, explain any genuinely necessary field and defer contact details until the visitor asks to book or save it.
Show annotated differences (2)
- Submit personal detailsIn “Exact birth date required for a delivery estimate”, this element shows how forced disclosure or excessive data request can shape the decision.
- Purpose and refusal effect, expanded: The form explains why “Show delivery estimate” is requested and what happens if it is not used.In “Exact birth date required for a delivery estimate”, this element keeps the clearer alternative visible at the same decision point.
Review questions (3)
- What functional need makes “Submit personal details” necessary for the furniture delivery estimate goal, and can that need be met with less disclosure or commitment?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “Personal data is mandatory or refusal blocks a desired goal”?
- Could the stated purpose make this dependency genuinely necessary under the boundary “Data evidently required for delivery, payment, security, age, safety or law”, and what product evidence would demonstrate that necessity?
Excessive details for product comparison
A fictional comparison tool requires occupation, exact birth date, mobile number and marketing preference before showing the plans that are available in a postcode.
Tell us everything first. Four personal fields block access to a basic plan comparison.. Occupation: Enter occupation. Exact date of birth: Enter exact date of birth. Mobile number: Enter mobile number. Not selected: Receive comparison offers. Reveal plans
Compare available plans. Postcode and the minimum eligibility facts are requested with a reason.. Postcode: Enter postcode. Relevant eligibility facts: Enter relevant eligibility facts. Show plans. Purpose and refusal effect, expanded: The form explains why “Show plans” is requested and what happens if it is not used.
Why the first version can mislead: The additional dependency controls access to the pricing goal. The panel states: “Four personal fields block access to a basic plan comparison.” Reviewers need to establish whether “Reveal plans” is necessary for the selected task or pressures the user into a separable action. The user may disclose more personal information than the preliminary comparison reasonably needs.
What a fairer design does: Ask only for information needed for the comparison, explain why each field matters and defer contact details until the user requests follow-up.
Show annotated differences (2)
- Reveal plansIn “Excessive details for product comparison”, this element shows how forced disclosure or excessive data request can shape the decision.
- Purpose and refusal effect, expanded: The form explains why “Show plans” is requested and what happens if it is not used.In “Excessive details for product comparison”, this element keeps the clearer alternative visible at the same decision point.
Review questions (3)
- What functional need makes “Reveal plans” necessary for the insurance comparison goal, and can that need be met with less disclosure or commitment?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “Necessity is apparently unrelated, disproportionate or unexplained”?
- Could the stated purpose make this dependency genuinely necessary under the boundary “voluntary field with a clear skip path and purpose”, and what product evidence would demonstrate that necessity?
What is a fairer alternative?
Request only data necessary for the current goal, make secondary uses optional, and explain purpose and consequences clearly.
Legal and information status
Legal position at a glance
Access or progression is conditioned on disclosing personal information that appears unnecessary, excessive or used for an insufficiently explained secondary purpose. The interface makes apparently disproportionate personal information a prerequisite and withholds the selected result when a field or permission is refused. Risk increases where the mechanism changes a material consumer choice, hides a consequence or makes a genuine alternative harder to use. The taxonomy label remains a review prompt and does not establish an infringement.
Dark-pattern research taxonomy
Editorial analysis
The cited research sources support identification and comparison of this recurring interface mechanism. They do not determine that a particular interface is unlawful.
UCPD Articles 5 to 9, where applicable
Possible risk indicator
Depending on the trader, audience, overall presentation, material information and likely transactional effect, the facts may require a separate assessment under the applicable UCPD provisions.
Evidence layers and open questions
Applicable law, enforcement records, policy preparation, stakeholder input, editorial analysis and unknown future details remain visibly distinct.
Current lawCurrent law
The UX label “Forced disclosure or excessive data request” is not a standalone EU offence. Depending on the trader, audience, complete presentation, omitted information and likely transactional effect, the observed facts may require a separate assessment under the applicable UCPD provisions or another instrument within scope.
Under considerationUnder consideration
The Commission is preparing a Digital Fairness Act initiative, but the call for evidence does not select a final rule for forced disclosure or excessive data request or establish that this taxonomy term will appear in a proposal.
Editorial analysisEditorial analysis
The pattern definition, variants and examples on this page use the cited research taxonomy sources to support recognition and comparison. That analytical classification is not a legal conclusion about an individual interface.
UnknownUnknown
No published DFA proposal currently establishes a definition, covered actor, legal threshold, duty, remedy, transition rule or application date for forced disclosure or excessive data request. Those details remain unknown pending primary legislative text.
Context matters
Context and boundary cases
- Personal data is mandatory or refusal blocks a desired goal.
- Necessity is apparently unrelated, disproportionate or unexplained.
- The requested data creates a plausible privacy or choice detriment.
- Exclude or qualify the label where data evidently required for delivery, payment, security, age, safety or law.
- Exclude or qualify the label where voluntary field with a clear skip path and purpose.
When a similar design can serve a legitimate purpose
- A similar design should not be classified this way where data evidently required for delivery, payment, security, age, safety or law.
- A similar design should not be classified this way where voluntary field with a clear skip path and purpose.
Operational review
What teams should review
- Teams
- What functional need makes “Submit personal details” necessary for the furniture delivery estimate goal, and can that need be met with less disclosure or commitment?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “Personal data is mandatory or refusal blocks a desired goal”?
- Could the stated purpose make this dependency genuinely necessary under the boundary “Data evidently required for delivery, payment, security, age, safety or law”, and what product evidence would demonstrate that necessity?
- What functional need makes “Reveal plans” necessary for the insurance comparison goal, and can that need be met with less disclosure or commitment?
- Which fields or permissions are required, what happens on refusal, and does the resulting state support this criterion: “Necessity is apparently unrelated, disproportionate or unexplained”?
- Could the stated purpose make this dependency genuinely necessary under the boundary “voluntary field with a clear skip path and purpose”, and what product evidence would demonstrate that necessity?
- Which complete journey evidence supports or contradicts the forced disclosure or excessive data request classification?
Evidence to retain
- Versioned captures of the Pricing states before, during and after the relevant decision
- Configuration, content and event records supporting the observed forced disclosure or excessive data request mechanism
- Responsive, keyboard and assistive-technology review of every material option and consequence
- Control defaults, validation rules and consent or selection state changes
Legal map and implementation tools
Evidence base
Sources
- Dark commercial patternsOrganisation for Economic Co-operation and Development · Secondary · checked 2026-09-14 · OECD Digital Economy Papers No. 336
- Unfair Commercial Practices DirectiveEuropean Parliament and Council of the European Union · Primary · checked 2026-08-09 · Directive 2005/29/EC; CELEX 02005L0029-20220528
- Digital Fairness Act: call for evidence for an impact assessmentEuropean Commission · Primary · checked 2026-08-09 · Initiative 14622; Ares(2025)6275573
- Commission work programme 2026: Europe's Independence MomentEuropean Commission · Primary · checked 2026-09-14 · COM(2025) 870 final; CELEX 52025DC0870; Annex I item 30