Arsen Bandurian: Technical Bloghttps://arsenb.wordpress.com
Sceptically passionate on Enterprise Mobility, AutoID, WLANs, OSes and other technical stuff I happen to work with
Thu, 04 Oct 2018 20:40:42 +0000 en
hourly
1 http://wordpress.com/https://s0.wp.com/i/buttonw-com.pngArsen Bandurian: Technical Bloghttps://arsenb.wordpress.com
Fighting the recent Apple DEP “vulnerability” with Workspace ONE UEM (AirWatch)https://arsenb.wordpress.com/2018/10/04/fighting-the-recent-apple-dep-vulnerability-with-workspace-one-uem-airwatch/
https://arsenb.wordpress.com/2018/10/04/fighting-the-recent-apple-dep-vulnerability-with-workspace-one-uem-airwatch/#respondThu, 04 Oct 2018 20:35:32 +0000http://arsenb.wordpress.com/?p=979There’s been recently a wave of news along the “OMG Apple DEP is insecure we are all doomed” line. While there is indeed a few flaws in Apple Device Enrollment Program, I want to show how to fight it with Workspace ONE UEM (AirWatch) in a simple 3-step process

Step 3: You are done. Really, this “vulnerability” is only serious in two cases:

Using no authentication, implicitly trusting anything that comes from the Internet over DEP

Staging (specifically using the staging process with the staging user) sensitive information – certificates, etc. Just don’t – have all the sensitive bits assigned to the end-user who has to authenticate.

]]>https://arsenb.wordpress.com/2018/10/04/fighting-the-recent-apple-dep-vulnerability-with-workspace-one-uem-airwatch/feed/0apcsbDEP-FUD-WS1-AuthSecuring work contacts while keeping caller ID 03: iOS with Boxerhttps://arsenb.wordpress.com/2018/07/25/securing-work-contacts-while-keeping-caller-id-02-ios-with-boxer/
https://arsenb.wordpress.com/2018/07/25/securing-work-contacts-while-keeping-caller-id-02-ios-with-boxer/#commentsWed, 25 Jul 2018 06:30:27 +0000http://arsenb.wordpress.com/?p=949I had a week of customer meetings, each (literally!) asking the same question: “How can I prevent WhatsApp from grabbing the corporate contacts on my device?”

In this series of posts we will explore the options of deploying corporate email/contacts/calendars with the goal of maximal work/personal contact separation, while trying to minimally impair the user experience (such as the Caller ID).

Recap

Deploy the Boxer app and explore the options that affect separation/integration

Install a 3rd party app which and see if we can leak the work contacts

Check that caller ID still works

Device: iPhone7, iOS 11.4

Separating work from private

In iOS world everything deployed via EMM is considered Managed, while everything installed by the user is Unmanaged. In order to ensure that no 3rd party app will be able to grab our contacts, we need to:

Deploy contacts as Managed This can be achieved in two ways.

Via EAS profile (into native contacts app). This requires iOS 11.3+ to work. We will explore it in a separate post.

Deploy Boxer email app as Managed and let Boxer deliver contacts, which will too count as Managed. This allows for greater degree of separation and that’s what we’ll do in this post.

Deploy a Restriction so that Unmanagedapps do not have access to Managed data. By default this separation is disabled.

Pushing Boxer via EMM will automatically make it managed. All we really need to do is to push the Restrictions profile with the following box unchecked:

Uncheck this box in iOS Restrictions profile to enable separation

Now that we all the preparations done, let’s push the app and test it.

Deploying the Boxer app

Deploying Boxer is the nearly the same for iOS and Android. It is a public app.

Since it is integrated with WorkSpaceONE UEM, the console conveniently shows extra options when you assign the app to devices. Provisioning email options here allows us to avoid creating the EAS profile, which in turn

ensures proper separation on older iOS devices (<11.3)

prevents work emails/calendars/contacts from popping up in stock Mail/Calendar/Contacts apps.

Note that I am using the variables here, which I have already pre-configured in my WorkSpaceONE UEM user account in VMware’s test Office 365 instance.

Opening More Email Settings allows us to configure the security settings and Caller ID forwarding. We are interested in the below options:

CallerID: Restricted. On modern versions of iOS (10.0+) Apple had introduced a technology called CallKit, which allows apps to provide Caller ID services. This switch relates to the old “export” method and as such we don’t need it. Or there is a bug in Boxer, where it allows CallerID even when restricted.

