This is a brief analysis on the upcoming Android Enterprise Features in Android Q. Read the full notes here. Google has a habit of silently updating those documents, so I expect to update this post once subsequent iterations of Beta are released. The below is my sole opinion, and I welcome hearing yours. NB: it starts slow, the really great stuff is towards the 2nd half 🙂
Work profile provisioning for company-owned devices
This is probably useful where COPE will not fly due to compliance/privacy rules/regulations, and makes the whole ecosystem more uniform. But aside from that I see no point.
Work-profile device-ID attestation
… admin of a work profile provisioned using zero-touch enrollment can now get secure-hardware-attested device IDs, such as an IMEI or manufacturer’s serial number. The device must include secure hardware (such as a trusted execution environment (TEE) or Secure Element (SE)) and support device-ID attestation and zero-touch enrollment.
This it useful! It allows to further protect Zero-Touch from certain spoofing attacks (which are inevitable since ZT must be more open that DEP), but imposes some restrictions. Guessing it will be part of AER certification.
Access to work profile calendars
Apps running in the personal profile can show events from the work profile calendar.
IT admins can block the work profile from sharing calendar information with the personal profile.
This is cool! Many customers enjoy the separation between personal and business data, but absolutely do not enjoy the fact that now they have two independent calendars and may accidentally schedule overlapping appointments. I really want to see an option “Show availability only” (like Outlook/Exchange since ages). Alas for now this one string is all we get in terms of behaviour description.
If we don’t get the availability-only, the effect of this feature will be much less, as quite a few will simply block it due to potential leaks and privacy concerns.
Work profile, device-wide unknown sources
In Android Q, admins of work profiles can now prevent any user or profile from installing apps from unknown sources anywhere on the device…
After adding this restriction, however, a person using the device can still install apps using adb.
We kind of had that before, but it involved fiddling with custom Google Play settings (or COPE mode). Good to see it natively implemented device-wide.
Limit permitted input devices to work profiles
… users are only restricted to the permitted input methods inside their work profile instead of the entire device, giving users full control over input methods on the personal side of their device.
IME (input method / virtual keyboard) whitelisting is known for a while and used by security conscious organizations to prevent untrusted 3rd party IMEs from hoovering all that comes through them (including passwords, which is why SSO+ZeroTrust is your best friend) and sending it in the unknown direction.
Problem is, it was global, which in turn annoyed lots of users using non-standard (i.e. not GBoard) keyboards. Unless you used Samsung KNOX, which in turn confused some admins 🙂
Now the admins can enforce IMEs inside the profile, while allowing to user decide themselves if their new kitty-sticker-board-tm is worth trust. And this is now a platform standard feature, ensuring uniform behaviour across devices and vendors. Good stuff!
Manual system update installation
In Android Q, admins of fully managed devices can install system updates via a system update file. Manual system updates allow IT admins to do the following:
* Test an update on a small number of devices before installing them widely.
* Avoid duplicate downloads on bandwidth-limited networks.
* Stagger installations, or update devices only when they’re not being used
No more comments. It seems pretty convoluted at the first sight, but given the variety of the use cases supported it may be OK. Hopefully by the time it gets to us the EMM vendors will make it as easy as pushing another profile/app to smart groups.
Note though, that the 30/90-day postpone/freeze windows are still in effect, as it seems. Let’s see how that pans out.
EAP Wi-Fi provisioning
In Android Q, QR codes and NFC data used for device provisioning can now contain EAP config and credentials—including certificates.
Including Certificates! Wow! OK, this takes a page out of Zebra StageNow/MX book and will be welcome by many customers. However….
Zebra StageNow used to encrypt the credentials with a key, which could be further customized. So far I had not seen anything in Android QR or NFC formats that supported encryption. I.e. as soon as that Barcode/tag leaks – your WLAN is screwed. The good news is that it is less screwed than a PSK-based WLAN, since you just invalidate the account/cert, but anyway…
I guess the only safe solution would be using staging apps, such as AirWatch Relay. This can actually be quite cool: push the app as a managed one, so it has access to the managed enterprise certificate store on your device, choose that cert during staging, turn off the app – and your credentials are as secure as possible at all other times!
Barcodes/tags I would not recommend though (also, consider the size of your typical certificate and the memory capacity of typical NFC tags / number of QR codes needed).
Private DNS support
Organizations can use DNS over TLS (called Private DNS on Android devices) to avoid leaking DNS queries, including those of internal hostnames.
Private DNS was introduced in Android 9, but was not managed. This is a useful addition, as long as your enterprise actually implements DNS over TLS. Does it? Let me know in the comments, for my guess is that is doesn’t 🙂 May be interesting for VPN solutions, though, since DNS often leaks in these scenarios.
VPN lockdown mode exemption
VPN lockdown mode allows a DPC to block any network traffic that doesn’t use the VPN. Admins of fully managed devices and work profiles can now exempt apps from lockdown mode. Exempted apps use a VPN by default, but automatically connect to other networks if the VPN isn’t available. Exempted apps that are also explicitly denied access the VPN will only use other networks.
I guess the description says it all. Are you using such functionality?
New delegation scopes
Android Q extends the list of functions that a DPC can delegate to other, more specialized apps
This may be quite useful for extending the features of VPN and MTD (Mobile Threat Defense) clients. And we may possibly see a fully-working Android Wi-Fi sniffer/troubleshooting tool! I vouch for the latter one, as I can’t tell you how many WLANs I had seen where coverage was designed and (maybe) validated for Laptops only, and phones with their weak antennas get -10dB (10 times less) signal.
Network activity logging, Certificate selection, Package installation
To help organizations detect and track malware, DPCs can log TCP connections and DNS lookups by the system. In Android Q, admins of fully managed devices can delegate network logging to a specialized app.
In Android Q, admins of fully managed devices, work profiles, and secondary users can delegate certificate selection to a specialized app.
Sometimes it’s useful to install a locally cached custom app onto a device. Admins of fully managed devices can now delegate package installation (and uninstallation) to another app. Package installation delegates can install app packages without user interaction.
…just as expected
Deprecation of device admin policies
Android Q prevents DPCs from applying legacy device admin policies
I will not post the Hallelujah video again, but if you had a good clip to the tune of “You have been warned a thousand times, migrate to Android Enterprise” – please leave a link in comments.
New features for apps
Starting in Android Q, apps with critical features that require a screen lock can query a device or work profile’s screen lock complexity. Apps needing a stronger screen lock can direct the user to the system screen lock settings, allowing them to update their security settings.
In Android Q, VPN apps can set an HTTP proxy for their VPN connection.
VPN apps can now discover if the service is running because of always-on Vpn and if lockdown mode is active. … For example, you might disable your disconnect button when always-on VPN controls the lifecycle of your service.
Devices now filter the list of certificates a user can choose from based on the issuers and key algorithms specified in the call.
So a bunch of small but useful tweaks to make security more comprehensible by the user – always welcome. I’ll put the last one separately as this was a considerable blocker for many COSU customers
KeyChainno longer requires a device to have a screen lock before keys or CA certificates can be imported.
Yes! Previously, if you wanted your internal Root CA on a rugged device (already locked down with Launcher or in a single-app mode) you still had to endure that second lock screen. And if your rugged vendor decided to implement it for you they risked losing Google CTS compliance. How’s that? Now your dreams come true. 🙂
So, nothing super-revolutionary like the COPE mode, but a whole bunch of useful improvements streamlining the management and security operations that every enterprise depends on. IMHO Android was reasonably mature since 8.1 (9.0 for Rugged customers due to TONS of enhancements there) and what we are seeing now is a welcome evolution.
Do you agree? Disagree? Did I misjudge some of the improvements? Do you have any favourites? Leave a note!
P.S. What do you think the name for Q will be? I vote for Qucumber!