This also happened on iOS when they began to prompt users before apps could access the clipboard. I built an app that would handle the inbound redirect automatically if you had a relevant URL in your clipboard - did this for years with many users happy with the feature.

Then it started prompting users before allowing them to paste, and then the claims of privacy violations began to come in.

If instead I were able to specify what was happening in the prompt rather than iOS giving users an ambiguous statement, or even provide a detection pattern, it wouldn't have been nearly as bad.

I feel like this really harms security and privacy awareness by flooding the field with unimportant prompts/warnings to the degree that a real issue is similarly ignored because it is assumed to just be noise.

From the perspective of the simple dialog, its a problem with the consumer app who calls the api to open the dialogue without context, without informing the user or obtaining user consent prior to doing so. Plenty of apps get this right, eg. Have a screen with buttons in the on-boarding flow that opens the dialogue next to the “maybe later” option, and use that page to explain or “sell” the benefits of enabling the permission.

Maybe the dialogs api should be treated like autoplaying videos with sound on the web, just disable the api if it is called outside of a click event handler, and let the consumer app break. That would be a breaking change for OSs tho. It wouldn’t prevent malicious UI patterns from triggering annoying permission prompts, but it would minimize accidental bad ux eg calling it in the main method on load

Well, usually the answer is no, and then when something breaks the app will tell me.

Which reminds me. Why does the CVS app need access to Bluetooth?