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