Uploading contacts to match friends must say how the server will keep them

What it is

If "see who already uses this" sends the address book to a server for matching, the ask must say which fields leave the device, cleartext or digest, how long the server keeps them, whether unmatched numbers are stored, and whether they can be deleted. "Used to find friends" is not a retention notice. This entry is about upload-and-keep disclosure. It is not about whether picking one contact on-device is enough, and not about photo granularity.

Why it happens

Picking a contact locally hands the app one row. Friend matching hands the server a social graph, used to intersect users, fill in non-users, sometimes to recommend or advertise. People's default model is "check and throw away"; common practice is a long-lived hash table and repeated invite attempts on unregistered numbers. Without retention disclosure, "this lookup" cannot be distinguished from "turn my address book into your growth asset." When keep-behavior is later discovered, even a useful matcher is counted as deception, because that table was not what was agreed to.

Studying it

Write two notices for the same matcher: "deleted after the check" versus "digests kept for later matching." Test predictions before the choice.

Independent variables: whether copy says data leaves the device, whether it names a retention period, whether it names the fate of unregistered numbers. Dependent variables: judgment of "does the server still have my friends' numbers," allow rate, anger and revoke after real retention is shown.

An allow-rate lift from hiding retention measures successful deception. Audits have to match actual upload and deletion logs, not copy. Lab "matching" has no real social stakes; product logs and regulatory samples matter more.

Where it stops holding

An on-device-style intersect that still sends a digest of one's own number must still say "a digest leaves the device," even if no profile is built. Legally required retention should name duration and purpose, not hide in page seventeen of a policy. A user-initiated address-book backup is a different consent and cannot cover this matching flow.

Applying it

• On the matcher's pre-prompt, short sentences must list: fields uploaded, hashed or not, retention period, whether unmatched contacts are stored, how long after revoke until deletion.
• Offer a no-upload alternate: share a link, type the other person's account. A failed match must not trigger a second full-book ask.
• When matching is revoked or contacts permission is turned off, fire the server deletion named in the notice, and report completion.
• Verify by asking uninvolved people, after reading the notice, to sketch where the data goes. If they cannot say whether numbers remain on a server, disclosure failed. Then run a test number through matching and check whether the server can still hit that number after the claimed period.

Related

• Within the group: H4.09.1 Prefer picking individual contacts over a full address-book grant · H4.09.2 Photo access splits into selected items versus the whole library · H4.09.4 After fine-grained pickers exist, a full-access ask is harder to justify
• Adjacent: O2.13 Disclosure of Third-Party Data Sharing · O1.03 Purpose Limitation · H4.04 Revocable Permissions
• Search terms: contact matching · address book upload · retention disclosure