Comment by skissane
14 hours ago
The big problem with these permission dialogs, is their lack of technical detail about what the app is actually trying to do which triggers them.
How do I know whether to say "Allow" or "Disallow" when it gives me no idea what either option actually means in concrete?
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.
Chrome extensions do the same thing, but worse (the warnings make it sound like the creator of the extension is going to see every page you visit, when really it's code that runs in the browser; it doesn't take html or any other data anywhere)
But it could… it’s arbitrary code execution and should be scary.
> If instead I were able to specify what was happening in the prompt rather than iOS giving users an ambiguous statement
No. They’re correct, there.
The app developer should not get to provide the message text for a prompt like that.
A secondary note somewhere in less than ten words, maybe, where it explicitly warns that the statement may be false.
> The app developer should not get to provide the message text for a prompt like that.
In App Store apps, where these messages get human review, it could more safely be allowed.
3 replies →
BlackBerry supported incredibly fine grained permissions way back in the day, and even that wasn't sophisticated enough to support OP's use case.
I don't really even care what OP's good intentions are, because the minute the app is sold, those good intentions are out the window. I use very few apps because I assume they are always going to potentially be adversarial to my interests.
The system warning is correct and should not be subject to the developer promising free candy to gullible users.
1 reply →
[flagged]
I think the visibility of these dialogs serves as a warning to the user--but they should do a better job directing the user's attention to where the threat is. If the user is getting annoyed at all these pop-ups, he should direct this annoyance at the developer who is (in all likelihood) asking for access to more of the user's computer than he needs.
The fact that there are so many popups should mean apps are reaching for access to your system way beyond what they should be. It shouldn't mean Apple needs to get rid of the pop-ups.
I get the pop-up semi-frequently from Chrome. I don't think complaining to Google has ever helped with anything; but then it's not like complaining to Apple has a better track record.
Yes, I don't know why the OS isn't tracking the pop-up by bundle id or anything. It's not like I changed my mind the last dozen times…
1 reply →
Regardless, apple should definitely not send popups unless an app is being engaged with.
I love the clipboard warning.
before that, facebook was stealing everything on your clipboard and send back to their server.
This dialog is what it take to stop them.
and it have the pattern detect you asked.
as a user with an itchy delete app finger, this is exactly why i like apple.
Counterpoint: do not read my clipboard without any action on my side, dude!
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?
> when something breaks the app will tell me.
Then you have to require these permission controls to tell the app the user denied permission, and not just giving a valid but empty result. Some people on HN feel strongly that when you deny contacts permission to an app, the app should receive a list of dummy contacts. Without it a bad app can lock its UI and not do anything unless the permission is granted.
Oh! There's actually good reason!
If you have an Extracare card, in some markets, you can self-unlock the locked display cabinets with the CVS app (because they have your identity via the ExtraCare card which adds inherent trust).
It's powered by the Invue smartlock platform. https://invue.com/smart-locks
https://abc7ny.com/post/cvs-testing-new-nyc-shoppers-open-ca...
Very interesting. But I'd imagine they aren't doing proper KYC to get an ExtraCare card, I bet it is very soft KYC. Like phone number verification or card payment which you can get anonymously, so it won't necessarily do too much to find the perpetrator. I wonder if it works through throttling and blacklisting so the loss and damage radius are reduced.
1 reply →
Ah, are you telling us that while people were outraged about rampant theft and pointing to all the locked-up merchandise as emblematic of the corporate response to rampant theft, even while there wasn't enough staff to unlock the cabinets... but the lockups are also a way to entice customers to install the app, sign up for an account, and enable Bluetooth all the time?
https://youtu.be/zS9U3Gc832Y?si=BmVOHE6ahKLbw82c
3 replies →