Personal Accounts: Restricted. When allowed, user can create additional accounts in their (Managed!) Boxer. Since this is clearly a way to a data leak, we’ll keep it disabled.

Personal Contacts: Restricted. Enabling it will result in Boxer displaying contacts from other sources in its own contact list. Full separation assumes that users private data won’t accidentally show up in work apps, so we should keep it off. Note that this also disables the Local Contacts slider in Boxer.

UEM Console settings and their counterparts in Boxer iOS app. Click for a larger image

That’s very much it, let’s push the app and see if our setup works.

Testing the separation and Caller ID

I have pushed Boxer, launched it and waited until the work contacts are synchronized. I have also installed two 3rd party apps that can access contacts: LinkedIn (“Invite Contacts” feature) and a 3rd party contacts backup app. Here’s what I see in every app.

This way we get a very clear, understandable and manageable Work/Private separation similar to Android Work Profile. However, the user now has to use essentially two separate contact apps. Here’s what we can do to address it:

Use Boxer as the main Contacts app:

Set Personal Contacts: Unrestricted (as discussed before).

Un-restricting Personal Contacts in the UEM Console enables the Local Contacts slider in Boxer

Use the native Contacts app as the main one:

Push a EAS profile. In addition, work emails/calendars will appear in the native apps, which may or may not be what you are looking for. Despite appearing all piles up and mixed with private Contacts/Emails/Calendars, they are still protected and separated (iOS 11.3+). As mentioned before – separate post.

The Exchange accounts is fully local to Boxer and not present in neither Accounts and Passwords, nor Device Management.If you want Work (Managed) contacts to appear in local Contacts app – deploy the EAS profile.

OK, let’s get the CallerID to work. According to Apple’s official security & privacy stance, user MUSTmanually enable CallerID for every CallKit enabled app (and take full responsibility for the consequences), so full automation is unfortunately impossible.

Boxer hints us that the setting is located in Settings –> Phone –> Call Blocking & Identification. Let’s turn it on and see what happens.

Enabling caller ID on iOS. Must be done manually. Thanks, Apple.

iOS even shows which app provided the Caller ID! Note that it doesn’t work in the notifications, however. I’m probably not holding my phone right…

Working Caller ID on iOS. Tap for a larger image.

Ok, we have it all working. Let’s summarize!

Summary

iOS offers secure enterprise Email and Contacts without having to compromise on convenience of the CallerID (provided you have a capable EMM and mail client). Notes:

+ CallKit allows an app to provide caller ID without ANY contacts integration, and even shows which apps provided it.

– Doesn’t work in notifications for some reason.

– Manual intervention required, user has more control than admin. Great for BYOD, not good for fully business-oriented devices.

– Since Apple doesn’t have a clear container boundary (like Android’s Work Profile) things can be confusing. For example, had we deployed EAS profile, all contacts would have been in the same app, but they would behave differently, confusing the user.

+ CallKit CallerID allows us to not expose the EAS profile to other managed apps, unless we want it.

Looks like the goal is achieved. What are your thoughts? Have I forgotten to test something.

]]>https://arsenb.wordpress.com/2018/07/25/securing-work-contacts-while-keeping-caller-id-02-ios-with-boxer/feed/1ContactsCallerID-20aapcsbContactsCallerID-02ContactsCallerID-06ContactsCallerID-08ContactsCallerID-09ContactsCallerID-15ContactsCallerID-17ContactsCallerID-16ContactsCallerID-18ContactsCallerID-20Securing work contacts while keeping caller ID 02: Androidhttps://arsenb.wordpress.com/2018/07/24/securing-work-contacts-while-keeping-caller-id-03-android/
https://arsenb.wordpress.com/2018/07/24/securing-work-contacts-while-keeping-caller-id-03-android/#commentsTue, 24 Jul 2018 06:30:13 +0000http://arsenb.wordpress.com/?p=919I had a week of customer meetings, each (literally!) asking the same question: “How can I prevent WhatsApp from grabbing the corporate contacts on my device?”

In this series of posts we will explore the options of deploying corporate email/contacts/calendars with the goal of maximal work/personal contact separation, while trying to minimally impair the user experience (such as the Caller ID).

Recap

Deploy the Boxer app and explore the options that affect separation/integration

Install a 3rd party app which and see if we can leak the work contacts

Check that caller ID still works

Device: Google Pixel 1, Android 8.1 Work Profile

