Why Device Binding Is Not the Same as Tracking

Both device binding and cross-site tracking involve recognising a device, which makes them sound like the same capability applied to different ends. Structurally they are opposites, and the difference is worth stating precisely.

Binding is scoped to one relationship

When a service binds a credential to a device, it stores something that only means anything to that service. A key registered with one bank identifies the device to that bank and to nobody else.

The identifier is generated for the relationship rather than derived from the device, so it carries no information about the hardware and cannot be recognised by another party.

The user is also a participant. Binding happens during an explicit enrolment step, and the user knows the relationship exists because they created it.

Tracking depends on recognition without a relationship

Cross-site recognition requires an identifier that is the same everywhere, derived from properties of the device rather than issued by any one party.

That is precisely what makes it work across sites that have no arrangement with each other, and precisely what makes it impossible for a user to scope or revoke.

The user is not a participant in this. Nothing is enrolled, nothing is presented for approval, and nothing indicates that recognition occurred.

Revocation behaves completely differently

A bound credential can be removed from the service's records, and once removed the device is unrecognisable to that service. The user can usually do this themselves from an account settings page.

A derived fingerprint cannot be revoked, because nothing was stored to remove. The properties that produce it continue to exist and continue to be observable on every visit.

This asymmetry is the clearest practical test of which mechanism is in use: if the user can turn it off and verify it is off, it is binding.

The security properties differ too

Binding provides a real guarantee, since possessing the key requires possessing the device and the key is protected by hardware that does not release it.

Fingerprint recognition provides a probability, since another device with the same configuration produces the same value and configurations are frequently shared.

Using a fingerprint where a binding is needed produces a control that can be satisfied by matching a configuration rather than by holding a device, which is a much weaker requirement than intended.

Regulators treat them differently for good reason

Consent frameworks generally distinguish processing that is strictly necessary for a service the user requested from processing that serves other purposes.

A binding the user enrolled in to secure their own account sits comfortably in the first category. Passive recognition for purposes the user never asked about sits in the second, and conflating the two in a privacy notice is a reliable way to lose the argument.