Practice · 03

Privacy engineering

A product can encrypt well and still assemble a person out of radio crumbs, device graphs, and “anonymous” events.

Unlinkability fails when identifiers from different layers are allowed to meet.

Privacy work at NIIS 9 is not a policy overlay. It is an engineering analysis of identifiers, retention, and inference, especially for products that must speak in public spectrum. Randomized MACs, SUCI, rotating advertising tokens, and hashed analytics IDs all fail in the same family of ways: a stable join key hiding in a lower layer, a log, or a customer-support tool.

LINDDUN, with radios on

The practice uses LINDDUN-shaped questions (linkability, identifiability, non-repudiation, detectability, disclosure, unawareness, non-compliance) and then adds the air interface as a first-class data store. Detectability of a device at a doorway is a privacy event. So is a support engineer’s ability to paste a BLE address into a ticket.

What a review looks at

  • Identifier inventories across radio, OS, app, and backend.
  • Join paths that product language calls “anonymous.”
  • Retention and access in telemetry, crash, and customer-operations systems.
  • User-facing controls that do not actually change the graph.
If two events can be joined, someone will eventually join them. First for debugging, then for a dashboard.

Related note: the IMSI is not the identity