Compartmentalization and Pseudonymous Identifiers

How do pseudonymous or rotating identifiers reduce linkage?

Using pseudonyms or no identifiers weakens the link between an individual and communications, and periodically creating new or randomized identifiers reduces cross-interaction correlation; matching logs from an unauthenticated context with an authenticating context can make a previously unauthenticated user identifiable.

The mechanism is control over linkability. RFC 6973 explains that pseudonyms or the absence of identifiers can weaken the link between an individual and communications. It also explains that periodically creating new or randomized identifiers reduces the possibility that multiple interactions or communications can be correlated back to the same individual.

Separation can fail when records from two contexts can be matched. RFC 6973 gives a generic example: a site that does not directly authenticate users may match its HTTP header logs with logs from a site that does authenticate users, making a previously unauthenticated user identifiable.

The two mechanisms point in opposite directions. Identifier separation and rotation reduce correlation opportunities, while a matchable record shared across contexts can restore a link. This is a generic Internet-protocol privacy model, not a claim about any person, account, product, or service.

• Weaker linkage: use a pseudonym, omit an identifier, or create new or randomized identifiers for later interactions.
• Stronger linkage: retain a matchable identifier or log across contexts.
• Cross-context failure: matching an unauthenticated context's logs with an authenticating context's logs can make a user identifiable.

What strengthens pseudonymity, and what does this section not establish?

Pseudonymity is strengthened when less personal data can be linked to a pseudonym, the same pseudonym is used less often and across fewer contexts, and independently chosen pseudonyms are used more frequently for new actions; the RFC conditions above describe pseudonymity only, and this section does not define anonymity or state a legal distinction between pseudonymisation and anonymisation.

RFC 6973 describes three conditions under which pseudonymity is strengthened: when less personal data can be linked to the pseudonym; when the same pseudonym is used less often and across fewer contexts; and when independently chosen pseudonyms are more frequently used for new actions, which the RFC says makes them unlinkable from an observer's or attacker's perspective.

These conditions describe stronger pseudonymity. They do not supply a definition of anonymity, and they do not establish a legal distinction between pseudonymisation and anonymisation. Those concepts are outside what this section states.

Pseudonymity is therefore bounded by the data and contexts that can still be joined. A label can be pseudonymous while remaining linkable across repeated uses, and the RFC conditions explain how reducing those joins strengthens the separation.

• Stronger pseudonymity: less personal data is linked to the pseudonym.
• Stronger pseudonymity: the same pseudonym is used less often and across fewer contexts.
• Stronger pseudonymity: independently chosen pseudonyms are used more frequently for new actions.
• Boundary: these protocol conditions do not define anonymity or create a legal characterization.

Can a shared recovery channel reconnect identifier compartments?

Matching HTTP header logs from a site that does not authenticate users with logs from a site that does authenticate users can make a previously unauthenticated user identifiable; this example does not establish that any product shares a recovery email or phone number across accounts.

The documented linkage example concerns cross-context logs. RFC 6973 explains that a site without direct user authentication may be able to match its HTTP header logs with logs from another site that does authenticate users, making a previously unauthenticated user identifiable.

That mechanism shows why a matchable identifier or record can bridge compartments. It does not establish how recovery systems work, that a recovery email address or phone number is shared by any product, or that every recovery channel links accounts.

Recovery-channel behavior remains a separate evidence question. The protocol example supports the general risk of cross-context matching, but it does not support a product-level or universal claim about account settings.

• Documented example: match HTTP header logs from a non-authenticating site with logs from an authenticating site.
• Documented result: a previously unauthenticated user can become identifiable through the match.
• Not established: shared recovery email addresses, shared phone numbers, or universal account-linkage behavior.

What defeats identifier compartmentalization?

Persistent or infrequently replaced identifiers can facilitate correlation of activities and communications over time, including repeated use of the same device ID, certificate, or email address across interactions.

Persistence is the core limit. RFC 6973 explains that Internet protocols can facilitate correlation by allowing activities to be tracked and combined over time, and that persistent or infrequently replaced identifiers at any layer of the stack can facilitate that correlation.

The RFC names three generic examples: a device ID, a certificate, or an email address used persistently across multiple interactions. Repeated use can allow recipients or observers to correlate the communications over time.

This limit does not mean that every use of one of those identifiers produces identification. It identifies the correlation mechanism: repeated, matchable use creates a path for separate interactions to be treated as related.

Related pages cover Hardened Mobile Operating Systems: Isolation, Boot, and Updates, Email Alias Forwarding and Private Inboxes, and EU and Swiss Data Rights: Access, Erasure, Objection, and Complaints.

• Persistent identifier: the same value remains available across interactions.
• Infrequently replaced identifier: the value remains stable across enough interactions to facilitate correlation over time.
• RFC examples: a device ID, certificate, or email address used across multiple interactions.
• Bounded conclusion: persistence facilitates correlation; it does not by itself establish a fact about a person or account.