Comment 1 for bug 1374570

I knew, when designing the "Location" settings, that I'd soon be designing settings for other app privileges too. I didn't put "Location" in its own screen merely because I designed it first, and it's not correct that "there really isn't any reason why Location shouldn't be grouped with the other trust-store-enabled services". There are two reasons. First, most people using the phone will not, and should not, have any idea that audio recording is a "service", nor any idea that the Ubuntu code includes something called a "trust store"; so that's not relevant to which organization is best. And second, there are three non-app-specific items in the "Location" settings design: the global "Location detection" switch, the "Send occasional location data" switch, and the "Privacy policy" item. Since those aren't about individual apps, they would seem weird inside a branch of System Settings that was labelled as if it *was* controlling individual apps, while separating them out would mean we'd awkwardly have two screens of location-related settings.

Now, it might still be best to group all the app privileges together ... just not for those reasons. What makes the word "should" a danger sign, in a bug report title, is that it both assumes the problem and assumes there is only one possible solution. Here, there's little empirical evidence for a problem, and there are at least three other ways these settings could be arranged.

(A) As you suggest, all inside "Security & Privacy", something like "Things apps have access to", then organized by service: a screen for each service, each with a toggle list of apps.

(B) All inside "Security & Privacy", something like "Things apps have access to", then organized by app: a screen for each app, each with a toggle list of services. (Benjamin Keyser has suggested this.)

(C) As many as possible inside related screens: for example, app access to location with the rest of the "Location" settings, app access to the microphone with the rest of the "Sound" settings, and app access to your call history with the rest of the "Phone" settings.

These aren't mutually exclusive. For example, we could do both (A) and (B) with a control to toggle between those views. Or we could take approach (C) for some services, and a different approach for others. It's fortunate we can mix and match, because some services are much more interesting than others. For example, notifications are a high-profile service where we provide external control over whether apps can use them. (I don't know whether notifications use the trust-store or not, but remember, that's not relevant.) It's harder to tell, in the first few minutes of using an app, whether it's a good idea to give it the ability to send notifications than whether it's a good idea to give it the ability to access your location. Therefore, people will change their mind about whether an app uses notifications much more often than about whether an app uses their microphone. That's why "Notifications" deserves to be at the top level of System Settings, while "Microphone" is much deeper.

As for the wording, it's true that "Other app access" is not a brilliant example of clarity. If I had room I would have called it "Other things that apps have access to", but as it is, it sounds like it's referring to some "other apps". If that's your real problem here, I'd be happy to narrow this bug report to just that issue and brainstorm some alternative phrases. Otherwise, please reopen if you have evidence that the current arrangement is causing findability or efficiency problems.