Updates must not silently weaken privacy defaults

What it is

Privacy-preserving migration keeps a person's existing protection level from silently decreasing after an upgrade, feature redesign, or account merger. A release may add controls, but must not activate previously disabled processing, widen an old object's audience, or convert a refusal into “unset” through schema renaming. The migrated state should preserve expressed intent, not merely fit a new configuration format.

Why it happens

Updates are commonly automatic, and people reasonably expect continuity rather than a fresh audit of every data flow. A technically convenient migration sends missing or unmappable values to the new-user default, creating a privacy regression. Because the change occurs backstage and its consequences may appear later, users struggle to detect its cause or intervene before the first new processing event.

Studying it

Teams can construct migration matrices spanning legacy settings, account ages, and device combinations, comparing effective permissions, flows, audiences, and retention before and after upgrade. Differential tests expose configurations whose stored values remain alike while semantics change; usability tests assess whether change summaries support accurate predictions. Clean-install tests miss migration risk, and averages obscure severe regressions in rare sensitive states.

Where it stops holding

A security fix may need to tighten or replace a legacy option, and service retirement may make an old state impossible; both still require explicit explanation. When old and new models lack a one-to-one mapping, choose a conservative state that does not expand processing or pause the capability instead of inferring preference. A routine update notice is not renewed consent, especially when refusal removes an existing paid or depended-upon function.

Applying it

• Define semantic mappings and “no more open” invariants for every privacy-relevant setting, rather than migrating boolean values alone.
• Place unmappable states into minimum processing and request a decision before any new collection or disclosure.
• Explain concrete differences in audience and data flow, with a one-step route back to the earlier protection level.
• Upgrade fixtures representing legacy states and compare permissions, traffic, other-user views, and retention; treat any exposure increase without affirmative choice as release-blocking.

Related

• Same group: O1.04.1 The default should be the most privacy-protective option · O1.04.2 Privacy-affecting features should be opt-in, not opt-out
• Adjacent: O1.03 Purpose limitation · O2.07 Scannable privacy policies
• Search terms: privacy-preserving migration · privacy regression · configuration migration