This week Google announced Android Instant Apps at Google I/O 2016. Instant Apps allow developers to break their app into parts that people can use without having to install the complete app on their device. The feature sounds useful, but certainly raises questions about Android Instant Apps security.

A use case for Instant Apps offered by Google involves a friend sending you a link to a recipe in a cooking app. Clicking the link will bring up the recipe directly in the app on your device, but without you having to wait to install the app. Your device only downloads the code it needs to serve that particular piece of content. The size of these modules will likely vary, based on how much of the app’s functionality is required to complete the relevant task.

How will permissions for Instant Apps be managed?

When describing the capability, Google clearly says the app needs to be modular. This would enable both the size and capabilities of an area of functionality to run separately from the entire app. Rather than installing the full app, a user’s device downloads and runs just the necessary module inside a sandbox, which presumably limits what functions that Instant App can call on the system, and should block all sensitive operations. From an architecture standpoint, it’s likely that an Instant App’s capabilities can be pretty effectively isolated and limited – in fact quite similar to how a web page can run a lot of Javascript but not compromise your system. Today’s web apps are not just images and HTML content, but are really complex app code running in a sandbox (the browser). So the concept is actually familiar. However, we have to consider the potential for Instant Apps to develop into an attack vector. Just as folks have managed to break out of browsers to get privileges on desktop operating systems, attackers will try to do the same via Instant Apps. Calling system APIs, other apps’ content providers, and user calls-to-action could all present attack surfaces.

How will users know what instant mobile apps to trust?

Another aspect of Instant Apps that concerns me is the blurring of a line of understanding that was already tenuous for many users, making things less transparent. With the Internet, you look at the URL to see where you’re going and look for a URL, and HTTPS. If someone deep links into an Instant App, how do I judge that app’s authenticity and that it’s provided by the company it claims to be? How do I know if it uses TLS to secure communications? With Instant Apps, you click what looks like a hyperlink but rather than a web page in a familiar browser, you get an unfamiliar app interface that you did not install. Within that interface an attacker may be capable of all kinds of spoofing, all without the many browser protections we’ve spent years building. With apps, the user must trust the app and the platform, and the platforms are not patching security vulnerabilities fast enough. The devices that will support the Instant Apps feature will also affect the security implications. Android devices vary, obviously, and so too do their policy enforcement mechanisms. The enforcement capabilities available to the device executing an Instant App will determine whether the app is effectively isolated and granted only the minimum permissions needed to function. We’ll have to wait for more technical details from Google about the security protections they plan to implement. The convenience of Instant Apps is appealing, but attackers will view it as a shiny new attack vector, and for me the security jury is still out.

What to read next:
Ted Eull

Ted Eull

linkedin icon twitter icon

VP of Risk and Privacy at NowSecure

Ted directs company risk, privacy, and security initiatives to ensure success of the growing company and NowSecure mobile security platform.