Hacker News Reader

Comment by rbanffy | Hacker News Reader

An application could access the protected APIs it needs during a first run in order to force the authorization dialogs. If I were designing an API for that, I'd allow a single call to declare as many permissions as needed, so all authorization dialogs would be triggered at once.

View on HN

But then you just have a model where an app asks for a dozen permissions upfront, which may not even make sense in context. For example, should your bank's app (assuming it had one) get camera access? On the surface this seems a bit strange, until you realize that it has check scanning functionality.

You could pop up a box that says "Bank of America is asking for access to the following parts of your Mac:"

Followed by a table with the function (I.e Camera, mic), a description from the developer about why, and a checkbox to accept or deny.

You are more likely to understand the reason an app wants a permission if it is requested the moment it tries to use it.

The behavior you describe is the old Android take it or leave it approach. It doesn’t work because then all apps refuse to work if they don’t get ridiculous permissions.

iOS has permission explanations. I imagine this should probably carry over to macOS.

It does. The issue is that even with a permission explanation, it can be hard to see what the reason for a certain permission is if it’s asked out of context.

On iOS users have selectable permissions control; I could allow an app to access my location but not the camera or microphone, and the apps are expected to even work with no permissions granted.

That all depends on context, if an app asks for all the permissions on first run, the user doesn't have any context to help him/her deny access.

Reply on news.ycombinator.com