Google’s Privacy Sandbox plans include separate vetting for third-party code

Earlier this year Google confirmed what many had thought inevitable when it confirmed that it would introduce its Privacy Sandbox concepts to the Android mobile operating system — a move that will, somewhat, ape the data limitations on Apple’s iOS.

Unsurprisingly, all tiers of the industry that felt the burn of Apple’s iOS 14 — a move that is estimated to have wiped a combined $16 billion in revenues from the likes of Meta, Twitter, and YouTube in less than 12-months — are concerned Google’s plans will have a similar impact.

However, Google’s reliance on advertising revenue, not to mention the regulatory travails it faces, means it must tread a more delicate path with its Privacy Sandbox proposals for Chrome often the subject of bruising peer review as they advance.

The pillars of Privacy Sandbox on Android

The nascent plans for Privacy Sandbox on Android were first unfurled in February 2022 with much aplomb, but little detail, and since then those stewarding the mobile OS’s privacy scheme have better fleshed out their proposals, according to sources familiar with their conversations.

At present, Privacy Sandbox on Android contains a number of tent-pole discussion points that largely reflect the proposals for audience targeting and tracking in Google Chrome after third-party cookies are retired. These include recommendations for continued interest-based targeting known as the Topics API, a proposal for retargeting Android device users dubbed FLEDGE, as well as a proposed means of measuring campaign performance with limited data signals called Attribution Reporting.

Google’s Privacy Sandbox proposals in Chrome have been met with mixed feedback, its early FLoC proposition is now KO’d, with the outcome of those continuing discussions far from certain.

Proposals to police third-party code

However, delegates at this week’s App Growth Summit in New York City effused over early proposals to police third-party code on apps submitted to Android app outlets, dubbed SDK Runtime, with some speculating that Apple may look to emulate it.

Currently, Google’s policy effectively lets third-party SDK developers, such as in-app measurement companies, share the same permissions as their Android app publishers. Such a policy lets third-party service developers better integrate their SDKs with code on their client’s Android app. From here, the host developer submits the packaged app for distribution via an app store.

However, it also opens the door for bad actors to infect the wider ecosystem as it creates the potential for undisclosed user data collection by third-party SDK providers without the knowledge of a host publisher. This is because publishers often rely on the self-reporting of their SDK providers as they don’t always have the resources required to regularly verify what data their partners are collecting.

“In Android 13, we plan to add a new platform capability that allows third-party SDKs to run in a dedicated runtime environment called the SDK Runtime,” according to documentation from Google. It goes on to detail how the initial version of SDK Runtime will focus on supporting advertising-related SDKs, including ad serving, measurement, as well as fraud and abuse detection.

A Google spokesperson informed Digiday that the new set of technologies is optional for SDK developers as the Privacy Sandbox proposals advance.

Removing publishers’ headaches?

During this week’s App Growth Summit, keynote speaker Mike Brooks, svp of revenue at WeatherBug, described the proposal as establishing a repository of privacy-compliant SDKs” that effectively takes responsibility for SDK management as potentially “groundbreaking.”

He added, “So, it’s basically a [proposed] library where every partner submits their SDK and Google combs through it and has to approve it, so there’s no bad code in it … then all the publisher has to do is flip a switch and the SDK is integrated.”

SDK integrations are often complicated tasks for app publishers with the process of vetting third-party code often delaying much-needed app updates. “You often find that there’s a two-to-three month delay due to queueing of SDK-integrations, then you just find there’s so much business you haven’t been able to do,” Brooks told Digiday.

Fellow AGS keynote speaker, Trevor Hamilton, managing director, Americas, Kochava, described Privacy Sandbox’s proposals as a scaled developer-friendly proposal, adding that it is critical for publishers to understand the surveillance capabilities of their partners before going to market as users don’t often screen the terms and conditions they consent to.

“There’s a small percentage of people that really dig into the details and really understand it,” he told conference attendees. “Just like with cookie policies, I think people are just gonna reach for that ‘X’ as fast as they can to continue their content experiences as fluidly as possible.”

Will Apple imitate?

Speaking separately at this week’s IAPP Global Privacy Summit, Apple CEO Tim Cook, advocated centralized control of app developers’ partners arguing that less rigid controls meant “that data-hungry companies would be able to avoid our privacy rules” and track iPhone users against their will.

WeatherBug’s Brooks, along with several other conference attendees who requested anonymity due to their employers’ PR policies, believe that Apple may potentially replicate Google’s approach, especially as the amount of data app developers collect from phone users comes under the microscope.

Although Kevin Susman, vp brand and communications at MATRIXX Software, said it’s difficult to compare how Apple and Google treat privacy. He observed that it seems Google is trying to apply a decentralized privacy strategy as opposed to Apple’s walled-garden approach.

“Apple makes money from the developers, now, it also makes huge ads money monetizing privacy,” he added in an emailed statement. “This gets to the heart of the question — will Apple follow Google’s privacy approach for devs [sic] who opt out of Apple’s ecosystem and pursue side-loading or an alternative app store? I don’t think so, at least not for a while because Apple has a walled garden in its DNA … What I think they will do is essentially wall off third-party devs [sic] that opt out of Apple’s App Store in the name of security.”