12 Replies
      Latest reply on Oct 10, 2019 7:59 AM by houdah
      Bill Standen Level 1 Level 1 (0 points)

        Let me open by saying that I'm all in on what Apple are trying to do with the permissions here, great change.


        However, if you're going to have the average user going to System Preferences > Security & Privacy > Privacy as much as this change will have them doing so it really needs a streamlined UI.


        Has any thought been given to inlineing the requested permissions in place of the current dialogue box directing the user to System Preferences?  Something to cut down on the number of clicks?

        • Re: Privacy controls need a better enable UI than going to System Preferences
          KMT Level 9 Level 9 (15,405 points)

               > 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.

          • Re: Privacy controls need a better enable UI than going to System Preferences
            houdah Level 1 Level 1 (0 points)

            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.

            • Re: Privacy controls need a better enable UI than going to System Preferences
              houdah Level 1 Level 1 (0 points)

              Please consider filing duplicated of Radar #43036095

              Apple really can and should do better.


              "Request: Standardized per-app privacy control UI"



              - 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.