Progress updates on Privacy Sandbox for Android

These progress updates will share a summary of new developments and updates to the design proposals, key questions and feedback we have received, and updates on the developer preview releases.

New releases

Developer Preview 7 released

This latest release is a major milestone that is the foundation for upcoming Privacy Sandbox Beta releases. This release includes additional functionality on Protected Audience waterfall mediation support, Attribution Reporting event registration daisy-chain redirects, and other API changes.

We'll continue to update the Developer Preview resources as new functionality is released in the months to come. You are encouraged to sign up to receive updates on the initiative.

March 2023 Beta released

This release represents the availability of Privacy Sandbox APIs on public devices and is functionally equivalent to Developer Preview 6. Developers can access the APIs in Beta releases through the Extension SDK.

Update on timeline for Developer Preview releases

All dates and details are subject to change

Each Developer Preview and Beta release will come with detailed release notes and guides to describe what functionality is and is not available with each release.

Available now:

  • Developer Preview 7 - Includes functionality that allows you to design integration using relevant APIs including the SDK Runtime, Topics, Protected Audience, and Attribution Reporting APIs
  • Beta program available for limited production testing. The March 2023 Beta release represents the availability of Privacy Sandbox APIs on public devices and is functionally equivalent to Developer Preview 6.

Early 2023:

  • First stable API release of the privacy-preserving APIs on a small percentage of Android 13 devices.

Through 2023:

  • Further iterations of Developer Previews and stable API releases with additional functionality. Expansion to more users and Android devices.

Reminder: When we announced the Privacy Sandbox on Android in February, we underlined that, while we design, build, and test these new solutions, we plan to support existing ads platform features for at least two years, and we intend to provide substantial notice ahead of any future changes.

Design proposal updates

This section describes several specific updates to the design proposals.

Reflection APIs

In our original SDK Runtime design proposal, we requested feedback on our proposal of preventing access to the reflection and invoke APIs, with the goal of helping SDK developers prevent tampering by other SDKs.

We received valuable feedback on affected use-cases and after a further investigation on the utility and the risks, we will be allowing the use of reflection and invoke APIs within the SDK runtime, and have updated our design proposal accordingly.

However, an SDK will not be allowed to use reflection or invoke APIs on another Runtime-enabled SDK. Instead, for SDK-to-SDK communication in the SDK Runtime, we are designing separate APIs for SDK discovery, which will be detailed in a future update.

We are continually investigating ways to reduce the risk of tampering by other SDKs, and as such we still propose preventing the use of JNI code within the SDK Runtime, and are actively considering other APIs. We will be sharing a full proposal of prohibited APIs in a future update.

Attribution Reporting API

Topics API

  • The Topics API returns a list of up to 3 topics, one for each of the past 3 epochs (for example, during the past 3 weeks). We have updated the Topics API technical proposal to clarify that the returned topics represent the interests of the user and any or all the returned topics can be used for ads personalization.

Summary of additional questions and feedback received

This section presents some of the questions and feedback that we've received, along with our responses.

General questions

Will the Privacy Sandbox on Android apply to connected TV devices?
Our current design proposals are focused on supporting use cases for mobile devices and apps. We plan to share more on other Android form factors in the future.
How will the Privacy Sandbox on Android be rolled out to devices for the Beta?
To flexibly release updates over time to users, the key components will be distributed as mainline modules to supported Android mobile devices. This will allow us to deliver improvements to supported devices in a seamless way, outside of the Android platform's normal release cycle.
What's your plan for Kotlin support?
We're working on iterating the Privacy Sandbox API design and intend to enable developers to write idiomatic Kotlin code. Related developer resources, such as sample apps in the Developer Preview, are available in Kotlin (in addition to Java).
What are the user-level controls for the Privacy Sandbox and what are the expected timelines for the rollout of these controls?

The final designs are still being developed, but during the beta we intend to provide user controls in device settings to:

  1. Leave or rejoin the Privacy Sandbox solutions
  2. Remove specific inferred topics from the Topics API
Can app store ecosystems other than Google Play use the Privacy Sandbox solutions?

All of the Privacy Sandbox solutions are part of the Android Open Source Project (AOSP), so could be adopted by other app stores if desired. Reach out to the app stores that you work with to better understand their plans.

SDK Runtime

How will SDKs versions be managed under these proposals? Will apps be able to control SDK version dependencies if vendors can independently update their SDKs?

This is currently being designed; one approach under consideration is that SDK developers specify the major.minor.patch version of any SDK they choose to distribute through an app store that supports the SDK Runtime.

App developers can then choose the major.minor version they wish to depend on by declaring it in their app manifest. The most recent patch release for that major.minor version will be installed until the next patch is released (which itself will be automatically installed) or until the app developer rebuilds their app specifying a different major.minor version dependency.