Separating work from private

Android has separation and caller ID support enabled by default thanks to Android Enterprise (ex. Android for Work): everything we push via EMM will be installed into the Work Profile Thus we really don’t have to do anything, but let’s explore some options – Android has a lot to offer (more than iOS, if you ask me).

First, let’s take a look at the default Restrictions (which we don’t even have to push!). Note that the separation is enabled, caller ID is enabled, and take a look at the last box: Allow work contacts in personal contacts app.

Android Work Profile restrictions offer more options than OS and are good by default, we don’t even need to push them

The naming is a bit confusing, as proven by the numerous discussions on the Internet. I’ll write a separate short post about this feature. What we need to know now, is that regardless of this checkbox 3rd party apps (LinkedIn, WhatsApp etc) still cannot access Work contacts.

We are pushing Restrictions, but do not push the Exchange ActiveSync profile. Thus Boxer will have to create one on the with run. Which will fail, unless we allow adding/deleting accounts (disabled by default). Alternatively, you can push the EAS profile yourself – Boxer will use the preconfigured one just fine.

Make sure to enable this if you are not pushing the EAS profile separately

Finally, we will configure a Permissions payload in the same profile, to automatically grant Boxer all necessary permissions, so that it doesn’t have to ask the user. Compare the two screenshots below – in one case the permissions were set by the user, and in another – via EMM console. Note that you can push permissions in a way that user can’t even touch them!

In summary, Android just works out of box, but there are lots of tweaks available.

Now that we all the preparations done, let’s push the app and test it.

Deploying the Boxer app

Deploying Boxer is the nearly the same for iOS and Android. It is a public app.

Since it is integrated with WorkSpaceONE UEM, the console conveniently shows extra options when you assign the app to devices. Provisioning email options here allows us to avoid creating a separate EAS profile – Boxer will take care of it.

Note that I am using the variables here, which I have already pre-configured in my WorkSpaceONE UEM user account in VMware’s test Office 365 instance.

Opening More Email Settings allows us to configure the security settings and Caller ID forwarding. We are interested in the below options:

CallerID: Unrestricted. This basically exports contacts to the Work Contacts. Disabling it will disable keep the contacts solely within Boxer and caller ID will not function. It also disables the Export Contacts slider in Boxer (see the illustration below), which does the same thing.

Personal Accounts: Restricted. When allowed, user can create additional accounts in their (Work!) Boxer. Since this is clearly a way to a data leak, we’ll keep it disabled.

Personal Contacts: Restricted. Enabling it will result in Boxer displaying contacts from other sources in its own contact list. Full separation assumes that users private data won’t accidentally show up in work apps, so we should keep it off. Note that this also disables the EnableDevice Contacts slider in Boxer.

UEM Console settings and their counterparts in Boxer Android app. Click for a larger image

That’s very much it, let’s push the app and see if our setup works.

Testing: Android

After I had pushed Boxer, I am checking the contacts I am seeing and comparing to private/unmanaged space, where I have one test contact. One of the Boxer contacts has no phone number and is thus not displayed in phone’s Work Contacts. The last screen is a 3rd party Contacts app for comparison.

As you can see, Work apps cannot see the Private contacts, 3rd party apps cannot see Work contacts, but the stock Contacts (and Messages) app can search for Work contacts. This is where the two options we’ve discussed above come into play:

Summary

Android offers secure enterprise Email and Contacts without having to compromise on convenience of the CallerID (provided you have a capable EMM and mail client). Both separation and caller ID work out of box, but allow for lots of customization. Notes:

+ Works out of box on defaults, which make sense for the Enterprise.

+ Tons of fine-grained controls if you want to further tighten security or tweak your setup

+ Fully automated deployment without user intervention

+ Clear container boundary and clear separation between Work and Personal apps and data

– Some users may find having two address books or two copies of the same app a bit cumbersome, we have examined tweaks for that

– No cool features like per-app caller ID (which Apple CallKit allows) – contacts have to be exposed to the Contacts Provider.

+ The provider itself is containerized in the Work profile, so private apps can’t get anything anyway

+ You can manage the Contacts permission per-app if you don’t want other work apps to see those contacts

+ Works on Work Managed (Device Owner) devices as well

Either set up Work Profile (Android 8.1+)

Or manage Contacts permission per app

