Forced action · Australia
Forced disclosure or excessive data request
Forced disclosure or excessive data request is a working label for this design mechanism: Access or progression is conditioned on disclosing personal information that appears unnecessary, excessive or used for an insufficiently explained secondary purpose. This is editorial implementation guidance for Australian journeys, not a finding of unlawfulness. From 1 July 2027, a similar interface is relevant to ACL section 28B only if the complete consumer-connection, manipulation or unreasonable-distortion and actual-or-likely-detriment test is met. Current ACL rules require a separate assessment.
- 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. This is a design and research taxonomy for learning and evidence review, not a statutory offence label or an automatic finding that an interface is unlawful.
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 · 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.
Potential consumer harm: The visitor must disclose identity and contact information that is unrelated to a preliminary delivery-availability check.
Illustrative example 2 · 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.
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 (4)
- Birth date and mobile number block a postcode-based availability estimate.Why this state matters: 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.
- Submit personal detailsReview prompt: 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?
- The estimate uses the postcode; contact details remain optional until booking.Fairer design: Use the postcode for the estimate, explain any genuinely necessary field and defer contact details until the visitor asks to book or save it.
- Purpose and refusal effect, expanded: The form explains why “Show delivery estimate” is requested and what happens if it is not used.Review prompt: 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”?
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 (4)
- Four personal fields block access to a basic plan comparison.Why this state matters: 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.
- Reveal plansReview prompt: What functional need makes “Reveal plans” necessary for the insurance comparison goal, and can that need be met with less disclosure or commitment?
- Postcode and the minimum eligibility facts are requested with a reason.Fairer design: Ask only for information needed for the comparison, explain why each field matters and defer contact details until the user requests follow-up.
- Purpose and refusal effect, expanded: The form explains why “Show plans” is requested and what happens if it is not used.Review prompt: 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”?
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
How Australian law may apply
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. These harms describe a review risk, not an automatic legal conclusion. Australian section 28B commences on 1 July 2027 and requires its complete, context-specific test. Existing ACL provisions remain a separate current-law assessment.
ACL section 28B, inserted by the 2026 Act
Possible risk indicator
In pricing journeys, the forced disclosure or excessive data request mechanism may warrant review where it manipulates a consumer or unreasonably distorts the decision environment and causes, or is likely to cause, detriment. The forced action label and an interface similarity do not establish a contravention; the complete section 28B test, scope, facts and evidence must be applied from 1 July 2027.
Dark-pattern research taxonomy
Editorial analysis
The cited research sources support this working pattern within the forced action family. It is editorial implementation guidance, not an Australian statutory category, regulator finding or legal safe harbour.
Evidence layers and open questions
Applicable law, enforcement records, policy preparation, stakeholder input, editorial analysis and unknown future details remain visibly distinct.
Final Act mappingEditorial implementation guidance
This editorial practice label is not itself an express statutory prohibition. Apply the complete provision and its scope to the facts.
Possible general-test applicationCommences 1 July 2027
ACL section 28B, inserted by the 2026 Act: In pricing journeys, the forced disclosure or excessive data request mechanism may warrant review where it manipulates a consumer or unreasonably distorts the decision environment and causes, or is likely to cause, detriment. The forced action label and an interface similarity do not establish a contravention; the complete section 28B test, scope, facts and evidence must be applied from 1 July 2027.
Existing ACLCurrent enforcement
Existing ACL provisions continue to apply on their own elements before and after commencement. The 2027 provisions must not be applied early.
Verified enforcement contextCurrent enforcement
No named pattern-specific enforcement example is asserted on this page. Existing ACL analysis remains fact-specific and separate from the 2027 provisions.
RegulationsRegulation pending
Later regulations may affect specified exclusions, matters or exceptions. That uncertainty does not postpone a core enacted rule unless the provision itself depends on prescription.
Regulator implementation materialGuidance pending
Government funding and parliamentary material anticipate regulator education and guidance. No dedicated final ACCC implementation guide is treated here as published.
Journey and evidence recommendationsEditorial implementation guidance
Request only data necessary for the current goal, make secondary uses optional, and explain purpose and consequences clearly. This is editorial portal guidance, not a statutory duty, regulator safe harbour or compliance certificate.
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.
- Boundary to test: Data evidently required for delivery, payment, security, age, safety or law
- Boundary to test: voluntary field with a clear skip path and purpose
When a similar design can serve a legitimate purpose
- Data evidently required for delivery, payment, security, age, safety or law
- 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?
Evidence to retain
- Annotated pricing screenshots at each responsive breakpoint
- The complete state sequence before, during and after the consumer decision
- Design-system component, content, default and configuration records for the reviewed release
- Operational records substantiating price, availability, timing and eligibility claims
- Usability, accessibility, reversal, complaint and support evidence relevant to consumer impact
- A dated product and legal review record identifying evidence, uncertainties and release decisions
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
- Competition and Consumer Amendment (Unfair Trading Practices) Act 2026Federal Register of Legislation · Primary · checked 2026-09-14 · C2026A00064
- Competition and Consumer Act 2010, including Schedule 2: Australian Consumer LawFederal Register of Legislation · Primary · checked 2026-09-14 · C2004A00109
- Unfair trading tricks and traps to be bannedTreasury Ministers · Primary · checked 2026-09-14
- Inquiry into the Competition and Consumer Amendment (Unfair Trading Practices) Bill 2026Senate Economics Legislation Committee · Primary · checked 2026-08-09