Back in March, I wrote an article called “Does unified endpoint management need user environment management?”
My basic thesis is that while there are a few hundred MDM APIs in iOS and Android, there are many more configuration and management options that are only available in the user interface of the Settings apps. (Several hundred settings? Thousands? I haven’t counted, but it’s a lot.)
These settings can’t be managed remotely with MDM. At best, some of these settings get stored in a device backup. In iOS, these backups and the settings they contain can be applied to other devices with Apple Configurator or GroundControl, both of which require a USB connection to the device. At worst, you have to have someone manually configure these settings on the device.
You can imagine all sorts of business use cases for these non-MDM settings; the example that I gave was setting up custom dictionaries.
The thought I had in March was what if the Settings apps exposed all configurable items via the app configuration interfaces available in iOS and Android MDM. This way, there would be no need to wait for the OS to add a dedicated MDM profile or API for the feature you need to control.
This idea has gotten a lot of good feedback, but since then, I thought of another approach.
Starting with macOS 10.14 Mojave, macOS supported an MDM payload called Privacy Preferences Policy Control. This is used to configure which applications can access sensitive data that’s protected by privacy permissions. That is, instead of having a popup when an app asks to access a privacy-sensitive resource, access will have been pre-configured via MDM. This got a lot of attention last year.
So, what if Apple brought this concept to iOS? There are all sorts of privacy permission-protected resources that an enterprise iOS app might need access to, such as Bluetooth, the camera, the microphone, and location services.
When an app requests permission, the user has to grant access in a pop-up dialog. We’ve all done this a million times on our personal devices, but think of the ramifications on an enterprise device. Apple continues to refine its approach to privacy, but the expectations and requirements can be different here.
If an app needs access to one of these permissions as part of its business logic, what happens if the user doesn’t grant it? Think use scenarios like mobile point of sale, kiosks, shared devices, or other non-personalized use case. If a necessary permission is denied, the app is essentially broken.
The user could go into the Settings app to fix it, but that requires a certain amount of time and knowledge or training. And if the device is locked into single app mode, it might not even be possible. Instead, the user will put down the device and go find another one that’s working.
To avoid this, Privacy Preferences Policy Control payloads (also referred to as TCC profiles) could be used to set configure permissions automatically over the air via MDM.
There are some caveats that I can see. On macOS, for the camera and microphone permissions, Privacy Preferences Policy Control payloads can only be used to deny access, not to proactively grant it. My assumption is that this is because these payloads can be installed on personally enabled and BYOD Macs, and these permissions are just so sensitive that you want the user to be warned. But on a corporate iOS device that’s supervised, maybe this is okay, depending on the situation. If the device’s camera is being used to scan barcodes in a store, or it’s connecting to a Bluetooth credit card reader, it’s expected that these frameworks are in use.
Overall, what do you think? Is this a problem that you’re facing?
I mentioned this idea to a few folks last week at the Jamf Nation User Conference, and they liked it. I’m posting this article today to get the idea out there and get people talking about it. (I also just like getting ahead of these forward-looking MDM issues. See my articles on iOS 13 User Enrollment.)
Is there a better way to do this? Maybe MDM-managed apps on supervised iOS devices should just get all permissions automatically? Or maybe my earlier idea of app config for the Settings app is a better approach? (It would certainly have broader uses.) Do you foresee privacy concerns in your environment?
Share your thoughts, and we’ll see what happens in iOS 14.