IMHO, a very good set of features. What are your thoughts?

]]>https://arsenb.wordpress.com/2018/07/24/securing-work-contacts-while-keeping-caller-id-03-android/feed/1ContactsCallerID-14apcsbContactsCallerID-03ContactsCallerID-04ContactsCallerID-05ContactsCallerID-07ContactsCallerID-08ContactsCallerID-10ContactsCallerID-11ContactsCallerID-12ContactsCallerID-13Securing work contacts while keeping caller ID 01: Android vs iOShttps://arsenb.wordpress.com/2018/07/23/android-vs-ios-securing-work-contacts-while-keeping-caller-id-01-intro/
https://arsenb.wordpress.com/2018/07/23/android-vs-ios-securing-work-contacts-while-keeping-caller-id-01-intro/#commentsMon, 23 Jul 2018 06:30:30 +0000http://arsenb.wordpress.com/?p=947I had a week of customer meetings, each (literally!) asking the same question: “How can I prevent WhatsApp from grabbing the corporate contacts on my device?” This happens more often than you think – the infamous GetContact collected over 3.5B contacts in just a few months, all of which were officially available for sale! With GDRP in effect, how much could this cost?

Of course, both iOS and Android offer means to securely lock down enterprise data on BYOD devices. But this comes at a price of usability, the most cited problem being the caller it. We know that in the modern day an unhappy and discomforted user is essentially a backdoor waiting to happen. How can we keep this balance between security and productivity?

In this series of posts we will explore the options of deploying corporate email/contacts/calendars with the goal of maximal work/personal contact separation, while trying to minimally impair the user experience (such as the Caller ID).

We will explore several approaches, their limitations and shortcomings for iOS and Android. This post lays the foundations and provides a TL:DR style summary/comparison of my current findings.

How can we have both secure contacts and caller ID?

Since the two OSes use different terminology, let’s set the terms now:

Private = personal = unmanaged = user space

Work = enterprise = managed = work space

As said before, if the goal is just to secure those managed contacts, we can always use a dedicated managed email app. This app will be containerized and totally inaccessible to user’s private space, including the address book. But, if the contacts are not in the address book, how will caller ID work?

The older solution was to export “limited” contacts to the device’s address book: names and numbers only, just for caller ID. But can we really call this protection?

Fortunately, recent generations of iOS and Android allow to achieve the goal, albeit in different ways. All we need is a combination of a capable EMM and capable email client.

I will use VMware WorkSpaceONE UEM (ex AirWatch) and VMware Boxer. Other EMM solutions and email clients might also work. These two, however, come from the same vendor and are developer in sync = less maintenance and more convenience due to direct integration in the UEM console.

Plan of action:

Ensure basic personal/work separation and containerization

Deploy the Boxer app and explore the options that affect separation/integration

Install a 3rd party app which and see if we can leak the work contacts

Check that caller ID still works

Summary/Comparison:

Both iOS and Android offer secure enterprise Email and Contacts without having to compromise on convenience of the CallerID (provided you have a capable EMM and mail client). Both achieve this goal, allowing full separation of work and private, while retaining the convenience of caller ID.

iOS pros, cons and notes:

+ CallKit allows an app to provide caller ID without ANY contacts integration, and even shows which apps provided it.

– Doesn’t work in notifications for some reason.

– Manual intervention required, user has more control than admin. Great for BYOD, not good for fully business-oriented devices.

– Since Apple doesn’t have a clear container boundary (like Android’s Work Profile) things can be confusing. For example, had we deployed EAS profile, all contacts would have been in the same app, but they would behave differently, confusing the user.

+ CallKit CallerID allows us to not expose the EAS profile to other managed apps, unless we want it.

Android pros, cons and notes:

+ Works out of box on defaults, which make sense for the Enterprise.

+ Tons of fine-grained controls if you want to further tighten security or tweak your setup

+ Fully automated deployment without user intervention

+ Clear container boundary and clear separation between Work and Personal apps and data

– Some users may find having two address books or two copies of the same app a bit cumbersome, we have examined tweaks for that

– No cool features like per-app caller ID (which Apple CallKit allows) – contacts have to be exposed to the Contacts Provider.

+ The provider itself is containerized in the Work profile, so private apps can’t get anything anyway

+ You can manage the Contacts permission per-app if you don’t want other work apps to see those contacts

+ Works on Work Managed (Device Owner) devices as well

Either set up Work Profile (Android 8.1+)

Or manage Contacts permission per app

