After fine-grained pickers exist, a full-access ask is harder to justify

What it is

Once the system offers pickers for selected photos or selected contacts, a product that still asks for full access has to prove, on its own, that enumerating the whole library or address book is irreplaceable for the current task. "There was no other API" used to count. After pickers, it does not. Sending an image, inviting someone, changing an avatar default to the picker; full access becomes an exception that needs a defence. This entry is about how justification shifts when platform capability shifts. It is not how to use the picker, and not what a server keeps after friend matching.

Why it happens

The minimum sufficient set for a grant moves with the means available. With no picker, full access was the only technical path to "attach one image," so necessity held. With a picker, the sufficient set for that task shrinks to the chosen files; full access becomes "for later convenience, for analytics, for preload"—none of which is the job in progress. Keeping full access as the default re-bundles granularity the platform already split. People see "Selected Items" on the system sheet and are steered toward "Allow All," and the picker's protection is bypassed. Weaker justification is not a moral slogan. It is task–capability fit: the means changed, so the old "must" is no longer true.

Where it stops holding

Whole-library backup, faces grouping, a read-only enterprise directory, and OS versions with no picker can still have full access as the minimum sufficient set. An app that serves both new and old systems should branch on capability: picker where it exists, not one full-access ask for code uniformity. If the person themselves chooses All on the system sheet, the product may accept it—but must not push them off Selected with a larger button or a scare line that the feature otherwise cannot run.

Applying it

• Branch on whether a picker exists: if it does, the main path does not call the full-access API. Put full access on manage/backup only, and say why the picker is not enough.
• When the system sheet offers Selected versus Allow All, the app's pre-prompt should aim at Selected; do not paint All as the recommendation.
• Audit launch-time library or contacts requests in old code; switch what can go through a picker, and record which remaining features still need full access and why.
• Verify: on a system that has pickers, finish send and invite on the main path with full access still unrequested. List every feature that fires a full-access dialog; each must answer "why the picker is not enough." Delete triggers that cannot.

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.3 Uploading contacts to match friends must say how the server will keep them
• Adjacent: H4.02 Purpose Explanation · O1.02 Data Minimization · H4.08 Camera and Microphone Permission
• Search terms: photo picker · limited library · full-access justification