Which types of SDKs is the SDK Runtime intended for?

The initial version of the SDK Runtime is being designed to support use-cases for advertising-related SDKs, including SDKs which enable ad serving, ads measurement, ads fraud, and abuse detection.

Although the initial focus is for advertising-related SDKs, developers of non-advertising-related SDKs that seek a pro-privacy posture and believe they can operate under the conditions outlined above can share feedback about their SDKs running in the SDK Runtime.

We currently use permissions outside of those specified in the proposal for our use cases. Can we request further permissions?

We are keen to understand advertising-related use cases that require specific access permissions beyond those in our initial design proposal.

Would moving SDKs into the SDK Runtime process provide download size or space savings?

If multiple apps are integrated with individual runtime-enabled SDKs of the same version, then this would save on download size and disk space.

Does the SDK permission to access the AAID (AD_ID) depend on the app's permissions?

The RE SDK's ability to access the AAID is dependent on both the app and the SDK declaring the permission in their app's manifest. In a future proposal update we will detail the API that SDKs will be able to use to get the AAID if they have the permission.

IP addresses, OS versions, and alternative data: will these be available to advertising-related SDKs?

We are currently working through the system properties that advertising-related SDKs will have access to, and this will be shared in a future design proposal update. We have not published any policy regarding usage of these properties.

Is the App Set ID that our SDK collects identical across many apps even when those apps belong to different Google Play developer accounts? How can we block fraudulent users across multiple apps without AAID?

An app or any of its SDKs may only have access to the App Set ID value associated with the host app's Google Play developer account. The Privacy Sandbox on Android will not offer a cross-publisher identifier for fraud purposes. For now, developers could consider using IP as a slightly less consistent alternative.

Topics

Would I be able to see a list of all possible topics that can be returned by the API?
For testing purposes, Developer Preview 1 uses topics from this taxonomy, which is subject to change. We expect to evolve this over time based on feedback from the ecosystem.
If the Topics taxonomy is subject to change, how can we account for these changes on downstream buy-side models?
The Topics API response will include a version number for the classifier and taxonomy.

Protected Audience on Android

Will exclusion targeting be supported by Protected Audience?

The current design proposal does not support negative targeting based on a custom audience in Protected Audience.

For app install campaigns, we will offer filter ad functionality for ad tech providers to filter out apps that are already installed. We are also exploring how frequency capping-based campaign negative filtering needs could be supported. More detail will be provided in upcoming updates to the design proposal.

Can custom audiences be created by the seller ad networks? Or are they limited to the buyer ad networks?

Our current proposal for custom audiences focuses on the buyside use case, given that they are intended to support the creation of buy-side bids for the remarketing use case in a privacy-preserving way.

Attribution reporting

Will the Privacy Sandbox APIs work together to support web-to-app and app-to-web use cases?
We are exploring use cases where a mobile browser app calls the Android Attribution Reporting API to enable attribution across app and web on the same device. If you choose to enable app-to-web, then Privacy Sandbox for Android APIs will be used for storage and attribution and will dedupe attribution across app and web (though you may receive separate reports for app and web from the API which will need to be combined).
Does the API support other attribution models besides last click?
The API supports a source-prioritized, last touch attribution model. Additionally, the proposal supports optional attribution logic for post-install conversions to be attributed to the click or view that drove the install.
Will the Privacy Sandbox impact the Play Install Referrer?

On the basis of the current design and plans, the Privacy Sandbox APIs will not impact the functionality provided by the Play Install Referrer.

Some developers have identified ad formats whereby users can be "rewarded" for completing specific post-click events. Without user level attribution, this would be a challenge under current proposals.

This is an area undergoing investigation to determine possible solutions. We encourage additional feedback for this use case and other use cases that may exist.

Why does attribution happen independently for each ad tech platform?

Today, many advertisers believe it is important to get a deduplicated view of their conversion events across networks, and it's common practice to use a Mobile Measurement Partner (MMP). This will continue to be easy to do with the new APIs, but also makes it easier for individual tech platforms or advertisers to measure directly if there is a desire to do so.

The use of redirects means that you do not need a physical presence of an SDK in every app, but do need a relationship with the ad tech SDKs to be involved in the redirect process.

A key benefit of this approach is that everyone can have their own meta-data and aggregation keys for their own business logic, plus define their own priority.

Is there any validation or verification of installs from the Play store?

Validated installs are used only for optional post-install conversion attribution logic. These validated installs will not be sent out by the API. The API will only send reports based on the conversions that are registered and will not return any signal on whether the user has installed the app before.

Are you doing any click or view validation? For view validation, is there a minimum duration?

The current API proposal supports basic click validation via InputEvent. We are looking into more robust forms of click validation and view validation. We encourage additional feedback for these use cases, especially on what types of view definitions would be helpful to the ecosystem.