Stay organized with collections Save and categorize content based on your preferences.
Update: FLEDGE has been renamed to Protected Audience API. To learn more about the name change, see the blog post.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?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 servicesFLEDGE 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 serviceAdtechs 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:
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 Note: This is a brand new proposal under discussion, and the current on-device bidding and auction approach for FLEDGE has not changed. The Bidding and auction service is a complementary proposal to offload bidding and auction computation to a trusted execution environment if and when useful. We want to hear your feedback, and we especially hope to hear from our testers participating in the ads relevance and measurement origin trial.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 servicesThese 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.
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:
Sensitive data will not be exfiltrated from any service, either by adtech, Google, or any other entity.
Bring Your Own Server to TEE migrationFLEDGE 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.
TimelineAdtech 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 feedbackThe 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:
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2022-08-24 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2022-08-24 UTC."],[],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3