Google’s Privacy Sandbox Plans Include Separate Third-Party Code Verification

Apple and Google, the duopoly controlling the $133 billion-a-year mobile app market, typically differ when monitoring their respective ecosystems; the iPhone maker is rigid in its controls while the latter generally favors open source.

However, the pressing need for more innovative security controls has prompted some to speculate that their policies may soon overlap when it comes to controlling third-party code on publisher apps.

Earlier this year, Google confirmed what many thought was inevitable when it confirmed that it would introduce its Privacy Sandbox concepts to the Android mobile operating system – a move that somehow apes data limitations on iOS. from Apple.

Unsurprisingly, every industry level that felt the burn of Apple’s iOS 14 — a move that would have wiped out a total of $16 billion in revenue from Meta, Twitter and YouTube in less than 12 months — fear that Google’s plans will have a similar impact.

However, Google’s reliance on ad revenue, not to mention the regulatory difficulties it faces, means it has to take a trickier route with its privacy sandbox proposals for Chrome that are often the subject of criticism. subject to bruised peer review as they go along.

The Pillars of Privacy Sandbox on Android

The nascent plans for Privacy Sandbox on Android were first rolled out in February 2022 with a lot of aplomb, but few details, and since then those who manage the mobile operating system’s privacy system have better fleshed out their proposals, according to sources familiar with their conversations.

Currently, Privacy Sandbox on Android contains a number of talking points that largely mirror the targeting and audience tracking proposals in Google Chrome after the removal of third-party cookies. These include recommendations for ongoing interest-based targeting known as the Topics API, a proposal for retargeting Android device users dubbed FLEDGE, as well as a proposed way to measure campaign performance with limited data signals called Attribution Reporting.

Google’s Privacy Sandbox proposals in Chrome have been getting mixed reviews, its first FLoC proposal is now KO’d, with the outcome of these ongoing discussions far from certain.

Policy Tier Code Proposals

However, delegates at this week’s App Growth Summit in New York were enthusiastic about early proposals to control third-party code on apps submitted to Android app outlets, dubbed SDK Execution, with some speculating that Apple might seek to imitate.

Currently, Google policy does allow third-party SDK developers, such as in-app measurement companies, to share the same permissions as their Android app publishers. Such a policy allows developers of third-party services to better integrate their SDKs with their client’s Android application code. From there, the host developer submits the packaged app for distribution through 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 to be collected by third-party SDK vendors without a host publisher’s knowledge. Indeed, publishers often rely on self-reporting from their SDK vendors, as they may not always have the resources to regularly verify the data collected by their partners.

“In Android 13, we plan to add a new platform feature that allows third-party SDKs to run in a dedicated runtime environment called SDK Runtime,” according to Google’s documentation. It then details how the initial release of SDK Runtime will focus on ad-related SDK support, including ad serving, measurement, as well as fraud and abuse detection.

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

Remove editor headaches?

During the week-long Application Growth Summit, keynote speaker Mike Brooks, vice president of revenue at WeatherBug, described the proposal as establishing a repository of privacy-compliant SDKs “that effectively takes responsibility for managing the SDK as potentially “revolutionary”.

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

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

Trevor Hamilton, Managing Director, Americas, Kochava, described the Privacy Sandbox proposals as a large-scale, developer-friendly proposal, adding that it’s critical that publishers understand their partners’ surveillance capabilities before they go to market. , because users often do not filter the terms and conditions to which they agree.

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

Will Apple imitate?

Speak separately At this week’s IAPP Global Privacy Summit, Apple CEO Tim Cook advocated centralized control over app developer partners, saying less stringent controls meant “that data-hungry companies would be able to circumvent our privacy policies” and track iPhone users against their will.

WeatherBug’s Brooks, along with several other conference attendees who requested anonymity due to their employers’ public relations policies, believe that Apple could potentially replicate Google’s approach, especially since the amount of data that app developers collect from phone users is under scrutiny.

Although Kevin Susman, vice president of brand and communications at MATRIXX Software, said it’s hard to compare how Apple and Google deal with privacy. He observed that it appears Google is trying to enforce a decentralized privacy strategy as opposed to Apple’s walled garden approach.

“Apple makes money from developers, now it also makes huge ads monetizing privacy,” he added in an emailed statement. “It gets to the heart of the matter: Will Apple follow Google’s privacy approach for developers? [sic] opting out of Apple’s ecosystem and pursuing sideloading or an alternative app store? I don’t think so, at least not for a while because Apple has a walled garden in their DNA… What I think they’re going to do is basically isolate third-party developers [sic] who withdraw from the Apple App Store in the name of security.

Leave a Comment