IMHO, both suffice, but Android is more logical and offers more features.

The following posts will explain these conclusions in detail.

]]>https://arsenb.wordpress.com/2018/07/23/android-vs-ios-securing-work-contacts-while-keeping-caller-id-01-intro/feed/2ContactsCallerID-01apcsbWorkSpace ONE Intelligence Custom Reports available + Free Trial of other featureshttps://arsenb.wordpress.com/2018/07/20/workspace-one-intelligence-custom-reports-available-free-trial-of-other-features/
https://arsenb.wordpress.com/2018/07/20/workspace-one-intelligence-custom-reports-available-free-trial-of-other-features/#respondFri, 20 Jul 2018 10:27:07 +0000http://arsenb.wordpress.com/?p=913Legacy AirWatch reports are being deprecated, and replaced by the next-generation Workspace ONE Intelligence Reporting. The point of this quick post is to provide a bullet-style quick overview and resources for further reading.

TL:DR

they are cool, customizable, and free* (=included in all UEM v9.2.3+ license types , cloud and on-prem).

There are even cooler features (custom dashboards, automation), which are premium, but a free 30-day trial is available.

Quick overview:

Old reports offered little customization and were built into AirWatch console, making it harder to include data from other WS1 components, such as vIDM etc.

New reports utilize the ETL service (Extract, Transform, Load) to gather and combine together data from multiple WS1 components and enable full (almost) customization (canned pre-made reports are also available)

This allows for extended use cases:

Quickly identify issues that can negatively impact user experience and prioritize development efforts based on user impact

Discover the applications that are used the most and measure their impact to easily quantify ROI of app deployments

]]>https://arsenb.wordpress.com/2018/07/20/workspace-one-intelligence-custom-reports-available-free-trial-of-other-features/feed/0Workspace_ONE_Intelligence_Dashboard-e1503977084912apcsbWorkspace-ONE-Intelligence-4-e1531855643282Workspace-ONE-Intelligence-FreeTrialDoes Android P private DNS really contribute to privacy? Or to Enterprise control?https://arsenb.wordpress.com/2018/04/27/does-android-p-private-dns-really-contribute-to-privacy-or-to-enterprise-control/
https://arsenb.wordpress.com/2018/04/27/does-android-p-private-dns-really-contribute-to-privacy-or-to-enterprise-control/#respondFri, 27 Apr 2018 07:30:23 +0000http://arsenb.wordpress.com/?p=898Private DNS is a new feature in Android P, which allows you to globally override the DNS settings (received from your carrier, hotspot provider etc.). This means that the said carrier’s or provider’s DNS servers will not be able to log your browsing habits.

This looks like privacy, but isn’t necessarily so…

1. If you are without VPN – the hotspot provider or carrier will harvest the hostnames from DNS packets anyway.
2. If they really want to spoof DNS (censure, diverting ad traffic) – they will intercept and overwrite the DNS packets.
3. If your VPN client leaks DNS – same story.

In oder to make it fully private, your DNS queries must be encrypted, and the authenticity of your DNS server much be validated. Which means DNSSEC or DNS over TLS. The latter being also introduced in P.

However, not many DNS services support it. So people will end up putting 8.8.8.8 or 1.1.1.1 there to allow their browsing habits to be harvested by Google, CloudFlare etc.

I guess this is called “out of the frying pan into the fire” in English

I can also imagine the next step: unhappy free hotspot providers (NSTAAFL) beginning to block said popular DNS IPs, explicitly requiring you to submit your data for harvesting.

Yep, No such thing as a free Wi-Fi

Moral: use VPN.
#SecurityTheatre

Now, to where can actually be useful?

My guess – enterprise-managed devices.Forcing this setting to corporate DNS equipped with TLS, DNS filtering, site reputation service or another security/enforcement mechanism ensures that the devices are safe and sound, the forbidden sites are blocked, and ad-serving sites are resolved to 127.0.0.1 (one can only dream…)

Of course, provided user can’t change it. We’ll have to live and see if this setting ends up upon many new Android Enterprise features in P or not.

Nevertheless, for absolute privacy this should be combined with a corporate VPN.

