O1.04.1Privacy by defaultdesignresearch

The default should be the most privacy-protective option

Aliases: protective defaults · privacy-friendly defaults · default privacy

What it is

Privacy by default means that a person who changes no settings receives the least collection, visibility, sharing, and retention compatible with the task they explicitly requested. “Most protective” does not require disabling every capability; it means not enabling additional exposure on the person's behalf. A stricter option buried in settings does not compensate for an overexposing initial state.

Why it happens

Defaults are sticky because they look endorsed, while changing them requires discovery, consequence prediction, and risk of breaking the service. Most people remain in the preset state, so the designer effectively decides privacy for a population. Protective defaults also place the cost of information asymmetry on the party that understands the system. Valuable extra processing must earn an affirmative choice through explanation rather than benefit from silence.

Studying it

Researchers can instrument untouched new accounts to record fields collected, network recipients, external visibility, and retained state, then compare alternative defaults experimentally. Outcomes include task success, later revision, comprehension, regret, and unexpected exposure. Studies should distinguish availability of the core service from pre-enablement of every add-on and control for endorsement labels, option order, and prompt timing.

Where it stops holding

The protective state depends on context and the requested task. Precise location may be necessary during active navigation, but persistent background location does not follow automatically. Collaboration-space visibility cannot simply inherit a private-account default. Emergency, security, and accessibility features may warrant different presets when justified by risk and reversibility. Administrator-selected defaults must also separate organizational interests from members' reasonable expectations.

Applying it

  • Define no-action acceptance states separately for collection, location, contacts, profile visibility, disclosures, and retention.
  • Make new objects visible only to the smallest audience needed for the task, expanding through deliberate authorization.
  • Review core-task success alongside default exposure instead of treating convenience from pre-enabled add-ons as decisive.
  • Run registration and core journeys with untouched accounts on multiple devices, inspecting traffic, other-user views, and later storage; correct any automatic non-essential datum or audience.

Related

  • Same group: O1.04.2 Privacy-affecting features should be opt-in, not opt-out · O1.04.3 Updates must not silently weaken defaults
  • Adjacent: O1.01 Privacy design · O1.10 Consent granularity and withdrawal
  • Search terms: privacy by default · protective defaults · default effect

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/O1.04.1