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

By Ronan Shields

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

However, the pressing need for more innovative security controls has prompted some to think their policies may soon overlap when it comes to policing third-party code on publishers’ apps.

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 …read more

Source:: Digiday