C9.08.3Fusion confidence versus privacy scopedesignresearch

Fusion raises confidence while widening the kinds of data collected and the privacy scope

Aliases: fusion privacy · data-type expansion · confidence cost

What it is

One more sensor can sharpen the posterior—and adds a kind to the collection list: location, audio, EDA, imagery. The privacy cost of fusion is not “the same heart rate stored twice.” It is type expansion: an attacker or an in-house model can infer attributes that no single channel was allowed to infer. Confidence and exposure are tied in the same decision.

Why it happens

Information-theoretically, the set of hypotheses identifiable from the joint is larger than from either margin. Heart rate poorly separates “in a meeting” from “running”; add microphone energy and GPS and it can. Products often sell fusion as one switch (“smarter”); users still see a single permission name while authorizing a vector. Type expansion also changes the unit of leakage: a log goes from a health metric to a re-identifiable trajectory because combinations of heterogeneous features are more unique. Even if fusion finishes on-device and the cloud receives only labels, the labels may already be a sufficient statistic of a high-dimensional inference.

Studying it

Run an attribute-inference attack: predict unauthorized labels from fused features versus from each channel. Factors: which data types are added, whether only fused labels are uploaded. Outcomes: primary-task confidence (calibrated Brier or expected calibration error), attack accuracy, and the gap between what users think is collected and what is. Permission-UI studies should measure how well separate per-type grants versus one master switch match the actual collection set.

Where it stops holding

Redundancy of the same type (two accelerometers) expands reliability, not a new attribute axis, so the privacy increment is smaller. Legally required minima (location with an emergency call) should be labeled apart from optional fusion. Discarding raw streams on-device and keeping only short-lived state can confine type expansion to device lifetime, but label inversion still has to be blocked. Children and bystanders are collateral of type expansion: they never granted that microphone or camera.

Applying it

  • List fusion by data type with a default minimum set; extra types need their own grant and must not be one-tapped on via “improve accuracy.”
  • Write the confidence target as a number (for example calibrated expected error) and stop adding types once it is met.
  • Default exports and cloud to primary-task labels; leave type detail on the device.
  • Verify by predicting, from a fused log, an attribute that does not appear in the informed notice; if it is predictable, either write it in or drop that type from fusion.

Related

  • Same group: C9.08.1 Noise and blind spots of a single sensor can be offset by fusing other sensors · C9.08.2 Fusion must time-align sensors whose rates and latencies disagree · C9.08.4 When one sensor fails, a fused system should degrade rather than fail as a whole
  • Adjacent: C9.04 Respiration and Posture Sensing · C8.07 Sensitivity of Eye-Tracking Data
  • Search: fusion privacy · attribute inference · data-type expansion

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/C9.08.3