Android’s SDK Runtime in Privacy Sandbox is a game changer

Google’s proposed SDK runtime in Privacy Sandbox on Android is a game-changer that represents a massive opportunity to both reduce ad fraud and boost people’s privacy. It’s also something I wouldn’t be surprised to see Apple copy on iOS, but deliver earlier than Privacy Sandbox’s minimum two-year timeline for delivery.

This is part one of a longer series of deep dives into Privacy Sandbox for Android where I’ll be looking at Google’s new technology for privacy and marketing:

• SDK Runtime (this post)
• Topics API (how Privacy Sandbox will do ad targeting)
• FLEDGE on Android (how Privacy Sandbox will do ad retargeting)
• Attribution Reporting (how Google is proposing ad measurement will work

Also see Mobile Attribution via Android Privacy Sandbox and without GAID, Singular CEO Gadi Eliashiv’s deep dive into mobile attribution post GAID.

And finally, sign up for the LinkedIn livestream Gadi and I will run on Thursday.

SDKs and apps: the promise and the peril

In the beginning there was the app. A developer said: I need more app candy and capability, but I don’t have the recipe, or ability to bake the cake all by myself. Solution providers filled the gap with delicious pre-coded goodies that app developers could simply conjure up in code without having to do very much work at all.

Wonderful?

Sure.

But SDKs with extensive fingerprinting code were the cause of Apple rejecting app updates back in the early days of iOS 14.5. They’re one way some apps have been kicked off the App Store. And SDKs from rogue ad networks have been accused of driving both attribution fraud on billions of devices and orchestrating privacy-threatening data exfiltration … including snooping on communications in apps.

The modern app ecosystem couldn’t function without SDKs. They’re absolutely critical to the software that everyone who uses a smartphone or a tablet today depends on.

But they’re also a double-edged sword.

Google thinks it has a solution.

Go to your room right now (SDKs are getting grounded)

Because some SDKs have been very bad boys indeed — and you can bet we’re privy to less information on just how bad than Google itself — Google is grounding them.

Or, confining them to a sandbox.

An “execution environment,” if you will.

Inside this execution environment SDKs will have specific permissions and will execute them outside the main app process. In other words, SDKs will have much less implicit insight into what apps are doing and app developers will have full explicit control — or at least more control — over what an SDK sees and does.

In Privacy Sandbox for Android, processes are isolated. 

SDKs live in a separate world. Adtech SDKs are no longer able to see and track app usage via persistent identifiers without developer knowledge and consent, and they’re also going to have a much more difficult time collecting perishable identifiers, or factors that can be summed up into a temporary identifier.

In addition, Google’s making it harder for SDKs to tamper with the functionality of other SDKs.

At the same time, however, Google is leaving room for SDKs to detect and prevent ad fraud and invalid traffic, where developers permit.

Google is your messenger now, SDKs

In the old model (today), apps and SDKs communicate unimpeded. They live, after all, in the same space and can chat whenever they want, however they want.

In the new world, which Google will provide in beta by the end of 2022, Google will build a “marshaling layer” which developers will call from within an app.

1. App needs the SDK to do something.
2. App code calls the marshaling layer and delivers a packet
3. The marshaling layer delivers the request to the SDK (presumably checking it first for legitimacy)
4. The SDK delivers an answer back to the marshaling service
5. The marshaling layer completes the loop with the needed data or functionality for the app

An important point: this could be asynchronous. As Google has currently defined the process, the “SDK asynchronously satisfies the requests and responds using the callbacks.” That could potentially mess with functionality that requires instant response, which is a little confusing: pretty much everything in an app requires instant response as the app needs to present options for users and then deliver responses based on their decisions and input.

However, this is all pre-beta at the moment, so there’s no need to get too worried about that just yet.

Also: Google is building in functionality for SDK-to-SDK communication for scenarios like mediation and bidding. That’s a massive part of the adtech ecosystem on mobile with SDK networks that offer mediation services like the new titans of adtech: ironSource, Liftoff+Vungle, AppLovin, Digital Turbine, and Unity.  There will be the ability, Google is saying, for SDKs to offer ad impressions or run ad auctions by communicating with other SDKs, whether they’re inside or outside of the SDK runtime environment.

However, there’s clearly open questions here: notice the language Google uses like “should” and “investigation.”

“The coordinating SDK, RE [runtime-enabled] or not, should be able to access all RE and non-RE SDKs for normal operation. Rendering in this context is an active area of investigation.”

SDK makers: get ready to submit

In some sense, SDK makers have gotten a free pass. While apps themselves have to go through an App Store approval process on iOS or Google Play, SDKs have just kind of glided through on their customers’ or developers’ efforts.

Not any more, likely.

Given the unique sandboxed runtime environment SDKs will now exist in, Google is proposing that SDK makers submit their SDKs to Google Play and then become available for use by apps via Google Play itself. Google says this will ensure quality and consistency, streamline publication, and make minor SDK updates — that don’t require app code changes to function — quicker and cleaner.

Google’s ideas here are quite nebulous, however, and it’s not at this point saying explicitly that this is the future of distribution for all SDKs.

However, software developers can read the tea leaves as well as anyone else, and once this mechanism is in place and available, it’s not hard to imagine that it will become the preferred — and over time likely the mandatory — method of SDK distribution.

Much more to dig into

As I mentioned up top, there’s a lot more to dig into here. Sign up for updates on our blog newsletter to be notified when we publish more.

Also, I’m doing a live stream with Singular CEO Gadi Eliashiv on this topic on Thursday, February 24. Sign up for that here.