Unfortunately because of the incentives that drive developer business, we have to treat apps with minimal trust for anything potentially sensitive. Clipboards often contain people's names, contact info, passwords, and personal writing. Carte blanche access is something that reveals these and personally I'm not comfortable with it.
There's obviously a balance to be struck with:
a) not introducing unnecessary permissions prompts, causing prompt fatigue in users (thus lowering security)
b) improved UX by saving a step for apps that may use clipboards for legitimate purposes (e.g. shipment tracking numbers, photos, emails, etc)
Here's how I'd solve the problem through improved App Store review:
1. Carte blanche access to pasteboard is removed, replaced with system data detectors, which delineate common data types like shipment tracking numbers, photos, emails/contacts, plaintext, etc.
2. During app submission, any request to access a specific pasteboard data type has to be met with a UX justification, specifically that it has to significantly improve the core user experience in a meaningful way, and developers must promise to not scrape or store the data remotely.
3. If justification is not approved, app may still be published. Routines that call for access to data detector pasteboard must be able to gracefully fall back to non-pasteboard access (since they are used solely for simplifying a UX step).
4. If it is discovered a developer breaks their promise, their app may be pulled from the app store.
(optional) 5. When users get to the particular part of the app that uses pasteboard data AND the current pasteboard data is of the data type that the app has been approved to use, user is presented with a permission prompt to allow it. The permission prompt should not just be boilerplate, it should show the current contents of the pasteboard the app is trying to access.
The last step is a judgment call based on balance of permission prompt fatigue and user trust. If its believed the app store submission process is believed to be a good enough filtering process, then don't present prompts. One way to approach is add the above 4 and see how developers respond, and if it seems insufficient then add #5 in the next iOS release.
There's obviously a balance to be struck with:
a) not introducing unnecessary permissions prompts, causing prompt fatigue in users (thus lowering security)
b) improved UX by saving a step for apps that may use clipboards for legitimate purposes (e.g. shipment tracking numbers, photos, emails, etc)
Here's how I'd solve the problem through improved App Store review:
1. Carte blanche access to pasteboard is removed, replaced with system data detectors, which delineate common data types like shipment tracking numbers, photos, emails/contacts, plaintext, etc.
2. During app submission, any request to access a specific pasteboard data type has to be met with a UX justification, specifically that it has to significantly improve the core user experience in a meaningful way, and developers must promise to not scrape or store the data remotely.
3. If justification is not approved, app may still be published. Routines that call for access to data detector pasteboard must be able to gracefully fall back to non-pasteboard access (since they are used solely for simplifying a UX step).
4. If it is discovered a developer breaks their promise, their app may be pulled from the app store.
(optional) 5. When users get to the particular part of the app that uses pasteboard data AND the current pasteboard data is of the data type that the app has been approved to use, user is presented with a permission prompt to allow it. The permission prompt should not just be boilerplate, it should show the current contents of the pasteboard the app is trying to access.
The last step is a judgment call based on balance of permission prompt fatigue and user trust. If its believed the app store submission process is believed to be a good enough filtering process, then don't present prompts. One way to approach is add the above 4 and see how developers respond, and if it seems insufficient then add #5 in the next iOS release.