Prefer picking individual contacts over a full address-book grant

What it is

Inviting one friend or filling one number needs those few contacts, not the whole address book. Prefer the system contact picker or "choose people to share," so the app only receives named rows. Jumping to "Allow Contacts" is a full dump: names, numbers, relationships, notes in one grant. This entry is about selection granularity for contacts. It is not about the photo library, and not about how a server keeps a contacts upload used for friend matching.

Why it happens

An address book is a sensitive social graph; ties among entries are worth more than a single number. The engineering reason for a full grant is "easier to find someone later." For the person, one invite prepays the whole graph. A picker keeps the capability inside system UI: the app gets result rows, not an API to enumerate the table. When granularity fails, people who refuse the full grant cannot even pick one number. The feature is bound to the widest tier, so both grant rate and privacy get worse.

Where it stops holding

Device management, emergency-contact sync, and tools the person explicitly asked to "back up the whole book" are full-access tasks; copy must say "we will read every contact" and remain revocable. On older platforms with no contact picker, fall back to typing a number plus optional full access—do not make full access the only door. An enterprise directory and a personal address book are not the same table; the picker should name the source.

Applying it

• Default entry is the system contact picker or a searchable "choose people" UI. Product paths that need only a few rows do not request the full contacts permission.
• For several people, allow sequential picks or a multi-select, rather than upgrading to full access.
• Put the full-access ask only on features that truly traverse the book (sync / backup / match all friends), and say that the whole book will be read.
• Verify after "invite one friend / fill one number": contacts in system Settings should be not-determined or selected-only. If it is full access, the entry was wrong. After refusing full access, the picker path should still work.

Related

• Within the group: H4.09.2 Photo access splits into selected items versus the whole library · H4.09.3 Uploading contacts to match friends must say how the server will keep them · H4.09.4 After fine-grained pickers exist, a full-access ask is harder to justify
• Adjacent: H4.08 Camera and Microphone Permission · O1.02 Data Minimization · O1.10 Consent Granularity and Withdrawal
• Search terms: contact picker · limited contacts · address book permission