Defaults must be set for the youngest plausible user

What it is

Age-appropriate defaults means that when a service's real user base includes minors, default settings should match the needs of the youngest plausible user: location off, profile private, contact by strangers disabled, personalized recommendation and profiling off, notifications and autoplay restricted. The rationale: children almost never audit settings — "providing settings" is, for a child, "no protection"; the default is the experience. Several jurisdictions have codified this, requiring services likely accessed by children to default to a high-protection state under a "best interests of the child" benchmark.

Why it happens

The power of defaults comes from stacked asymmetries of friction and cognition. Changing a default requires knowing it exists, understanding its consequences, finding the entry, and completing the action — and children in the most protective age band fail all four: unaware settings exist, unable to imagine what "public profile" makes visible, dependent on non-text interfaces, lacking any model of permission. Commercial incentives worsen the asymmetry: platforms profit from open defaults (wider distribution, sharper profiles), making children's privacy the cheapest sacrifice. Setting defaults to the youngest user flips the game: protection becomes the zero-action state, and abandoning it absorbs all the friction — with parental confirmation on the abandonment path.

Where it stops holding

"Youngest" needs a sensible floor: where a statutory minimum age applies, defaults should match that age band's plausible capability, not preschool level. Products with overwhelmingly adult populations and incidental child access would sacrifice adult experience by defaulting to the youngest; effective age tiering (differing defaults, not just content) substitutes for a single most-conservative default. Defaults also do not replace development: progressively opening features as age advances is the goal, not a one-day cliff.

Applying it

• Maintain an age-defaults checklist: location, profile visibility, stranger contact, recommendation personalization, profiling use of data, notification windows, autoplay, in-app purchases — each with a declared child-tier default.
• Route default changes through separate review: any proposal moving a child-tier default from protective to open needs ethics and legal co-signature.
• Reposition parental controls from "tighten" to "loosen": the default is the protective state; opening requires deliberate parental action and leaves a trace.
• Verify: instrument a freshly registered child-tier account and test the first-day experience — location off, stranger messages blocked, recommendations unpersonalized; any failure invalidates the default configuration.

Related

• Same group: P4.05.3 Age verification itself involves a privacy trade-off · P4.05.6 Location and social exposure risks are asymmetric for children
• Adjacent: O1.01 Defaults and privacy architecture · P4.04.6 Restraint applied to everyone beats differential treatment after identification
• Search terms: age-appropriate design · protective defaults · children's code