Quarterly report for 2025 Q1 summarizing the ecosystem feedback received on Privacy Sandbox proposals and Chrome's response.
Google has prepared this quarterly report as part of its Commitments to the Competition and Markets Authority ('CMA') under paragraphs 12, 17(c)(ii) and 32(a). This report covers Google's progress on the Privacy Sandbox proposals; updated timing expectations; substantive explanations of how Google has taken into account observations made by third parties; and a summary of interactions between Google and the CMA, including feedback from the CMA and Google’s approach to addressing the feedback.
Google has been keeping the CMA updated on progress with the Privacy Sandbox proposals in its regular Status Meetings scheduled in accordance with paragraph 17(b) of the Commitments. Additionally, the team maintains the developer documentation which provides overviews for the core private advertising features and cookie changes, along with API implementation and status information. Key updates are shared on the developer blog along with targeted updates shared to the individual developer mailing lists.
Glossary of acronyms
- ARA
- Attribution Reporting API
- CHIPS
- Cookies Having Independent Partitioned State
- DSP
- Demand-side Platform
- FedCM
- Federated Credential Management
- IAB
- Interactive Advertising Bureau
- IDP
- Identity Provider
- IETF
- Internet Engineering Task Force
- IP
- Internet Protocol address
- openRTB
- Real-time bidding
- OT
- Origin Trial
- PA API
- Protected Audience API (formerly FLEDGE)
- PatCG
- Private Advertising Technology Community Group
- RP
- Relying Party
- RWS
- Related Website Sets (formerly First-Party Sets)
- SSP
- Supply-side Platform
- UA
- User Agent string
- UA-CH
- User-Agent Client Hints
- W3C
- World Wide Web Consortium
- WIPB
- Willful IP Blindness
General feedback, no specific API/Technology
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| User Choice | It is unclear what Google's updated approach to elevate user choice will look like, how it will be presented to users, and the anticipated opt-in/opt-out rates. Further information is required to distinguish this from third-party cookie deprecation. | In April 2025, Google published a blog post on Next steps for Privacy Sandbox and tracking protections on Chrome, announcing that Google has made a decision to maintain the current approach to offering users third-party cookies in Chrome, and will not be rolling out a new standalone prompt for third-party cookies. We will provide further updates as available. |
| Fingerprinting | Google has shared no information with publishers or marketers about how they can rely on any alternatives to Google's Ad Systems without using more risky consumer identity as a common match key (ie fingerprinting). | We've highlighted several, non-Google Ad Systems that are offering solutions to publishers and marketers which are built in part on Privacy Sandbox APIs. This includes non-Google Ad Systems across markets and channels. Further details and case studies are available in the Business Resources section of privacysandbox.com here. |
| Privacy Sandbox | The Privacy Sandbox APIs would replace internet data ingredients with Google's own finished products. Since Google's alternative is an API, it is offering access to a product that it owns and controls, and one that is subject to terms and conditions that Google has discretion over. That is not a substitute for components that are used by others to make their own finished products. | The Privacy Sandbox APIs have been developed and implemented following extensive engagement with regulators and a wide range of ecosystem stakeholders. As with other platform technologies, Privacy Sandbox APIs must take into consideration that they will be used as components in others' finished products and we welcome ecosystem efforts to develop additional technologies to work alongside the Privacy Sandbox APIs. |
| User Choice | Request for information on whether Google's updated approach to 3PCs on Chrome will meet certain regulatory requirements, which may impact stakeholders consent management platform experience. | In April 2025, Google published a blog post on Next steps for Privacy Sandbox and tracking protections on Chrome, announcing that Google has made a decision to maintain the current approach to offering users third-party cookies in Chrome, and will not be rolling out a new standalone prompt for third-party cookies. We will provide further updates as available. |
| Privacy Sandbox Timeline & Adoption | Ad techs have paused Privacy Sandbox API testing and are seeking stronger reasons to reinvest in these technologies for product and marketing activities. Their reinvestment decisions are heavily influenced by the need for greater clarity on the User Choice timeline, as well as concerns around Protected Audience API (PA API) latency and the B&A roadmap. Additionally, there are concerns about the upcoming CMA Commitments review, particularly regarding Google's role as the primary driver of Privacy Sandbox technologies without relying on 3P identifiers, and the overall future direction of the initiative to inform investment strategies. | In April 2025, Google published a blog post on Next steps for Privacy Sandbox and tracking protections on Chrome, announcing that Google has made a decision to maintain the current approach to offering users third-party cookies in Chrome, and will not be rolling out a new standalone prompt for third-party cookies. We will provide further updates as available. Chrome PA API auctions are 35% faster year-over-year. On top of that, we've seen a significant increase in usage of parallelized auctions, which provides an even larger win for those auctions. Our current B&A roadmap is available here. |
| Privacy Sandbox Timeline | What was updated in the Privacy Sandbox Timeline page? | An overview for the Topics API was recently added to the Privacy Sandbox Timeline page. |
| Privacy Sandbox | Are there any research papers on Privacy vs. Utility to help understand the impact of Privacy Sandbox on revenue? | Relevant Market Case Studies which address these questions are available here and results from Privacy Sandbox APIs testing are available here. |
| Privacy Sandbox Adoption | An early adopter reported initial challenges with the Privacy Sandbox APIs due to slow adoption by larger companies, impacting test launches. However despite this, the Privacy Sandbox team's collaborative approach and responsiveness to feedback was appreciated. | We appreciate the early adopter's feedback. We are committed to collaborating with early adopters and we will continue to engage with the ecosystem and gather feedback as we evaluate the role of the Privacy Sandbox technologies in supporting the ecosystem. |
| Chrome Testing | Concern over the ability to continue Privacy Sandbox testing effectively after the removal of testing labels highlighting significant difference in traffic quality between Chrome with 3PCs disabled (Mode B) and users who have personally disabled 3PC in Chrome settings. | Our response is similar to previous quarters: The Privacy Sandbox team understands that companies would like to continue using the cookie deprecation labels. The process to extend the availability of the labels is similar to extending an origin trial. Support for the labels has been extended on several occasions. We envisage proposing further extending support for cookie deprecation labels and will share updates on blink-dev as available. |
Enrollment & Attestation
No feedback received this quarter.
Show Relevant Content & Ads
Topics
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Opting In/Out | Will Google's confirmation that Google Search will not use a site's decision to opt-out of the Topics API as a ranking signal restrict Google from using a site's decision to opt-in to the Topics API as a ranking signal? | Our response is similar to previous quarters: The Privacy Sandbox team has not coordinated or requested from the Search organization that they use page ranking as an incentive for websites to adopt the Topics API. Google Search will not use a site's decision to support (or not support) the Topics API as a ranking signal. |
| Usage Observability | Requesting an observability mechanism for an SSP or general ad tech to be able to see if their implementation of the Topics API is being used on the web. | We are evaluating support for this functionality, and we welcome additional feedback from the ecosystem if this feature is a high priority. |
| Privacy | Questions about consent and re-identification potential. | We are currently discussing this issue here and welcome additional feedback. |
Protected Audience API
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| PA API & GAM/AdX | Google will not send any GAM/AdX demand to a publisher who wishes to rely on a rival publisher ad server. Google should enable rival publishers to choose alternative top-level PA API auction sellers to control the final auction. Information from PA API will be available to GAM but restricted for rival SSPs. As a result, publishers are not able to compare the performance of PA API sourced demand in GAM, such as from AdX or from SSPs integrated into PA API. | Chrome Response: The PA API standard is designed to be flexible and allows different parties to run the top-level auction. This choice depends on the specific implementations and capabilities offered by the publisher's ad server (whether GAM or another) and other participating companies in the ecosystem. The PA API's privacy-centric design limits granular reporting for all participants consistently. The specific data reported from the PA API auction itself is subject to the same API-defined, privacy-preserving rules and limitations for all participants, including any SSPs. Publishers use the PA API's aggregate, privacy-preserving reports to evaluate performance. This allows assessment of the overall contribution of demand sourced via PA API and enables comparison against other demand channels, consistent with the API's privacy-by-design principles. Response provided by Google Ad Manager: Publishers are not required to use GAM's ad server functionality in order to access AdX demand. In addition, PA API is agnostic to who initiates an auction both in single seller and multi-seller designs. |
| Top Level Seller | The Top-Level Seller (TLS) has access to information that none of the other component sellers have access to, raising concerns about unequal access to information. While any entity can be the TLS, in order to access AdX demand, publishers are required to use GAM as the publisher ad server. This creates an incentive to use GAM as the publisher ad server, creating a competitive advantage for Google. | Chrome Response: The design of PA API does not dictate which entity can act as a TLS. The TLS role requires coordinating the auction and accessing related auction information per the API's structure. Response provided by Google Ad Manager: We have maintained a strong focus on auction fairness for years, including our promise that no price from any of a publisher's non-guaranteed advertising sources, including non-guaranteed line item prices, will be shared with another buyer before they bid in the auction, which we then later reaffirmed in our commitments to the French Competition Authority. For PA API auctions, we intend to keep our promise and not share the bid of any auction participant with any other auction participant prior to completion of the auction in multi-seller auctions. To be clear, we won't share the price of the contextual auction with any component auction, including our own, as explained in this update. Moreover, we do not use information about component auction configurations, including signals provided by buyers to SSPs, as part of our own auction. Furthermore, as stated above, GAM does not require that publishers use its ad server functionality in order to access AdX demand. Finally, as noted previously in Google's Q2 / Q3 2024 report, Google's buyside platforms – Google Ads (formerly AdWords) and DV360 – do buy impressions from non-Google exchanges, including via the PA API. |
| PA API & GAM/AdX | It is difficult for publishers to understand activating PA API on 100% of inventory as the labelling of the option does not make the purpose clear. For SSPs, whose primary means of accessing inventory is often through a multi-level auction with GAM acting as the TLS, there is effectively no way to conduct tests or monetize via PA API without being subject to GAM. | Chrome Response: The PA API standard defines technical roles (like TLS and component seller) and the auction process, allowing flexibility in which platforms perform these roles. Operational activities—such as configuration, coordination, and agreements—are managed by the implementing parties (publishers, SSPs, TLS providers) to facilitate participation using the PA API framework. Response provided by Google Ad Manager: As described in our Help Center, Ad Manager offers publishers a control to enable testing with non-Google component sellers, such other SSPs, on 100% of a publisher's inventory where the API is available to use (overriding any sampling or throttling that GAM might apply). If a publisher enables this control, then whenever a non-Google component seller provides an auction configuration, GAM will attempt to run a top-level auction with the provided component auction included, provided that the publisher has obtained the necessary user consent to do so. GAM makes it clear to publishers that this control may impact performance, so that the publisher can make an informed decision. |
| Server-side vs. On-device | Server-side solutions, such as Bidding and Auction (B&A), have the potential to solve for traffic-shaping while maintaining privacy. Server-side solutions are the only viable path forward and Google should abandon on-device solutions. | Privacy Sandbox aims to support both server-side (B&A services) and on-device auction solutions, providing options to meet different ad tech needs and use cases. |
| Auction Security | Attacks on PA API bids are fundamentally disqualifying for on-device bidding and auctions, this issue is not considered resolved by stakeholders and they continue to request technical guarantees to ensure PA API bids are not tampered with as well as an exhaustive debug mode to provide real-time incident detection and efficient debugging. | Ensuring PA API auction integrity, including mitigating potential attacks, is a key Privacy Sandbox focus. The API's design incorporates integrity measures, and we welcome further technical discussion on specific concerns. We presented and discussed a detailed list of potential attacks on PA API and our mitigations during the W3C Anti-Fraud Community Group meeting in May 2024. We welcome further discussions and feedback on what potential ‘attacks on PA API bids' are of concern. |
| Cookieless Traffic | Will there be a way to enable PA API only on cookieless traffic for testing or other purposes? | Ad techs can identify whether 3PCs are present or not. This is explained in further detail here. |
| Seat ID | In regards to the Seat ID proposal, seat ID knowledge is essential for most bid requests which brings concern about tying seat ID to creative registration. Furthermore, would it apply only to the "main ad" or also to component ads? | The BuyerAndSellerReportingId proposal addresses the concern about the lack of buyer's Seat ID during creative registration for the main ad. This identifier aims to communicate the buyer's Seat ID to the seller. We are evaluating the support for component ads. |
| Monitoring and Reporting | Feature request for Real-Time Monitoring (RTM) for (1) sending RTM reports for cancelled auctions as well as (2) new browser-populated buckets to make clear what kind of cancellation happened. | RTM does not appear to be a suitable solution for investigating participation rate. RTM is designed, as a low latency monitoring API, to catch critical, sudden, temporary outages. In contrast, participation rate does not require low latency reporting and is not a critical, sudden temporary outage. Concerns about participation rates are most effectively answered by the sellers with whom buyers collaborate, and not by buyers investigating via the browser. Moreover, as cancelled auctions are extremely common, if the browser would generate RTM reports from each cancelled auction, it could drown out RTM reports for actual outages. |
| Documentation Clarification |
Report of a documentation discrepancy in the PA API explainer that states that the nonce should be a UUID string, but it actually returns a promise. | A clarification is proposed here. |
| Frozen Context |
When working with frozen-context, what options are available to address issues and challenges related to (1) bundling, (2) external libraries, and (3) unsupported data types? | We have provided a response to this question here. |
| Specs | The Private Aggregation API added a generic contributeToHistogramOnEvent operation. As a consequence, the definition in PA API became an overloaded operation, and Web IDL operations "must not be overloaded across interface, partial interface [...]", so that definition is now invalid. | This issue points out a temporary inconsistency between the PA API and Private Aggregation specs while we merge similar changes in both. We have merged a pull request to address this. |
| Interest Groups | Request for guidance on the recommended and resource-efficient method for ending an Interest Group's (IG's) bidding participation when a campaign stops. | Here are some suggestions we can provide: We believe the lowest latency, least permanent, but also least resource releasing mechanism is using the real-time bidding signals to inform their generateBid() to stop bidding. The second option that uses fewer resources would be setting a negative priority for that IG in the real-time bidding signals response, as this would stop generateBid() from even getting invoked. The third option, that uses even fewer resources, would be removing the ads from the IG. IGs without ads don't have their generateBid() invoked. The fourth option, that uses even fewer resources, would be removing the biddingLogicURL from the IG. At this point the IG can still be updated/rejoined so as to reactivate it. Further options revolve around leaving the IG, either via leaveAdInterestGroup() or clearOriginJoinedAdInterestGroups() or via the IG expiring.As highlighted above, different options have different latency implications and resource consumption. Ad techs can pick the option that has the best tradeoff for their specific use cases. |
| Audiences | Request for a mechanism to run logical operations on audiences built (e.g. ability to target an intersection of IG A & B) | With PA API, running logical operations on audiences from the same site is achievable today. Logical operations of audiences across different sites are not supported today for privacy considerations as explained in our privacy model. We are continuing to conduct research in this area and will share any updates along the way. |
| Feature Request | Proposal to remove restriction on additional bids requiring the TLS to be known in advance. | We are currently discussing this proposal here and welcome additional feedback. |
| Updated approach to 3PCs on Chrome | Will Privacy Sandbox APIs such as PA API remain generally available to all Chrome Stable users, or would the APIs (or a subset of APIs) only be available to users who have declined 3PCs? | We do not intend for a user's decision to decline 3PCs to have an impact on the availability of the Privacy Sandbox APIs in Chrome Stable. |
| Enhanced Signaling | Are there any plans to add functionality that indicates whether the TLS intends to run a PA API auction? | We are evaluating support for this functionality. We will share further details on timing when available and we welcome additional feedback on this request. |
| Deal ID | Concern that the KV server requirement in the Deal ID proposal may be an expensive and time-consuming server-side process. | The Deal ID proposal allows SSPs to query metadata of the selected deal IDs from the key-value server during PA auctions, so that they don't need to preload all deal-related metadata onto the device. This proposal is being developed in response to requests from SSPs, and we welcome additional ecosystem feedback here. We understand that there's work required to set up the key-value server, but overall still think this is a net benefit for ad tech companies. We continue to welcome feedback and suggestions on making this process easier. |
| Cross-IG Frequency Capping | Request for cross-IG frequency capping via PA API. | Cross-IG frequency capping has challenging privacy characteristics that we've been unable to find solutions for. We welcome additional feedback from the ecosystem if this feature is a high priority. |
| Deal IDs & Seat IDs Reporting | Requesting ability to get deal or seat IDs into aggregate reporting. | The reporting ID functionalities we are working on here will make the reporting of deal and seat IDs possible. selectedBuyerAndSellerReportingId is provided to reportResult(), so the easiest way to report it would be via event-level reporting (i.e. encoding the Deal ID into the URL passed to sendReportTo()). If aggregated reporting were to be used, that can also be done. The reporting ID feature is currently live for 10% of Chrome Stable channel traffic. We are evaluating expanding the launch to 100%. |
| Interest Groups | Use the same order of priority in both IG selection and evaluation and use that order of priority in all evaluation modes. | We are currently discussing this here and welcome additional feedback. |
| Interest Groups | Suggestion to use audience activation and delegation as ways to increase Privacy Sandbox API adoption. | We are aware of this request from multiple stakeholders and are researching a solution. We welcome additional feedback from the ecosystem. |
| Interest Groups | Challenges around creating PA API IGs, specifically around delegation and ownership when acting for multiple buys or on behalf of publishers. | We have received the request to support more advanced IG delegations from multiple stakeholders, and we see the added value of SSPs contributing to this process. We are conducting research to find the best solution that allows different parties to participate in the audience extension process. We welcome additional feedback from the ecosystem. |
| Client-side Performance | Request for guidance on easing client-side caching of trustedBiddingSignals to optimize infracost and latency. | We are currently discussing this here and welcome additional feedback. |
Protected Auction (B&A Services)
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| K/V Services | How are requests from the browser to the seller's KV server batched? For a seller, what will the request from the browser look like - a GET or POST request? Additionally some clarification is needed around k-anonymity requirements. | For v1, Chrome sends a GET request to the Seller's KV service to fetch trustedScoringSignalsURL with the signals in the query parameters of the request. The parameters would include the hostname, renderUrls, adComponentRenderUrls, and experimentGroupId. We are currently experimenting with some extensions for sending additional information for creative scanning, but that has not yet launched. When setting maxTrustedScoringSignalsURLLength to 0 then Chrome could potentially batch all of the signals into a single request (possibly exceeding any URL length limit on their server), but it's not guaranteed. Chrome currently chooses to include requests in the same batch if they are ready to be sent within 10ms of each other, though we are currently investigating how to optimize this.When working with trustedScoringSignals, it's useful to remember that Chrome respects caching headers. Headers like the Stale-While-Revalidate "Cache-Control" header could reduce the average latency by allowing Chrome to use the cached copy (and update the cache for the next auction), effectively removing the signals fetch from the critical path.Finally, regarding k-anonymity, the particular section of the explainer seems to be outdated. Originally we were going to require the trusted signals URLs to be k-anonymous, but that requirement was dropped. We will remove this sentence from the explainer. |
| B&A Services | Upgrading to the latest version of B&A takes a long time. Faster build times or pre-built images would be beneficial. | Ad techs can build the binaries on their own and validate using the provided hashes. We will consider investigating the possibility of providing pre-built artifacts or improving build times in the future. |
| API Feature Request | Request for macOS compatibility for Bidding & Auction Services (B&A) build scripts, container images, and invocation tools to facilitate local development and testing. | We currently support amd64 which is sufficient for deployment to the supported cloud platforms (GCP & AWS). We may investigate support for other architectures in the future. |
| AWS | Is having IAM roles created a requirement for production builds? | Yes, IAM roles are required for proper permissions and communication with Coordinators. The keys are used to decrypt the ProtectedAudienceInput ciphertext that is generated on device as set out here. Additionally, these roles are required to pass server/TEE attestation of production builds with those same Coordinators. This is addressed in further detail in our self-serve guide. |
| B&A Flags | Requesting definitions of available B&A flags to be listed in documentation given that today these definitions reside in the Terraform code, cc files and proto files but ad techs would benefit from documentation on these flags leveraging it as a source of truth for understanding how to customize deployments. | We are investigating the possibility of documenting the Terraform flags descriptions and welcome additional feedback here. |
| AWS Bidding Service |
Seeking guidance regarding bidding service on AWS and default logging behavior and configuration. | For debugging your bidding services within the TEE (such as Bidding service), we recommend using Ad Tech consented debugging. This allows you to enable detailed logging and capture request/response data for your specific test requests directly from your client to help with debugging. |
| TEE K/V Documentation |
Requesting clarification regarding the beginning of TKV enforcement as stated on the dev site. | We will provide sufficient notice in advance of requiring the use of TEEs. Until then, you can continue to use your own server for real-time key/value signals. |
| B&A Testing & Analysis | B&A analysis and testing remains costly and does not seem production-ready. | We'd need more information on the cost analysis and the factors leading to the assessment of production-readiness in order to look into it further. |
| Trusted Server Optimization | Proposal to merge parameters specific to component sellers into one inputsPerSeller parameter, using a JSON string for its value. | We are discussing this proposal and welcome additional feedback here. |
| Security | How are security risks from TKV mitigated by using B&A? | Preventing external calls to TKV is possible. This is fully supported and configurable on GCP today. For AWS, additional support needs to be developed due to the deprecation of AWS App Mesh, which previously enabled this. We welcome additional feedback here. |
| B&A Services | Requesting clarity on the narrative/comms regarding the value of HTTP Streaming for B&A optimization. | Privacy Sandbox supports streaming capabilities in transferring B&A data to improve latency for ad techs who choose to use it. It is optional performance optimization in case of mixed mode. |
| Prebid | Request for updates on contributing to the open source Prebid library to enable PA API B&A features for the ecosystem. | In March 2025, Chrome launched the Prebid-preferred optimization in stable as documented in the B&A public roadmap (see March 2025). |
| Traffic Shaping | Request for mechanisms to log contextual signals received by B&A to better understand when IGs are being activated and improve their "intent to bid" logic in contextual response. This enables better usage of network resources to avoid "useless traffic" (a.k.a. traffic shaping). | We are currently discussing a proposal here and welcome additional feedback. |
| Documentation Clarification |
Clarification needed regarding ‘Service/Vsock proxy is not reachable' error spotted at B&A test integration setup. | This is due to minimum memory requirements.The AWS configuration explainer has been updated to reflect this requirement. |
Measuring Digital Ads
Attribution Reporting (and other APIs)
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Real-Time Data | The lack of real-time data impacts everyone in the industry. Delaying real-time data is a serious problem for advertisers, buyers move to platforms that have Google Analytics as it is the only place they can get proof of reaching audiences. | The real-time data delays that are part of the Attribution Reporting API (ARA) are implemented as privacy-protection mechanisms to reduce the ability of ad techs to use event-level reports to track users across sites. However, ARA provides flexibility in how attribution reports are delivered, by allowing event-level reports to have a minimum report window of 1 hour and by allowing Aggregate Reports to have an option of being sent instantly to ad techs with no delay. |
| API Usage | Request for confirmation regarding the correct configuration for a Cross Web App attribution flow, specifically when operating web-to-web and web-to-app attribution in parallel. | When running web-to-web and web-to-app campaigns in parallel, the ad tech should choose only one platform to register each source or trigger, in order to prevent double counting. We strongly recommend using the Operating System (OS) where possible, as the OS has the ability to perform both web-to-web and web-to-app attribution, as long as the web sources and triggers have been correctly delegated. This would mean responding with the Attribution-Reporting-Register-OS-Source header for sources and Attribution-Reporting-Register-OS-Trigger header for triggers. The Attribution-Reporting-Support header can be used to identify whether there is Chrome and/or Android-level support. The Attribution-Reporting-Info header is useful when there is no Attribution-Reporting-Support header in the request, in which case the browser will make the platform registration decision based on the availability of the platform support on the user's device. |
| API Spec | Seeking clarification about the Attribution-Reporting-Support HTTP request header set by the Attribution Reporting API and whether it is intended for the header to contain both web and os keys, regardless of the platform. | The Attribution-Reporting-Support header is subject to the browser adding "GREASE" parameters, to ensure that servers use a spec-compliant structured header parser. For this header, only structured-dictionary keys should be interpreted. The values and parameters are currently unused. See here for an example. |
| 3PC-based reporting | Requesting guidance on how to troubleshoot discrepancies in measurement between ARA and 3PC in ads campaigns. | ARA supports two types of debug reports that can be used to troubleshoot and debug discrepancies. Attribution-success debug reports can be used to easily compare ARA results against results from other measurement technologies, and Verbose debug reports can be used to receive more information and troubleshoot potential issues in the attribution registrations. |
| API Usage | While testing ARA certain issues were discovered: insufficient granular reporting leading to noisy data and inflexible campaign optimization, high thresholds excluding smaller advertisers, and difficulty comparing campaigns due to inconsistent Key Performance Indicators. | ARA provides flexibility by providing multiple parameters that ad techs can customize to achieve their specific measurement use cases. Event-Level Reports support flexible event-level reporting which allows ad techs to customize their reporting windows, the number of reports they can receive, and the trigger data they want to measure, which can change the impact of noise on their data and allow them to achieve different use cases. Similarly, Aggregate Reports have different ways ad techs can customize their configurations such as the number of dimensions they track, their batching frequency, and their use of contribution budget to change the impact of noise and achieve different use cases as well. |
| API Spec | Question about the dependency of ARA on 3PCs, specifically regarding whether it remains in a testing phase requiring these 3PCs. | ARA is enabled independent of 3PCs, but 3PCs need to be enabled to allow ARA transitional debug reporting to compare ARA results with cookie-based attribution results. |
| API Usage | Inquiry about registering sources for app-to-web attribution on older Android versions (11, 12, and 13) using ARA. | ARA is currently supported on Android S and above (12+). |
| API Usage | Request for ARA opt-in rates and distribution details. | Our response is unchanged from previous quarters: "We have no plans to share this information with the ecosystem. Developers are welcome to call the APIs where they have code deployed today to estimate availability of the Privacy Sandbox APIs" |
| API Availability | When ARA is enabled, are 3PCs enabled or disabled? | When ARA is enabled on the users' browser, it does not have any effect on the users' cookie settings. It is possible for ARA to be enabled and for the user to have cookies either enabled or disabled. |
| Reporting | Is there a predefined list of values we can receive in the "Attribution-reporting-support" header? | As set out in our guidance, the value is a structured header dictionary, whose only currently defined semantics is the presence or absence of the OS and web keys. All other parts of the header should be ignored. In other words, parsing requires using a structured header parser, not simple string matching. |
Aggregation Service
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Feature Request | Feature requests for Aggregation Service: Server-to-Server integrations, Cross-device measurement, Ease multi-touch attribution and contribution reporting, omnichannel attribution, and support for advanced ML optimization loops (e.g., Private Model Training). |
We are evaluating these requests and will share further details when available. We welcome additional feedback from the ecosystem on whether these requests are a priority. |
| Feature Request | Request to set the EBS delete_on_termination parameter to True in the terraform environment, in order to mitigate concerns about the reset when updating the aggregation serviceset. | We are evaluating this request and will share further details when available. We welcome additional feedback from the ecosystem on whether this request is a priority here. |
| Documentation Clarification |
Requesting guidance about what can be changed (e.g. monitoring thresholds) and what should stay untouched. | We are evaluating publishing additional documentation and guidance on the available customizations for the aggregation service. |
| Deployment | Request for clarification regarding new deployment failing at bazel command. | Deployment failing can happen due to the bazel version used in the environment. Documentation will be adjusted to cover debugging on Terraform failures as well as indicating the required bazel version. |
Private Aggregation API
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| API Usage | Request for guidance on some implementation challenges such as potential data loss due to reported Shared Storage limitations, difficulties with high cardinality requiring complex Aggregation Service allowlists (wildcard suggested), and slowed testing caused by the Aggregation Service's "no duplicates" rule. | Concerning the Shared Storage limitations, the 20 contributions limit (detailed here) is per execution, not per month. Additionally, API callers can override this limit. The limit is in place to help manage the cost of processing reports in the aggregation service and not to limit the reporting utility. Concerning wildcard queries, we are evaluating this request and will share further details when available. Concerning the "no duplicates" rule, in order to enable testing, we temporarily support debug mode for the purpose of bypassing this rule. This is set out here in more detail. |
| Filtering ID & Buckets | Is it possible to request to the aggregation service the same bucket with two different filtering IDs in two separate aggregation runs, i.e., can the filtering ID act as a supplementary partitioning of domains? | Yes, this feature is supported. When performing an aggregation, only contributions with a filtering ID matching the list in the job parameters will be processed, and the rest will remain available to process in separate run(s). |
| Multi-touch attribution | Requests for clarification regarding Multi-Touch Attribution (MTA) implementation: 1) Is there a limit to the number of contributions if the aggregation value does not exceed 2^16? 2) Is there a limit to the number of unique aggregation keys (buckets) that can be stored for a given context? 3) How does the Aggregation Service process summary reports when each user agent (browser) has a unique aggregation key, as is likely in MTA? |
1) We have put in place default contribution limits, but there are options for the API caller to override them as explained here. The purpose of the limits is to help API callers manage the cost of processing reports in the aggregation service. 2) There is no such limit, although ad techs should consider the granularity of the aggregation keys to improve signal-to-noise ratio, as further explained here. 3) Please see this guidance, especially the signal-to-noise guidance addressed above under item 2). |
Limit Covert Tracking
User-Agent Reduction/User-Agent Client Hints
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Feature Request | Request to add Sec-CH-UA-Robot to User-Agent Client Hints (UA-CH) as it would allow servers to identify automated traffic for content adaptation, security, and analytics. | This is an important use case that is being discussed in other standards groups (see here for further details), and we would recommend interested parties to participate by providing their feedback. However, we consider that UA-CH might not be the appropriate solution, given that HTTP request headers can be easily manipulated by automated traffic. |
IP Protection (formerly Gnatcatcher)
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| IP Address Privacy | Leaving IP addresses available for Google to use contradicts its stated privacy goals. Even though Google says that it anonymises data through IP Protection, users must be logged in to Chrome to use IP Protection, so Google still learns their identities. | The reasons for login are for anti-fraud and abuse purposes, primarily rate-limiting access to the proxies. Furthermore, to protect users' privacy in the context of the authentication requirement, our token design is blind-signed meaning the token issued during login is different from the token that is used during the proxying therefore the tokens issued cannot be linked to a user's Google identity later on. This means Google does not know who the user is when that user's traffic is proxied in incognito mode, despite the authentication requirement for anti-fraud reasons. |
| IP Address Privacy | The use of IPs is a step in the wrong direction. They cannot be deleted from the browser, like cookies, and users don't have the same transparency controls as they do with cookies. If cookies go away, the industry will move to using IPs as an alternative solution, prioritising self-preservation over privacy. | As a platform, Chrome aims to provide users with features that improve their browsing experience on the web. For Chrome users who choose to browse in Incognito, that means providing enhanced protections against cross-site tracking by limiting the availability of IP address information in third-party contexts. |
| Masked Domain List | What is the selection criteria on the Masked Domain List (MDL)? | Chrome developed criteria to identify which domains should be on the MDL and therefore receive masked IP addresses in a third-party context. Google has partnered with Disconnect.me, a prominent internet privacy leader who also collaborates with other web browsers. Chrome will leverage Disconnect.me to identify domains that align with Chrome's established criteria. Additionally, Chrome has developed a methodology to identify widely used JavaScript functions that provide consistent outputs from stable and high-entropy web APIs and can therefore be used to construct high entropy probabilistic identifiers. These functions are then detected when they are loaded on websites in a third-party context, resulting in a list of domains that serve scripts with these characteristics that become part of the MDL and are therefore proxied. The detection pipeline that looks for these patterns of API misuse considers all domains, including Google's own domains. |
| Fraud Prevention | Feedback on Probabilistic Reveal Tokens (PRTs) that the proposed 24-hr reveal delay and reveal rates impede real-time fraud detection. Request for shorter delays (1-hr delay) and higher rates (at least double-digits). Further suggestions involve enabling differential rates based on risk signals (VPNs, automated browsers), and allowing targeted reveals of specific tokens. | Most developers we talked to provide hourly reporting to their customers, and several update IP blocklists throughout the day. A shorter delay period enables more frequent updates, and under an hour, would re-enable IVT measurement in hourly stats, but it also potentially increases the likelihood of re-identifiability of users. We are open to exploring reducing the delay periods and changing the reveal rate based on ecosystem studies, and feedback from stakeholders and welcome additional feedback here. |
| Masked Domain List | Question regarding domain's inclusion on the MDL despite not having an advertising use case. Concern that this could enable "IP-bridging" to create profiles based on IP addresses. | We recognize the importance of implementing an appeals process for our list-based approach. Appeals permit companies to make a claim that their domain on the MDL does not meet the inclusion criteria and ought to be removed, thereby allowing that domain to continue to receive users' original IP addresses in a third-party context in Incognito mode. We have now launched the appeals process to provide domain owners sufficient time to seek an appeal and receive a decision prior to the launch of IP Protection in Incognito mode in Chrome Stable. Further details regarding the appeals process are available here. |
| Masked Domain List | Feedback that publishers are investigating the implications of their partners being included in the MDL. They were reassured by the GeoIP provisions within the IP Protection Explainer. | Chrome recognizes the importance of supporting geo-based use cases. The proxy will assign IP addresses that represent the user's coarse location, including country. Further information is available in the IP Geolocation Explainer. |
| Masked Domain List | Question regarding the MDL whether or not country-level targeting is still available. | Chrome recognizes the importance of supporting geo-based use cases. The proxy will assign IP addresses that represent the user's coarse location, including country. Further information is available in the IP Geolocation Explainer. |
| Fraud Detection | Concerns about impact of IP Protection on fraud detection systems. Will users see proxy IPs or a header? Will SSPs and DSPs see the same proxy IP address for a given use? Inconsistencies could affect fraud detection and OpenRTB. | Users browsing in Incognito mode with IP Protection enabled that make requests to domains on the MDL will receive a proxy IP address based on a defined geofeed. Organisations may request PRTs to be passed as an additional header on proxied traffic, where a small sample of original IPs can be revealed after a delay period. We suspect many SSPs will pass their proxied IP address in server-side bid requests to their demand partners, but winning DSPs are not guaranteed to see the same proxy IP address at impression time. |
| Fraud Detection | Questions about the update frequency of the IP geolocation file, the update timing for details on reporting fraudulent behavior and PRTs, and how ad tech should detect fraudulent activities. | The PRTs explainer is live, as is the list of proxy IP addresses and their mapped geo regions. We recommend periodically checking this file for updates and changes, as IP addresses will rotate over time. The public email address to report abuse will be announced closer to launch. |
| Geolocation | Request for public list of IP addresses used for proxies. | The file mapping IP addresses to rough locations for IP Protection is available here. Please note that this file is updated periodically. |
| API Usage | Assertion that IP Protection seems to be on by default and users are not given the option of opting out. | IP Protection will be available for users in Chrome's Incognito mode, on Android and Desktop platforms. Users will have the ability to disable IP Protection. For enterprise-managed versions of Chrome, IP Protection can be enabled, but it will be off by default. |
| API Usage | Query regarding the availability of an experiment flag to enable and test IP Protection in Chrome Canary and Beta releases. | Currently, we do not have an experiment flag available to test the full IP Protection feature. The functional experiments we are conducting only proxy traffic going to Google domains. |
| IP Address Privacy | How do 3PC prompt settings work when a browser moves into Incognito mode? | 3PCs are blocked by default in Incognito mode. |
| Incognito Mode | Seeking clarification on whether IP Protection functions in Incognito mode when the user is not signed into Chrome. | IP Protection is not active if the user has not logged in to Chrome ahead of launching Incognito mode. The reasons for this are for anti-fraud and abuse purposes, namely rate-limiting access to the proxies. IP Protection will use client authentication to limit the ability of bad actors to leverage the proxies to amplify attacks on services on the MDL. Therefore, IP Protection will only be available to users that have been authenticated using the Google account they're signed in with in the Chrome browser prior to opening a new Incognito window. |
| Incognito Mode | Requests to assess impact of IP Protection ahead of launch, including: (1) Proposal to use a browser state flag or aggregate API reporting to quantify Incognito mode usage; (2) Sending an IP Protection header for a period before enabling the feature; and (3) Shipping the feature to a small, known percentage of traffic for extrapolation. |
We understand the ecosystem's interest in being able to understand and measure the scale and impact of IP Protection. However, Chrome works towards making a user's choice to browse in Incognito mode private. Chrome does not expose a method to detect users browsing Incognito, and has taken steps to limit other signals that may reveal the user's browsing mode. We are considering ways to facilitate this testing without impacting the privacy of users browsing in Incognito mode and welcome additional feedback from the ecosystem. |
Bounce Tracking Mitigations
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Compliance | Google's unwillingness to authorise use of the Bounce Tracking Mitigations (BTM) technique that is compliant with data protection legislation has no legal basis and renders the Privacy Sandbox appeals process meaningless. | As we explained in our previous feedback report, compliance status has no relation to the application of BTM and Google does not make any decisions regarding compliance in implementing BTM. BTM, like other Chrome privacy protections, is instead focused on furthering users' control over whether and how their data is shared. The third-party managed appeals process referenced in the CMA's Q2/Q3 Report is specific to areas where Google is making decisions about individual companies' inclusion or exclusion in lists. |
| Compliance | Discussion about how browsers ensure compliance with legally consented actions in the context of GDPR highlighting scenarios where browsers might suppress actions (like redirects or cookie setting) that users have explicitly consented to, creating a conflict between legal consent and browser privacy settings. | The browser does not have visibility into the nature of the relationship between a user and a website. Additionally, with current BTM behavior, there already exist workarounds for a user to give explicit consent to bounce tracking from a given site. Further information regarding compliance is available in our Privacy-related compliance FAQ. |
| Dual-Use Sites | Seeking clarification on whether transitions from WebView or app-to-web (Chrome) will be considered "dual-use sites" under BTM? | The browser does not have visibility into whether a bounce chain began via a transition from WebView or app. Hence, BTM does not give those flows any special treatment. Instead, it interprets the flow as a cross-site bounce beginning from "about:blank" and proceeds with standard behavior. |
Strengthen cross-site privacy boundaries
Related Website Sets (formerly First-Party Sets)
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| API Usage | Concerns about potential for abuse of RWS in conjunction with IP Protection. Exposing IP addresses to organizations within an RWS set could incentivize organizations to join multiple RWS sets to gain access to portable IP Address data for tracking Incognito users. | The set requirements for associated sites, service sites, and sets as a whole, enforced by automated validations, mitigate any potential incentive to attempt joining multiple sets. Joining user activity across sets via IP addresses would require inclusion of an MDL domain in a set, which requires coordination between the set owner and the domain owner. This same risk applies for single sites (i.e. no RWS involved) coordinating with MDL domains. We have responded to this question in further detail here. |
Fenced Frames API
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Native Advertising | Feedback that Fenced Frames, as currently designed, is incompatible with their native advertising business model, which requires ads to flexibly adapt to surrounding content. | We continue our assessment of the ecosystem needs and the current Fenced Frames offering. In any case, as previously stated, Fenced Frames will be required no sooner than 2026. |
Shared Storage API
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| API Bug | Report that Chrome logs an error when the Shared Storage API's budgeting mechanism prevents the selectURL operation from running, even though this is expected behavior. Request that Chrome downgrade the logging level from error to warning or info, as the error is not actionable for the caller. | The change has been implemented and included in Chrome M134, available since 4 March 2025. |
CHIPS
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| API Documentation | Clarification needed regarding the security protections offered by partitioned cookies compared to SameSite=Lax/Strict cookies. Suggestion that the documentation should explicitly state that partitioned cookies do not provide the same level of protection against XSS and CSRF attacks as SameSite=Lax/Strict cookies. | We will update the explainer and specification to clarify the semantics and protections offered by partitioned cookies. |
FedCM
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| UI & Security | Feedback that the FedCM UI is too similar to Google's previous one-tap login, it's hard to quantify FedCM performance due to lack of passive presentation tracking, and a recommendation for stronger documentation language regarding PKCE. | We are actively engaging with stakeholders to address their feedback. Areas of ongoing discussion include ways to provide better metrics to IdPs to allow them to track FedCM performance, and possible enhancements to address new use cases for FedCM around subscription use cases. |
| API Usage | When a user refreshes the page and calls navigator.credentials.get to login, a pop-up window appears, requiring the user to click to continue, which introduces a delay impacting user experience. Could Relying Parties (RPs) cache the token returned by navigator.credentials.get to improve user experience? | RPs can use their own cookies to store the token. RPs can then check their own cookies to determine if a user is logged in before invoking navigator.credentials.get. We have addressed this in further detail here. |
| Multi-IdP Selection | How would the browser display the login options for multiple identity providers (IdPs) in FedCM? | The developer documentation has information on how multiple IdPs would be displayed. Stakeholders can experiment with this functionality by enabling the fedcm-multi-idp flag in chrome://flags. |
| Browsers & IdPs | Is it possible for a browser, such as Chrome, to act as an IdP itself? Browsers could use their stored account and profile data as a trusted source of authentication. | Due to the fact that browsers can be modified (e.g. via extensions), any claims of email verification made directly by the browser cannot be trusted without additional server-based verification. As such, a purely-client-based solution is not recommended. We have discussed this issue in further detail here. |
| API Spec | Discussion around whether the parameter for the IdentityCredential.disconnect() algorithm should be required or optional. | This is now fixed. More details can be found here. |
| API Security | Concerns around token leakage in FedCM login process if a RP has an XSS vulnerability. An Attacker could execute navigator.credentials.get in malicious code to obtain the token. | FedCM does not create new XSS risks; these risks are inherent in web applications and existing auth protocols. To mitigate these risks, RPs should verify the aud claim in ID tokens and only accept assertions issued in their own origin. As discussed here, there are widely established best practices to secure this token exchange that exist today and are available for use with FedCM. Additionally, the Storage Access API can be used with FedCM, and Storage Access API calls are automatically granted when there's a prior FedCM call. This should enable the embedded redirect flow discussed on the GitHub issue. |
| API Spec | The client_metadata_endpoint is a required field in the config endpoint response for FedCM. An empty object is a valid response, and Chromium silently ignores a 404 response, suggesting that the endpoint is treated as optional in practice. | We agree that the specification could be changed to reflect this and make the client_metadata_endpoint an optional field. |
| API Usage | Concerns regarding the difficulty of testing FedCM implementations due to browser-controlled user interfaces that are not accessible through the DOM. | We support the browser automation APIs for regression testing, which may address these concerns. These APIs are documented here. |
| API Spec | The login_url parameter, which is a required part of the response of the config endpoint, was not documented in Section 3.2 of the specification. | We have submitted an update to the documentation to include the login_url parameter in Section 3.2. |
| API spec | Concern around a potential tracking vector in FedCM. An IdP could insert IDs as path parameters into the endpoints specified in the config endpoint response (accounts_endpoint, client_metadata_endpoint) and use these IDs to correlate the account and client metadata requests. | While we do not have evidence of IdPs inserting IDs into these endpoints, we are actively considering mitigations to address this issue here. |
Fight spam and fraud
Private State Token API (and other APIs)
No feedback received this quarter.