Comment 18 for bug 1404188

The connectivity-api option was discussed in comment #6 and unlikely to solve the issue in a way to make developers like the bug filer happy. Other proper/robust solutions would include writing a proxy service to filter sensitive data out, or adding "a single nm api call that doesn't make the app traverse all of the nm api". Those however do not have a plan or an implementer at the moment.

For the apparmor policy relaxing option, Jamie opposes a policy that would expose MAC addresses, SSIDs etc to all apps. But there's possibility to try to experiment with the rules, by:

< jdstrand> this easiest thing to do is this: create an app with the networking policy group that does what people what it to do. install it. then modify the generated apparmor profile in /var/lib/apparmor/profiles for the app to remove the explicit deny rules for nm (because they silence the denials). then do sudo apparmor_parser -r /var/lib/apparmor/profiles/<profile>
< jdstrand> then tail -f /var/log/syslog in one terminal, then launch the app to use whatever api people are trying to use. in the syslog there will be an apparmor denial. add a rule to allow the access to the profile, then reload the profile
< jdstrand> then repeat until you have a full list of rules. important-- the rules should be very specific (ie, interface, path and method are specified) so it is clear everything that is being exposed
< jdstrand> people may want to do 'sudo sysctl -w kernel.printk_ratelimit=0' to suppress rate limiting