> If you've ever tried to use 802.1x / EAP on Android then you've already had a taste of this issue. Android makes importing and trusting a new root certificate authority very difficult.
Good lord don't get me started. In worked at a NOC in college part-time and a significant part of my job was helping users onboard devices to the network and determining where there were gaps in our onboarding process. After a random security update, all Pixel phones just ... stopped being able to connect to our network and we eventually determined that you needed to go through a new, non-obvious path to import a CA for our EAP-TLS certificates. I'm not remembering the details but unless you connected _exactly_ right on the first try, it would delete the CA certificate and you'd have to start over. There's a lot of other details here but it ended up taking us almost a month to find the exact path to get things up and running.
We also paid a vendor (SecureW2) for an app to enroll devices on the network, but Google removed the ability for users to edit configurations generated by apps. Our network required disabling MAC randomization at the time (which Google provides no API for apps to disable). Before the change, users would enroll, and then disable MAC randomization to complete setup. However, because users were no longer allowed to edit these configurations after the app had gotten everything else configured, they were left dead in the water.
On the flip-side: Apple makes this very easy and provides a "profile" mechanism that users can download and get everything set up in a few clicks.
> Our network required disabling MAC randomization at the time (which Google provides no API for apps to disable). Before the change, users would enroll, and then disable MAC randomization to complete setup.
Yeah, that one I kinda agree with. I don't want most apps to be able to disable that. It's one of the first lines of defense in protecting a device's privacy, and I doubt most people would understand the potential impact if any app could even ask to disable it. That one can be left in the main settings.
Yeah, I totally understand why Google did that (though, it's a WiFi provisioning app... it's literally an app that connects you to a previously untrusted WiFi network. I get you gotta draw the line somewhere but that's debatably just as much of a privacy risk). That said, if you decide that it's not allowed to be changed by an app, you gotta let the user be able to make the change...
Good lord don't get me started. In worked at a NOC in college part-time and a significant part of my job was helping users onboard devices to the network and determining where there were gaps in our onboarding process. After a random security update, all Pixel phones just ... stopped being able to connect to our network and we eventually determined that you needed to go through a new, non-obvious path to import a CA for our EAP-TLS certificates. I'm not remembering the details but unless you connected _exactly_ right on the first try, it would delete the CA certificate and you'd have to start over. There's a lot of other details here but it ended up taking us almost a month to find the exact path to get things up and running.
We also paid a vendor (SecureW2) for an app to enroll devices on the network, but Google removed the ability for users to edit configurations generated by apps. Our network required disabling MAC randomization at the time (which Google provides no API for apps to disable). Before the change, users would enroll, and then disable MAC randomization to complete setup. However, because users were no longer allowed to edit these configurations after the app had gotten everything else configured, they were left dead in the water.
On the flip-side: Apple makes this very easy and provides a "profile" mechanism that users can download and get everything set up in a few clicks.