Privacy controls need a better enable UI than going to System Preferences

> it really needs a streamlined UI.

While we wait for the feedback app, feel free to use the 'Report Bugs' link, below right, adding your report # to your thread for reference, thanks and good luck.

From a developer perspective, it bothers me that there already were several types of API to request or check for permissions. For the address book, one has to try to access and "risk" a UI being shown to ask permission. This meant that the call could block and be made at a time where it did not startle the user. There is no way to check if permission has previously been requested, granted, or denied.

For other data, like calendar, there is API to check permission status. This makes it much easier to adapt application behavior to user preferences. This appears to be the more modern approach. It seems address book only took the other approach to retain API compatibility. Though I would appreciate to see additional API to check on permission status.

In Mojave, Apple adds new categories of protected data. This is fine. What bothers me is that we again get a bucnh of different behavior and API styles. For Photos and certain file access we get the behavior seen in address book. Not the best. For Mail we get a silent failure. The silent failure may actually be an improvement. It allows for partial checking of the authorization status. If listing the contents of ~/Library/Mail fails, the user either has not yet been asked or has refused access. The catch here being that there is no API to ask for permission to access.

The new process to grant access to app data is unduly complicated on both the developer and the end user:

- The developer has no way to distinguish between situations where the user has not made a decision yet and situations where the user has refused access

- There is no API to request permission

- The user needs to be directed to System Preferences

- In System Preferences, the user needs to pick the correct pane to grant permission. She has to do se without the benefit of a permissions string (or privacy statement) that explains why the application needs access

- The user needs to manually add the application to the list. This is in stark contrast to Accessibility preferences, where the apps are already listed and th user only needs to add a checkmark

- The "+ / Add" button opens a NSOpenPanel rooted in the Documents folder - the most unlikely place to find applications. At the very least, this should point to the Applications folder. Better yet, select the last used application

I will submit bug reports / feature requests to suggest the following:

- There should be an API that pops up an alert to ask for permission to access application data. This should show a description string from Info.plist. Much like access to Calendar does.

- The System Preferences pane should list all application, or running applications, or applications that have recently tried to access protected application data.

- There should be API to check if the user has granted or refused permission. E.g. if the user added an application to the list in System Preferences and unchecked it, that could be understood as explicit refusal.

Looks like this has been greatly improved in Beta 2 which is nice to see.

What has changed? I didn't notice any improvement in beta 2 or beta 3.

Actually, it got worse instead of better in Beta 4, for background helper tools. Although cumbersome (⌘⇧G, /Applications/My.app/Contents/Helpers), in Beta 3, users could add my app's enclosed Helper tool to the Application Data whitelist, and it worked. Starting in Beta 4, users can still do this, but it has no effect – the helper is subsequently denied access by sandboxd.

Of course, in my Bug Report (42602218), I urge Apple to enable all enclosed executables when a .app package is entered into the Application Data whitelist.

Please consider filing duplicated of Radar #43036095

Apple really can and should do better.

"Request: Standardized per-app privacy control UI"

TL;DR;

- Organize privacy controls by application

- Always show Info.plist reason strings

- Make privacy controls available from within each application

- Thus allow for workflows where the user can effortlessly upgrade or downgrade data and service access

Currently privacy controls (e.g. access to location, calendar, …) are available in System Preferences and are structured by type. When a user decides to trust an application and authorize or pre-authorize an application, she has to browse through all types and add the application to the list.

For the user it would be more natural to have privacy controls structured by application. Then she can decide to trust (or not) an application and decide to which information to extend that trust.

Ideally these privacy controls should be available right from within the application. E.g. as standard menu item in the Application menu. A standard item in a standard location. Like the Quit menu item.

This would open a UI that lists all privacy sensitive data and service the application has voiced interest in by way of Info.plist. This UI would also show the reason strings provided in Info.plist. This information is currently missing from System Preferences.

The user can then toggle application access to all privacy sensitive areas in a single place. She can find that place from the Application menu. She can trust that UI since (like NSOpenPanel) it is provided by the OS in a tamperproof way.

Such streamlined UI also allows the user to start cautiously and allow more data access as trust has been built. On first launch, an application may explain what features may be limited by restricted data access and then invoke the privacy UI for the user to make an initial choice. That choice may be restrictive. Later after trust has been established and the user has established the usefulness of the application, she can decide to allow the application access to more information. For that she only needs to turn to the Application menu and make adjustments.

The same works the other way around. The application may request access to a system service for a specific task and the user may decide to grant that access to complete the task. She may not want to give the application indefinite access. A quick trip to the privacy controls in the Application menu can revoke access starting with the next application launch.

Apple has "closed" my Bug Report 42602218, which is really frustrating because, as usual, there is no indication of whether it's been (a) accepted and expected to be fixed before the GM, or (b) it's a won't fix, or (c) they don't think it's even worth any serious consideration. Because Beta 6 still behaves the same as Beta 4, I fear one of the latter 😟.

Houdah, what do you mean by file a duplicate? Do you think it helps to just file a one-liner which simply states your bug number with the words me too! Or is it necessary to rewrite the whole thing.

This is going to be fun to support :-( I guess a simple me-too will be enough to serve as upvote.

Anyone who wants to file may start with or plagiarize mine:

Applications which require Full Disk Access in macOS 10.14 Mojave must instruct their users to navigate into System Preferences > Security & Privacy > Full Disk Access and add the application to the whitelist. This procedure is complicated and will frustrate new users of such an app.

There should be a API for this – an asynchronous function which, when called by an app, would present the user with a dialog requesting Full Disk Access and, if the user clicks OK, automatically enter the calling app into the Full Disk Access whitelist. This function should pass the user's YES or NO to its completion handler. There should be another function which would indicate an app's Full Disk Access status.

It appears that Apple has added API to check for AppleEvent authorization: https://mjtsai.com/blog/2018/08/31/aedeterminepermissiontoautomatetarget-added-but-aepocalyse-still-looms/

Let's request they add the same API for Full Disk Access.

I am currently traveling and can't access my Mojave machine to check if such API already exists. From the mjtsai.com post it appears that documentation is not keeping up with headers.

Agreed! +100! Apple has done a HORRIBLE job of supporting (or not supporting as the case may be) the new Privacy preferences such as Screen Recording. They didn't even put out any sample code that works reliably. And like you stated, there's no way to even detect that they previsouly denied access. Also, with Screen Recording, the function you call to create the checkbox is also the same function which puts up the permissions dialog, and it only does this the first time it's called. There's no way to detect whether it actually put up the dialog if you're calluig the function a second time. It seems that Apple is getting lazier and lazier in terms of supporting new versions of Mac OS.

I have built my own privacy controls UI for HoudahSpot 5.0.10. Check out HoudahSpot > Preferences > Privacy.

It has been a lot of work. Involves a lot of guesswork. It is convoluted code that tries to cover edge cases on various OS versions. Still, it is far from perfect and can't ever be perfect. The available API simply does not provide enough information to create a smooth experience.