FLEDGE services for Chrome and Android

FLEDGE (Android, Chrome) is a Privacy Sandbox proposal to let marketers target ads to custom audiences, based on audience members' previous mobile app or web engagement, in ways that limit third-party data sharing. FLEDGE services provide real-time information to advertisers and adtechs.

# Who should read these updates?

• If you work in adtech, advertising, or ad mediation, this article will share a high-level overview of the cloud services you can use to optimize FLEDGE.
• If you're a developer, the explainers will link to and provide more in-depth technical details and setup.

These services are designed for supply-side providers (SSPs) and demand-side suppliers (DSPs). No action is currently required from website and application content publishers, though an SSP may reach out directly to coordinate efforts.

# Cross-platform, real-time services

FLEDGE was built for apps and the web, so it's critical that services work across platforms and in real time.

The FLEDGE services explainer details the high-level system overview, trust model, privacy considerations, and security goals for current and future proposed FLEDGE services.

If you've been testing FLEDGE in production, you'll already be familiar with the Key/Value service. This proposal has been updated with a new trust model for cloud implementation. If you're familiar with the "Bring Your Own Server" model, we've provided migration details and timeline updates.

The second service is newly proposed under the FLEDGE umbrella: Bidding and auction service. This new proposal, offloads bidding and ad auctions from the client into the cloud, while preserving privacy of the ad auction and bidding service. We welcome feedback on the merits of the new Bidding and auction service idea versus the current on-device design, especially from testers who have already gained experience as part of the ongoing Chrome ads relevance and measurement origin trial. This proposal is in the discussion phase of the proposal life cycle. The Bidding and auction service is not in scope for a "Bring Your Own Server" model.

# Key/Value service

Adtechs can use the Key/Value service to supply real-time information to the FLEDGE ad auction. This information could be used in a number ways:

• Buyers may want to calculate the remaining budget in an ad campaign.
• Sellers may be required to check ad creatives against publisher policies.

The Key/Value service will have APIs for developers that allow for custom, user-defined functions. This allows developers to execute their own logic for tasks such as multiple look-ups and other advanced queries.

By implementing a cloud service, adtechs can securely store data for their use and keep it up-to-date as the ad campaign progresses.

The TEE-based FLEDGE Key/Value service has been open sourced.

# Bidding and auction service proposal

The proposal for FLEDGE proposes ad bidding and auction execution to happen on-device.

FLEDGE bidding and auction processes may be compute intensive and involve several calls over the network. Migrating these computations to the cloud can free up computational resources and network bandwidth for the device, and optimize overall ad rendering latency.

With the Bidding and auction service, ad space buyers and sellers can offload the execution of ad bidding and auctions to services running in trusted execution environments in the cloud.

Unlike the Key/Value service, the Bidding and auction service is not in scope for a "Bring Your Own Server" model.

# Infrastructure for FLEDGE services

These service proposals present privacy-focused cloud-based services, rather than services which run on-device.

There are several entities that interact so that the FLEDGE services can perform their tasks.

• Clients (Android devices and the Chrome browser) send encrypted requests to the FLEDGE service.
• A cloud platform, hosts FLEDGE services in virtual machines backed by a trusted execution environment (TEE), which prevents FLEDGE services from sharing information with third-parties.
• Key management systems include services and databases that generate and distribute public and private keys to ensure end-to-end encryption of client-service communication.

# Privacy and security considerations

In the proposed architecture for FLEDGE services, we've made several decisions to ensure the infrastructure is privacy-preserving and secure.

Adtechs operate these services in trusted execution environments (TEEs) running on a cloud provider with the required security features.

There are a number of mechanisms to ensure data is kept private and secure, including:

• End to end encryption of all client-service and service-to-service communication.
• Key management system operated by trusted parties.
• The FLEDGE service is attested before that can obtain access to private keys required for decrypting client requests.

Sensitive data will not be exfiltrated from any service, either by adtech, Google, or any other entity.

# Bring Your Own Server to TEE migration

FLEDGE for Chrome currently allows a "Bring Your Own Server" (BYOS) model for the Key/Value service, which will need to be migrated to TEEs in the future. The BYOS model is not in scope for Bidding and Auction services.

To ease the migration from the BYOS model, we're providing new open source APIs, documentation, server implementation, and explainers for the FLEDGE Key/Value service with additional capabilities beyond those already proposed. These APIs intend to allow custom scripts and custom code by adtechs, which can be run on TEEs.

Chrome and Android will be open sourcing a Key/Value service so that adtech platforms can monitor development and potentially contribute to the data plane’s codebase.

# Timeline

Adtech platforms who have implemented the BYOS model can consider migrating to a TEE-based Key/Value service implementation while FLEDGE is still in development.

In the long-term, adtechs will need to use the open source FLEDGE Key/Value services running in trusted execution environments (TEEs) for retrieving real-time data. To ensure that the ecosystem has sufficient time to test, we don’t expect to require the use of the open-source Key/Value services or TEEs until sometime after third-party cookie deprecation. We will provide substantial notice for developers to begin testing and adoption before this transition takes place.

Further, we're aiming to provide user-defined function API and other integrations for the Key/Value service by mid-2023. Once that is ready, adtechs can develop more advanced logic. We welcome your contributions to make this implementation better and best meet your needs.

# Engage and share feedback

The Privacy Sandbox is a collaboration between Chrome and Android to provide technologies that protect user privacy and give companies and developers the tools they need to leverage interest-based advertising.

To learn more about the Privacy Sandbox initiative:

• GitHub:
  • Read the FLEDGE services proposal, raise questions, and follow the discussions.
  • Read the Bidding and auction service proposal, raise questions and follow discussions. In particular, we’re interested in hearing from participants of the ads relevance and measurement origin trial. What do you think of this proposal as compared to the current on-device design?
• W3C: Discuss industry use cases in the Improving Web Advertising Business Group, and discuss FLEDGE design in the Web Platform Incubation Community Group's FLEDGE GitHub repository and regular calls.
• Developer support: Ask questions and join discussions in:
  • Chrome's Privacy Sandbox Developer Support repository
  • Privacy Sandbox on Android issue tracker
• Chrome: Learn more about the FLEDGE API on Chrome.
• Android: Read the FLEDGE on Android design proposal and learn more about how to build FLEDGE in your Android projects.