What do you think?

]]>https://arsenb.wordpress.com/2018/04/27/does-android-p-private-dns-really-contribute-to-privacy-or-to-enterprise-control/feed/0Screenshot_20180422-175014.pngapcsbScreenshot_20180422-175014.pngNSTAALFiOS Trustjacking protection with EMMhttps://arsenb.wordpress.com/2018/04/25/ios-trustjacking-protection-with-emm/
https://arsenb.wordpress.com/2018/04/25/ios-trustjacking-protection-with-emm/#respondWed, 25 Apr 2018 07:39:50 +0000http://arsenb.wordpress.com/?p=908Trustjacking is a new “scary” attack on iOSnew “scary” attack on iOS devices, exploiting user’s lack of understanding or what’s going on. When plugging into an unknown computer or charger user may choose to “trust” it, which allows the remote device quite a degree of access to iPhone/iPad data. Many don’t realize that this trust remains after the device is disconnected and may be exploited, for instance, via Wi-Fi, if Wi-Fi sync is enabled. Many others also think that this trust is necessary for charging.
What is really should read: “Your settings and data will be accessible from this computer even after disconnected. You DON’T need this for charging”

Basically, Apple should have looked at how Android 6+ has a “charge only” USB mode by default, fixed the wording and be done with it.

Protecting from this attack is extremely simple on Supervised (DEP) devices via EMM.

Here’s how it’s done via AirWatch, but any other major EMM will have something similar – this is Apple’s standard OS feature.

iOS Trustjacking protection: it only takes one tick

As a bonus, this will prevent not just the Trustjacking attack, but many other threats and leaks, since it blocks everything.

Wondering, how many had this configured before the Trustjacking news?

]]>https://arsenb.wordpress.com/2018/04/25/ios-trustjacking-protection-with-emm/feed/0apcsbios20blog2021-e1524555570975.pngiOS Trustjacking AWChange of windhttps://arsenb.wordpress.com/2018/04/23/change-of-wind/
https://arsenb.wordpress.com/2018/04/23/change-of-wind/#respondMon, 23 Apr 2018 07:30:36 +0000http://arsenb.wordpress.com/?p=905Those of you who follow me on LinkedIn may have noticed that I have a new workplace, which comes with a Digital Workspace.

This means less wireless, but even more on Enterprise Mobility, EMMs, mobile security Android, iOS, Windows 10 and MacOS (did you know that both MS and Apple made their desktop OSes manageable by EMM ?)

If you are not following me in LinkedIn and Twitter, you are probably missing 90% of the stuff! So, please consider (or save yourself lots of noise and unsubscribe – fair enough )

Why VMware/AirWatch, why EMM?

This is going to be a long-ish and exalted neophyte read, purely optional.

Given the events in the last two years, I think that UEM solutions are ripe for conquering whatever remaining market is left there, and VMware is surely spearheading the charge with AirWatch (market-dominant) and the new WorkSpace ONE (watch the cool 7-min demo here). I am personally really sold on this story and here’s why:

Desktop OSes (Win10 1709+ and MacOS High Sierra+) can be managed with EMM just like the mobile devices, and both MS and Apple seem to take this direction seriously.

CE6 is dead and WEHH6.5 dies in less than two years. Given no other competition, everythin will be either iOS or Android, and none of those can be realistically deployed without MDM/EMM. And another weak spot for AirWatch that is going away soon.

Identity management and SSO have fully matured in the last few years, and are ripe to become standard, rather than “enhanced/advanced” functionality in the Enterprise infrastructure. And WorkSpace ONE (if you’ve seen the demo) has a unique value proposition here.

Being able to show off AutoCad on an iPad is cool! But more importantly, being able to free the enterprise from the leash of legacy apps (must have IE6, Java5 etc etc etc) by delivering them virtualized even to mobile devices means that mobile first has to real reason not to happen.

Who else can combine the industry-leading EMM/UEM, identity management and virtualization into one package?

So, where else to be in the EMM world?

Or do you disagree? Let me know your thoughts here or on LinkedIn/Twitter!

P.S. Bonus point to those who recognize the cover image

]]>https://arsenb.wordpress.com/2018/04/23/change-of-wind/feed/0WindOfChangeapcsbDo Android Enterprise and GMS mean the end of differentiation for Android Device and EMM vendors?https://arsenb.wordpress.com/2018/04/04/do-android-enterprise-and-gms-mean-the-end-of-differentiation-for-android-device-and-emm-vendors/
https://arsenb.wordpress.com/2018/04/04/do-android-enterprise-and-gms-mean-the-end-of-differentiation-for-android-device-and-emm-vendors/#commentsWed, 04 Apr 2018 15:11:26 +0000http://arsenb.wordpress.com/?p=895After publishing my post regarding tightening the screws on non-GMS devices and gradual move towards all-GMS in the Enterprise, I have received a response, which was very representative of what I was thinking last year, when digesting all the Android Enterprise news [formatting and edit by me]:

