As noted in our recent Q2 Mobile Threat Report, Google’s Android for Work recently introduced a set of new features aimed at improving the security posture of Android in the enterprise. Following these updates, Android Instant Apps was announced at Google I/O ‘16.
According to Google, “Android Instant Apps enables Android apps to run instantly, without requiring installation.” They’ve built this capability to get rid of “installation friction” or the time and steps it takes to install an app and get to specific content. Developers can upgrade their existing apps, modularizing them so that only the elements a user needs in a scenario are loaded. For example, don’t have the parking app a meter requires? Simply tap the parking meter with your phone and via NFC and Android Instant Apps, just the the app’s components for choosing how long you want to park and for paying with Android Pay will be loaded. Using these instantly available components, you can park and pay without downloading the app.
Google is working with a small group of developers now and will be rolling Instant Apps out to users over the next year. Accordingly, the framework or SDK required for Instant Apps is not yet available publicly but Google has started releasing information at its developer site.
With the information available so far, we know that Android Instant Apps:
- Will run on most Android Devices, Android 4.1+ or higher.
- Use the same Android API’s as regular apps but block access to certain features, such as background services, notifications, and reading unique device identifiers.
- Use the same permission models introduced in Android 6.0. This means permissions are asked at runtime so, if for example, an app tries to send an SMS, you’ll get the permission request the first time the app tries to send a text.
Appthority is focused on protecting enterprises from mobile app risk so we also want to understand the security implications for both mobile users and enterprises. Without full information about the details of Instant Apps, at present, there are many unanswered and unassessed security questions around this new project.
According to Google: “As a developer, you won’t need to build a new, separate app. It’s the same Android APIs, the same project, the same source code. You’ll simply update your existing Android app to take advantage of Instant Apps functionality. …. You modularize your app, and Google Play downloads only the parts that are needed, on the fly. And when you do upgrade, your app will be available to more than a billion users on Android devices going back to Jelly Bean.”
While this is undoubtedly easier for app users, we wonder if this will be a good thing in the context of managing enterprise app risk. Specifically, we are concerned about three main areas:
1. Bridging Code Becomes A Bigger Attack Vector
Instant Apps are ‘upgraded’ apps, meaning they have been modularized and can be delivered via Google on the fly. The process of modularizing and delivering app components involves a translation from mobile web scripts to native Android code. This may introduce some additional security risks. Bridging code, like the kind required for this translation, is a well-known vector used by attackers, aggressive adware, and even app developers to push patches to their apps without going through the proper app vetting process. The recent JSPatch back-door (an iOS vulnerability) is an example of how this type of code can be used by bad actors to circumvent app store vetting and access personal and enterprise data.
2. More Access Via Pre-Marshmallow Access Settings
Instant Apps will, according to Google,“take advantage of Google Play services features — like location, identity, payments, and Firebase — which are built right in for a seamless user experience”. This means that Instant Apps delivered to a pre-Marshmallow OS device may have more binary – and less secure – access settings for those features. Users can only allow access or not allow access (which may prevent the app from functioning properly), they cannot choose to only allow access when the app is running, for example. Additionally, Users who have not upgraded to the latest OS don’t benefit from the security upgrades that are part of each new OS release.
3. Risky Behaviors Become Harder to See
Third, malware is already present in the Google Play Store and apps have been approved contain risky behaviors in widely distributed SDKs or adopted code snippets. Our Q1 Mobile Threat Report found that, of the 150 most common apps on enterprise devices, 100% of the Android apps were found to have data leakage and privacy invasive behaviors. Will Google’s process for evaluating Instant Apps – in their modules or their entirety – change to improve security? Further, if the distribution method for Instant Apps is more akin to the delivery of sideloaded apps, will these apps be visible to current security technologies for malware and deeper app analysis? If not, many Instant Apps could be out of compliance with corporate security policies but remain an undetected and unprotected part of an enterprise’s mobile app ecosystem.
In short, Instant Apps, may decrease install friction but at the expense of increasing blind spots and app risk to the enterprise. At present, there are more questions than answers about the impact of Instant Apps on corporate mobile environments. We are monitoring this new offering closely and will provide an update as we learn more about the true risk implications from Android Instant Apps.