Protect identity by separating identifiers from relationship paths

Separate login, display and public identity

Start with three rows. Login identity includes email, phone number, external sign-in account and recovery details; it should authenticate the account without automatically becoming a public label. Display identity is the name and image used inside a private experience. Public identity includes a searchable handle, shared profile or attribution attached to community content. For each row, record the exact value, where it appears, who can see it and whether changing it also changes another service. Google’s current profile controls illustrate why this separation matters: phone or email can participate in discovery, while an abbreviated name and profile picture have their own visibility choices for people who have not interacted with the account.

Map contact discovery before granting access

Before allowing contacts, ask what operation follows the permission. Is the app checking selected entries on the device, uploading an address book, matching phone or email values, creating invitations, or retaining a discovery result? Apple’s current iPhone controls let a user grant limited access to selected contacts and revise access later. Use the narrowest option that completes the intended action, such as selecting one person or sharing one invite manually. Record whether refusing contacts still permits ordinary use. Permission scope answers what the app can read now; it does not by itself explain what was already uploaded, derived or retained, so keep those as separate questions.

Recognize a social graph as information about several people

A contact list describes more than the account holder. Names, phone numbers, relationship labels, groups and repeated communication patterns can reveal a social graph. Apple’s App Privacy definitions explicitly include a phone contact list, address book or social graph in the Contacts data type and separately ask whether data is linked to identity. In the six-column map, give every relationship path six fields: data item, original source, identifier class, visible audience, link trigger and rollback check. A “find friends” button is therefore not a single yes/no setting. One row may cover the address book, another matched accounts, another invitations, and another mutual-connection suggestions.

Inspect links, profiles and cross-service joins

Test every surface that can carry identity outward. A profile link may show a display name in its preview even when the destination needs sign-in. A conversation share link may reveal author attribution, timestamps or a stable account handle. External sign-in can connect an app account to an identity provider; cross-device sync can restore a display name or contact setting on a second device. These are potential paths to inspect, not claims that every app uses them. Open the share preview without posting, review connected-account settings at both ends, and note whether changing a display name propagates elsewhere. Keep this article focused on user-visible linkage rather than advertising profiles or vendor lists.

Choose a narrow setup and test the outside view

Choose a minimal setup first: private display name, no address-book access, discovery by phone or email disabled when the feature allows it, no public handle, and manual sharing to a known recipient. Then enable only the feature you actually want. Check the view from a signed-out browser or the app’s preview, without creating a fake persona or probing another person’s account. Compare the visible name, picture, link title, searchable fields and mutual-connection clues with your map. NIST’s Privacy Framework supports inventorying and managing privacy risk across data processing; here the useful personal adaptation is a dated boundary map, not a claim of formal compliance.

Disconnect, delete and verify as separate actions

Revoke, unlink and delete are different tests. Revoking contacts stops future access at the operating-system boundary but may not describe prior uploads. Disconnecting an external sign-in may remove a login route without deleting the app account. Deleting a share link may not remove a screenshot or a recipient’s copy. Ask the service what each control changes, record the completion time, and revisit the outside view after the stated update window. During account deletion, check whether discovery matches, imported contacts and connection edges are named in the scope. Mark each row closed, still visible or unknown; do not convert an invisible system into a certainty. The map is complete when every identity link has an owner and a verifiable end state.

Keep exploring this topic