AOSP was or still is the major [vendor] differentiator. With all these Android changes1) it will be almost no matter what devices will be engaged
2) the role of 3rd party EMMs will go down. Google will be everywhere.
Do you feel it as a positive news?

Before looking any further, please pause and consider, how do you feel about that? Now, read on!

The latter was not that bad, since most Enterprise customers did not want uncontrolled access to Play Store, and did not need other apps such as GMail anyway (plus, the annoying initial setup wizard, which one could not even skip in the earlier versions). In fact, the subject of getting rid of GMS was very popular in the last few years, indeed. Most customers’ requirements began with “disable the Play Store“.

What we have now is very different:

Google Play Protect has made Play Store much more secure than before. With additional features, in fact it is more secure to have GMS on device, that not have it, since many GMS components receive same-day security patches [Samsung users, how long do you want for the next security patch?]. Check this 2017 Android security report for more details.

In fact, recent versions of GMS certification mandate monthly updates for at least two years (if I’m not mistaken). I know quite a few AOSP devices that never received any update after 3 months to market.

Managed Play Store made access controllable, manageable and gave a whole new layer of visibility to enterprise admins. Of course, many companies, who offered their own versions of “Enterprise App Store” won’t be happy, unless they had some unique offerings, which they should now be able to build on top of standard, Google-maintained platform to further focus on their own unique advantages vs grinding the basic app distribution code.

Finally, and most importantly, up until Android L/M Google did not really care about Enterprise, but now they do, and they listen.

So, how about the aforementioned device and EMM vendors? Absolutely the same logic applies to them!

Instead of developing hacks, wasting lots of resources on maintaining/rewriting/testing them after every update, providing some level of uniformity of such hacks across different devices/OS revisions, they can now build on top of standard, Google-maintained platform to further focus on their own unique advantages: hardware features, extra software (not bloatware please!), CTS-compliant extensions, fast and reliable updates etc.

Basically, instead of grinding the hacks, they can focus on executing their strategy and vision. Now, how do you feel about that?

]]>https://arsenb.wordpress.com/2018/04/04/do-android-enterprise-and-gms-mean-the-end-of-differentiation-for-android-device-and-emm-vendors/feed/1apcsbThe final nail in the coffin of the non-GMS Enterprise devices?https://arsenb.wordpress.com/2018/04/03/the-final-nail-in-the-coffin-of-the-non-gms-enterprise-devices/
https://arsenb.wordpress.com/2018/04/03/the-final-nail-in-the-coffin-of-the-non-gms-enterprise-devices/#commentsTue, 03 Apr 2018 08:00:56 +0000http://arsenb.wordpress.com/?p=893Google had taken a long way to make GMS (Google Mobile Services, i.e. Play Store etc) acceptable, useful and then essential for the Enterprises. Now, the final nail in the coffin is being prepared…

Current state

However, as time went by, Google addressed most, if not all, of the issues, and introduced new great features: Android Enterprise, Managed Play Store, adjustments to CTS requirements, EULAs and policies etc. Combined with additional management features and developer-facing APIs available only with GMS – it all made having Google’s Services and apps on the device much more lucrative. Around 2016-2017 I’ve seen a major shift in perception and a “GMS-by-default” approach (i.e. only use AOSP if there are specific issues).

In addition, those who wanted Google’s apps and services on AOSP devices, could have simply installed them independently. One such popular distribution is GApps.

Though technically illegal (while AOSP Android is sort of free, GMS apps are proprietary and Google only allows installation only on GMS-certified devices), Google turned a blind eye at this at large.

The near[est] future

Finally, the upcoming Android P seems to have nailed the rest of the required enterprise features: among many there is rapid provisioning via barcodes, ephemeral users for depersonalized (kiosks and the like) and multi-user (shift workers) devices, great UI lockdown enhancements etc etc etc. Basically, in my opinion, if everything declared works as intended, Android would have become a fully-fledged Enterprise mobile OS (legal/policy matters aside).

The final nail

Finally, having implemented all that, Google seems to have begun tightening the screws. There are reports coming, that non-GMS devices will be denied access to the Play Store, and other APIs may follow suit.