I want my tech-averse relatives to bail out of an app when they see that unless they're hand-held through it and the reasoning is made sufficiently apparent that they can parse it. If they can't, it's not clear enough, and they (and the OS) should default to no.
There has to be a common sense compromise on this, like a revokable certificate for access without a prompt.
I completely reject your whole premise.
No, you're not. And that's good. It's a bad pattern! It's a bad pattern whether one app or a million use it.
> There has to be a common sense compromise on this, like a revokable certificate for access without a prompt.
You seem to think this is the extreme position, and it's not. The extreme position is "you cannot access the pasteboard directly, at all, under any circumstances, and only user-triggered actions through OS-served and unintermediated controls can do so."
You have your compromise already: "ask for permission and be sufficiently clear about why you want it to get people to say yes".
> I completely reject your whole premise.
That's fine. Apple doesn't. That's why I like them. You started this thread with what sounded like a reasonable objection, but you've kept digging to the point where it sounds like you're kind of the reason they're doing it.
It doesn't seem like they do believe that, and even if they did, that's not the point.
The point is that allowing this access without explicit user consent enables various "scummy things" that neither Apple nor the user can then stop or easily detect.
It's really not that different from the person at the bank saying, "But you know it's me! Why can't you give me all my money without seeing my ID??!"
As a developer, I sympathize with you, but as a user, you can get bent. I appreciate that Apple makes it difficult for you to use potentially dangerous APIs with large risk surfaces, and forces you to ask me for permission to take that risk. It's why I continue to buy Apple products and will never switch to Android as long as it's owned by a user-hostile advertising company.
That's not to mention that my concern is fundamentally addressed by gating clipboard access behind a prompt in the first place. That is, I always have the option to decline the permission entirely.
It's a layered set of problems, and the answer is high walls.
The purpose of which is navigating to a particular part of the app on its first ever launch.
If universal links worked on the first install none of this theoretical discussion would be necessary.
If you can put arbitrary data on the clipboard from your website, and then read it in your app, without my interaction, that allows for a variety of potential exploits.
If we’re taking hundreds of thousands of clients and it works 99% of the time, then the risk of it not working in that 1% of cases is acceptable to our product team. Worst cast scenario is that it fails, the user tries again, and no clipboard is needed on the second attempt because universal links work now that app is installed.
This value in the clipboard might be something like: /path-to-experience?id=something
No, I understood that this was your intention. I'm trying to explain that even if you have the best of intentions, there is a risk you introduce a bug where your website _doesn't_ put something on the clipboard, so then when your app tries to read it, it instead reads whatever unrelated data is on the top of the user's clipboard. And if your app tries to append this value to a URL, then you are effectively sending clipboard data to your server, i.e. risking worst case scenarios like user passwords showing up in your server logs.