Feedback Report - 2025 Q2

Quarterly report for 2025 Q2 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.

Taking into account observations made by third parties

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
Future of Privacy Sandbox In light of the announcement to not proceed with the introduction of a user choice mechanism for 3PCs, some APIs are more useful than others when 3PCs are present and others would need to evolve in order to be useful. There are additional potential areas for investment for Chrome beyond the Privacy Sandbox APIs. We appreciate the feedback and we are continuing to engage with stakeholders in order to evaluate the role the Privacy Sandbox APIs can play going forward, as well as to explore new areas for future investment, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Privacy Sandbox Some ecosystem participants are disappointed by the announcement to not proceed with the introduction of a user choice mechanism for 3PCs, but are proud of the work accomplished, they appreciate the technical challenges within Privacy Sandbox, and have emphasized the value of their collaborative working relationship with Chrome and the utility of the Market Testing Grant. We appreciate the feedback and agree that Chrome can and should collaborate with developers to create technologies that improve online privacy while preserving an ad-supported internet.
Browser Data Sharing Browser-mediated data sharing is a compelling technology with a potential to address market inefficiencies and trust issues. The browser has value as a third-party execution context for collaboration. We appreciate the feedback and agree that Chrome can and should play a role helping developers with creating technologies that enhance trust between collaborating developers and users.
Chrome Traffic What is the share of cookieless traffic on Chrome and the share of traffic for Incognito mode? As noted by the CMA in its "Notice of intention to release commitments", Incognito mode only affects a very small fraction of browsing activity. In each of the UK and the EEA, Chrome Incognito mode represents: less than 10% of navigations on devices running on the Android operating system; and less than 10% of navigations on devices running on the Windows operating system. These metrics refer to navigations only on Chromium-based Chrome in the UK and EEA.
We do not share data about browsers who block 3PCs.
Developers may determine when cookies are partitioned using Storage Access Headers and use available mitigations accordingly.
Chrome Testing Labels What is Chrome's plan for 1% of cookieless traffic that was enabled for testing in 2024? We do not have plans to share at this time, but we intend to share them publicly as soon as available.
Chrome Testing Does the current testing label setup include a treatment for scenarios where both 3PCs are available and Privacy Sandbox APIs are enabled? The current testing label setup includes treatment for both 3PCs and Privacy Sandbox APIs in the form of Mode A.
Privacy Sandbox Some advertisers find Privacy Sandbox APIs complex and are experiencing apathy due to previous readiness exercises, questioning how to quantify the advantage for early adopters, and are looking for education about the effects of retargeting, prospecting and measurement. We appreciate the feedback and understand the sentiments about technological complexity and readiness exercises.
Regarding understanding the performance of the current Privacy Sandbox technologies, our testing results indicated that ecosystem participation is a critical factor in understanding the performance of the Privacy Sandbox solutions. Testing at low volumes could not reproduce the marketplace dynamics and incentives of using the technologies at scale.

Enrollment & Attestation

No feedback received this quarter.

Show Relevant Content & Ads

Topics

Feedback Theme Summary Chrome Response
Performance and Utility Interest in the Topics API with Enhancements Feedback from buy-side stakeholders indicates that the Topics API is a valuable signal and results in Cost per Impression data (CPM) that is competitive with that for 3PC audiences, for advertiser campaigns. Some publishers view the Topics API's signal as being of greater quality than standard open web signals. Given this feedback on the Topics API's utility, stakeholders are requesting enhancements, such as improving taxonomy fidelity, consistency, and expanding publisher controls to drive wider adoption. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Usefulness for
different types of
stakeholders		 Because the Topics classifier currently uses only the page hostname to define the corresponding topics, large sites with diverse content are contributing generic topics while small sites are contributing niche topics with more advertising value. Our response is similar to previous quarters:
As with 3PCs, there is a difference in the value of information contributed by different sites. Niche-interest sites are inconsistent in their value contribution: not all niche-interest sites have commercially-valuable content, and therefore contribute less value. These are the sites which will benefit from the Topics API. We have considered the possibility of page-level rather than site-level classifications, however, there are a number of significant privacy and security concerns with such a classification.
Topics taxonomy not granular enough The Topics API does not provide sufficient granularity for news publishers with diverse content sections within a single domain, potentially limiting the API's usefulness for ad targeting. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Classifier Improvement Allow publishers to give Chrome permissions to classify topics based on page content (e.g., head, body). We are considering this request and welcome additional feedback here.
Policy Request for clarification on the guidelines regarding the use of the Topics API in conjunction with 3PC information. There are no difficulties with using both the Topics API and 3PCs, as the Topics API provides a subset of the functionalities of 3PCs.
Observe-Browse-Topics Header Request for clarification on the implementation of the Observe-Browse-Topics header, specifically whether continuously returning the header would cause issues. Continuously returning the Observe-Browse-Topics: ?1 header will not cause any technical issues.
The browser handles this signal efficiently, simply noting that the page visit is eligible for topic calculation without causing duplication or errors. While not required on every page, sending it as a standard header on all top-level documents is a valid and simple strategy.
Taxonomy Categories Request to update the latest Topics taxonomy with new topics. We are considering this request and welcome additional feedback from the ecosystem here.
Null Values Request for guidance on improving the Topics API's performance and understanding the reasons behind the null responses, such as filtering or sensitivity. For clarity, null or empty responses from the Topics API are an expected privacy feature, not an error.
A null response can be caused by:
• Privacy Rules: A 5% random null chance, or because your script has not "observed" the user on sites related to that topic.
• User State: Insufficient browsing history, use of Incognito mode, or the user has opted out in Chrome's ad privacy settings.
• Technical Errors: Publisher sites must send the Observe-Browse-Topics: ?1 header, and any calling iframes require the allow="Browse-topics" permission.
To investigate, use the chrome://topics-internals debugging page to see what topics your browser has calculated and why.
While the privacy features prevent a 100% fill rate, you can improve performance by:
• Working with Publishers: Ensure your partners correctly send the Observe-Browse-Topics: ?1 header on their sites.
• Verifying Your Code: If you use iframes, confirm the allow="Browse-topics" policy is in place.

Protected Audience API

Feedback Theme Summary Chrome Response
PA API Adoption Hindered by Cost and Complexity Adopters are deprioritizing or rolling back Protected Audience API (PA API) integrations, citing operational costs, a lack of advertiser demand, and low inventory volume from exchanges.
Some feedback included benefits of PA API's potential, such as its ability to deliver durable audiences and superior reach due to a high match rate.		 We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Cross-platform functionality Cross-platform functionality should be supported by utilising PA API across platforms to unlock greater retargeting and audience targeting capabilities. Google should enable Interest Groups (IGs) registered in Chrome to be accessible when serving ads in native environments or within webview, and interest groups registered in Android should be available in Chrome auctions. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
directFromSellerSignals By limiting the amount of information available in the contextual auction, auction participants are always routed through Google's ad server. A publisher must call all of its exchange partners first, then Google Ad Manager (GAM) second to run the contextual auction and finally allow GAM to invoke IG auctions. Without knowing the contextual auction's result in real time, no competitor can fairly orchestrate a top-level decision.

The directFromSellerSignals feature within PA API may lack transparency regarding auction information, potentially hindering the ability to access necessary data. Google should either remove directFromSellerSignals or update it so it cannot be used to hide the ad server's auction clearing price. For example, the contextual price could be passed through Chrome via a transparent, immutable, signed field that all auction participants (and the publisher) can access and verify.		 Our response is unchanged from previous quarters:
Chrome response:
Information passed into runAdAuction() is not known to come from the seller unless the seller calls runAdAuction() from its own iframe. In a multi-seller auction it becomes impossible to have all sellers create the frame calling runAdAuction(). directFromSellerSignals addressed this issue by loading content from a subresource bundle loaded from a seller's origin. This ensures that the authenticity and integrity of information passed into an auction from the seller-auctions configurations cannot be manipulated. If publishers want to use PA API to understand any of the information their technology providers are passing into PA auctions, they can ask those technology providers for this functionality.
Google Ad Manager response:
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 Protected Audience auctions, we intend to keep our promise by leveraging directFromSellerSignals, 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 our own component auction either, as explained in this update.
Reporting Request to add an analytics/reporting entity to enable centralized reporting. We are discussing this request here and welcome additional feedback.
K-Anonymity on buyerReportingId Ability to discard bids based on the k-anonymity of the "buyerReportingId" to facilitate audience curation and reporting obligations with third-party data providers. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Improved Debugging in generateBid Script Requesting a mechanism to rapidly identify the specific stage or "breakpoint" within the generateBid script where the process is failing. We are aware of the desired usage of Real-Time Measurements as a breakpoint-setting mechanism for on-device auctions. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Event Listeners for Monitoring runAdAuction State Proposal to add event listener support to PA API's navigator.runAdAuction function to improve monitoring of the ad auction lifecycle. We are evaluating this request and welcome additional feedback from the ecosystem here.
API Usage Request to clarify how PA API and Attribution Reporting API (ARA) can support web advertising use cases in the absence of 3PCs, particularly for users who have opted out of 3PCs but not out of Privacy Sandbox APIs, and in scenarios involving failed cookie syncs and WebView? We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Latency Latency associated with PA API could hinder adoption, as publishers may choose to disable PA API if latency is too high. Several improvements to on-device latency were made in the past few quarters. Bidding and Auction (B&A) services building and scaling continues as necessary. Our latency best practices guide was updated to include more information on how to take advantage of these features. We are also exploring development of new latency improvements, some of which can be consulted here.
Logging Behavior in B&A (Test vs. Production) Clarification regarding the differences in logging behavior between test and production modes for B&A services. Specifically, the availability of cloud logs and the impact of production mode on logging. First, it's important to distinguish between prod vs. non_prod builds and the separate TEST_MODE parameter, which simply enables a hardcoded test encryption key. The below explanation focuses on the build types.
In non_prod builds, B&A servers feature a configurable verbosity level for logging. These detailed logs are written to the standard stdout/stderr streams. On Google Cloud, these are accessible through the native logging interface, and on Amazon Web Services, they can be found in the attached-console logs.
For prod builds, the logging behavior is more restricted. The verbosity level is fixed and cannot be changed. While some non-privacy-relevant logs, such as server startup messages and most crash errors, are still printed to stdout/stderr, no request-specific logs are available through this channel. The only per-request logs from a prod build are for requests containing a consented debugging token, and these are exported exclusively via OpenTelemetry. It's important to use consented debugging sparingly, as heavy traffic can degrade server performance and lead to health-check failures.
Regarding metrics, all are exported via OpenTelemetry. Non-privacy-sensitive metrics are always exported as-is, without any "noising". Conversely, privacy-sensitive metrics are always "noised" when exported from a server running in prod mode. The specific telemetry configuration determines whether these privacy-sensitive metrics are exported as noised, un-noised, or both.
Include Full Page Path in Trusted Bidding Signals for Brand Safety Request for an update to PA API to include the full URL path of the top-level page, in addition to the hostname, in the fetch request for trustedBiddingSignals.
The primary use case is to enable more granular brand safety controls. Advertisers often need to block ads from appearing on specific sections of a domain (e.g., news-site.com/politics) while being comfortable with the domain in general. As these blocklists can be millions of entries long, they must be evaluated on the server-side. The current specification, which only sends the hostname, makes it impossible for the trustedBiddingSignals server to perform this necessary path-level evaluation, limiting brand safety capabilities.		 We are currently discussing this issue here, after extensive prior discussions, that can be consulted here, and we welcome additional feedback.
However, we want to clarify that we are only considering adding this information when the trustedBiddingSignals fetch is going to a server running inside a Trusted Execution Environment (TEE).

Protected Auction (B&A Services)

Feedback Theme Summary Chrome Response
Testing Availability Information regarding the availability of Key/Value (KV) v2 for testing in both Chrome and B&A environments. KV v2 is available both on B&A and Chrome. Additional guidance is available here.
KV Server Implementation Request for clarification on the usage of the KV server, specifically concerning mapping creative render URLs to request data, the necessity of coordination between SSPs and DSPs for defining parameters in the render URL, and the availability of documentation outlining required coordination and data storage in KV mode. The KV service uses the renderURL as a key. If the URL is new, it's stored. If it exists, its value is returned for use in scoreAd. The return format depends on the setup: "Bring Your Own Server" (BYOS) allows any value, while the Trusted KV service requires a User-Defined Function.
While not always required, coordination with DSPs is essential for features like macro replacement (e.g., ${AD_WIDTH}) in the renderURL, which enables dynamic ad customization and verification.
We recommend starting with a simple test with one DSP to determine the necessary level of coordination. We are also in the process of updating our KV documentation and will share it publicly once available.
BYOS for B&A Why doesn't B&A offer BYOS mode similar to KV's BYOS mode? B&A requires a TEE, preventing a BYOS model, because it handles highly-sensitive data combinations which require the enforcement of privacy mechanisms, as explained below.
For DSPs:
B&A processes publisher context (potentially the full URL if explicitly sent by the seller via auctionSignals / perBuyerSignals) combined with detailed user IG data. The TEE is essential to securely process this combination and to prevent potential user re-identification. In KV BYOS, the full URL cannot be sent.
For SSPs:
Even just knowing the combination of participating IGs (and their DSP owners) in an auction can generate an identifying signature. This is where the chaffing solution comes into play, which requires the use of a TEE.
Therefore, the secure processing of these combined sensitive signals and the enforcement of privacy mechanisms mandate the controlled, attested environment of a TEE.

Measuring Digital Ads

Attribution Reporting (and other APIs)

Feedback Theme Summary Chrome Response
Noise Policy The implementation of ARA has been valuable for some market participants and Google should continue to maintain event-level reporting. Google should consider relaxing the noise policy in scenarios where both ARA and 3PCs are available. Performance advertisers are increasingly using the current 'value' field implementation of the ARA flex event, and a less restrictive noise policy would help reduce delays and inaccurate reporting. This mechanism is a foundational part of the ARA's design, which is meant to protect user privacy by preventing individual tracking. We are taking into consideration the feedback about the reporting challenges caused by noise, as we continue to evaluate the role the Privacy Sandbox APIs will play going forward, as well as any potential future enhancements, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Roadmap and Long-Term Support Requesting a product roadmap for ARA, as well as confirmation of long-term investment and support given the announcement to not proceed with the introduction of a user choice mechanism for 3PC. The Privacy Sandbox team is engaging with the ecosystem to understand the role the Privacy Sandbox APIs will play going forward and to evaluate any future investments.
Cross-Environment Measurement (App-to-Web) Request for a solution that involves utilizing ARA to facilitate cross-environment measurement, offering a cleaner and more reliable data flow, enhancing the ability to connect user interactions across different platforms. App-to-Web on the same device is already supported by ARA. You can find more details on the cross app and web measurement solution here and here.
Cross-Browser Attribution A unified, cross-browser approach to ARA would dramatically improve the ability to measure ROI on the open web and provide a stable alternative ahead of potential regulatory shifts. Chrome should collaborate with the Safari team on a solution like this. We are already exploring an interoperable API with other browser vendors in the PATCG and PATWG groups within the W3C. Noting that this work is preliminary, stakeholders are welcome to consult our progress here.
Cross-Device/Offline Measurement Inability to support cross-device conversion measurement within ARA is a significant limitation. Measuring online-to-offline conversions is also significantly important, and the browser could play a role in collaborating with measurement vendors. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Multi-Touch Attribution Request to allow advertisers to use Privacy Sandbox data as an unbiased "ground truth" to validate and calibrate their existing attribution models. This can be achieved by using ARA's browser-provided data as a reliable calibration signal, creating a baseline of truth. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Consentless/Opted-Out Traffic Measurement A privacy-preserving solution, such as Interoperable Private Attribution, would enable measurement for consentless traffic. This would allow for a more comprehensive understanding of campaign performance by including data from users who have opted out of tracking, addressing a major gap in measurement created by consent requirements. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Server-to-Server Attribution Request to allow ad techs with sophisticated server-side infrastructure to integrate with ARA in a more flexible way, accommodating use cases that are difficult to manage purely on the client side, while maintaining user privacy. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Multi-Domain Enrollment Seeking clarification on limitations and caveats when enrolling multiple domains with ARA, particularly concerning the aggregation service and cross-origin attribution. Below are the key limitations when using ARA with multiple domains:
• Attribution is scoped to a single origin. You cannot match a click from one of your domains to a conversion on another. Attribution is sandboxed to the same origin for both the source and trigger.
• The Aggregation Service does not support multi-origin batching. Reports from different origins must be batched and processed separately. We are exploring ways to support this in the future.
Briefly, while multiple domains can be enrolled under one entity, all ARA functions, such as attribution and aggregation, must currently be handled on a per-origin basis.

Aggregation Service

No feedback received this quarter.

Private Aggregation API

Feedback Theme Summary Chrome Response
Limits and Noise Levels Concerns regarding limitations on aggregation key sizes and aggregation values within the Private Aggregation API. Aggregation key and value sizes were chosen to have high granularity while limiting network and storage costs. We also recommend using hashing when assigning keys to maximize flexibility.
While there are other factors protecting user data, adding noise is an important piece of the Private Aggregation API's privacy protections.
We are taking into consideration the feedback and will continue to evaluate the appropriate parameter choices alongside our consideration of the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.
Privacy vs. Utility The Privacy Sandbox's approach may prioritize privacy over utility, potentially hindering adoption. Suggestion to allow more granular data sharing with user consent to improve measurement and ad personalization. Aggregation key and value sizes were chosen to have high granularity while limiting network and storage costs. We also recommend using hashing when assigning keys to maximize flexibility.
We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.

Limit Covert Tracking

User Agent Reduction/User Agent Client Hints

Feedback Theme Summary Chrome Response
Spam Detection If the first request from a website that uses a spam detection system relies on client hints, the tracking or detection system could fail to identify or properly categorize the request. Use cases that rely on having access to User-Agent Client Hints (UA-CH) on the first request should make use of critical client hints.
API Feedback Consider deprecating Sec-CH-USA-Wow64 as it is no longer relevant for the modern web. We are considering this request and welcome additional feedback here. We have also received feedback that it would be useful to extend wow64 beyond Windows.

IP Protection (formerly Gnatcatcher)

Feedback Theme Summary Chrome Response
Controls Request for IP Protection toggle for sites to use selectively outside of Incognito mode. We appreciate the feedback and we welcome additional input on this issue here.
Misconduct Will Probabilistic Reveal Tokens (PRTs) resulting in a NULL value prevent perpetrator identification when police request IP address disclosure for platform misconduct? If a domain is used exclusively for fraud and abuse detection, it's likely not included in the Masked Domain List (MDL) and therefore not impacted by IP Protection. Consequently, PRTs would not be needed for those domains.
If a domain is included in the MDL, PRTs are currently the only way to learn the original IP address for a proxied request. As PRTs are specifically designed to support aggregate analysis, not individual identification, it is true that PRTs will not contain an IP address in most cases. We expect this to have limited impact in the described scenario, however, as IP Protection applies only in the third-party context, meaning that publishers will continue to receive un-proxied IP addresses for first-party interactions, such as users visiting the site of an online platform.
Anti-Fraud What are the specifics of Google's anti-fraud measures for IP Protection, including details on rate-limiting access to proxies and authentication token issuance, and what are the specific use cases for PRTs ? We confirm that rate-limiting and authentication tokens in IP Protection are designed to prevent bots from performing ad fraud by over-accessing proxies, as detailed in the anti-fraud and anti-spam strategy. Further use cases for PRTs are outlined in the PRT explainer documentation here.
Incognito Mode Is IP Protection in Incognito mode still planned for Q3? There are currently no changes to the Q3 timeline for IP Protection launch in Incognito mode.

Bounce Tracking Mitigations

Feedback Theme Summary Chrome Response
API Feedback Chrome should block cookie/storage access rather than partitioning them when applying Bounce Tracking Mitigations (BTM), citing unintended behavior and confusion from Safari's "partitioning" method. We welcome this suggestion. Currently, BTM does not involve cookie/storage partitioning and instead deletes it after a grace period. If there are any later designs to BTM that involve immediate action towards cookies, we intend to prefer blocking cookies over partitioning them.

Strengthen cross-site privacy boundaries

No feedback received this quarter.

Fenced Frames API

No feedback received this quarter.

Shared Storage API

Feedback Theme Summary Chrome Response
API Feature Request Request to append ad views and clicks in Shared Storage. We are taking this feedback into consideration as we evaluate the role the Privacy Sandbox APIs will play going forward, in light of Google's April 2025 announcement that the current approach to offering users 3PCs choice in Chrome will be maintained.

CHIPS

Feedback Theme Summary Chrome Response
API Question Request for clarification on how Chrome's 3PC controls interact with CHIPS, specifically whether non-partitioned cookies are converted to partitioned ones when 3PCs are disabled, and if partitioned cookies remain active. Non-partitioned cookies will not be stored, retrieved, or sent in a third-party context when 3PCs are disabled. Partitioned cookies, however, will continue to be stored, retrieved, and sent in a third-party context, as their functionality is not impacted by browser settings that disable 3PCs.
Privacy Concern Concern that an embedded party with a persistent identifier, such as for Single Sign-On, might still enable both embedding and embedded parties to gain a global digital identifier, even with partitioned cookies. While an embedded party may have a persistent identifier, this identifier, when stored in a partitioned cookie, is only accessible on the site where the cookie was set by the embed. Cross-site joining of this identifier would require a login action, which already allows for the exchange of an identifier in the form of an authentication token, even without the use of partitioned cookies.

FedCM

Feedback Theme Summary Chrome Response
API Usage Silent mediation failing for users with multiple accounts with no specific error. The silent mediation behavior is a by-design feature, as it is intended for a very specific case with just one available account. The recommendation is to use the "optional" mediation instead, in which FedCM falls back to presenting the user with an account chooser if silent mediation is not possible.
API Usage navigator.credentials.get returns generic errors, preventing capture of specific rejection reasons like user dismissal or cooldown periods. The inability for developers to distinguish between the user dismissing the FedCM dialog vs. a network error vs. FedCM being in a "cooldown period" due to the user having previously dismissed the dialog is also a by design feature, meant to preserve the user's privacy. The concern is that such a capability would allow websites to infer the user's login state on different Identity Providers (IdPs).
Sign-in Inconsistent account selection behavior with multiple signed-in accounts was observed. It is unclear whether the intermittent inability to select a specific account in a multiple-signed-in-account scenario is an intermittent bug in FedCM or some issue involving the testing system. We are working with the reporter to resolve this issue, and have asked for further details in order to better understand the issue.
API Usage If the user dismisses the dialog while authorising with FedCM, the fact that they are in the cooldown state is not reported via a catchable error. Yes, that would be the case and this would produce the generic error code in order to preserve user privacy.
API Usage Why does FedCM go into a 10-minute quiet period after a successful "auto-reauthentication"? Given that auto-reauthentication happens without a user-initiated action, if the user wanted to go back to the website but sign in with a different account, they would need a period of time when FedCM does not auto-reauthenticate them. The "quiet period" provides the opportunity for users to manually sign in using a different account. This blog post has further details on this "quiet period".
Lightweight FedCM Concerns that the Lightweight FedCM proposal introduces additional complexity for IdPs due to the need for supporting two incompatible implementations (FedCM vs. Lightweight FedCM). Lightweight FedCM is compatible with traditional FedCM. IdPs can choose which implementation method to use and will not be required to support both.
Lightweight FedCM is a push mechanism for FedCM. If an IdP chooses to use this feature, they can push the account information to the browser when the user logs in, so that, when a Relying Party (RP) invokes FedCM, the account would be retrieved from the browser, instead of the IdP's accounts endpoint.
Lightweight FedCM Concerns about the exposure of personal user data such as name, email, and profile picture to the RP in the Lightweight FedCM proposal. The proposal for Lightweight FedCM has been updated since receiving this feedback, to remove the name, email, and profile image from the method response.
Lightweight FedCM Managing multiple signed-in accounts appears to be too rigid in the Lightweight FedCM proposal. The proposal does not currently support individual session lifetimes or nuanced login states per account. Expiration is currently tied to the IdP within the credentials object. We have noted per-account expiration as an open question and will take this feedback into consideration for future developments.
Lightweight FedCM The distinction between "signed in" and "available for selection" is not clearly defined, which could impact the user experience for the Lightweight FedCM proposal. We do not currently support the ability to distinguish if an account is logged in or logged out in the FedCM User Interface (UI). Logged out accounts should not be listed.
If an account is logged out and listed, and a user selects the account that is not actively logged in, the Continuation API can be used to have the user log back in.
API Usage Inconsistency between the given_name field in getUserInfo and its usage in the FedCM UI. This issue was discussed further with Mozilla here, in order to align on how given_name should be treated in getUserInfo.
API Usage Not all fields used in the UI from IdentityProviderAccount are provided to getUserInfo, specifically tel and username, suggesting a need for synchronization. The discussion with Mozilla and other FedID Community Group members is progressing on the issue of reconciling which fields from IdentityProviderAccount get sent to getUserInfo.
Enterprise FedCM Request for FedCM support for Enterprise IdP use cases. The key issue is the need for a trusted mechanism for IdPs to signal to browsers that administrators have pre-consented to allow the user to access specific RPs that cannot be mimicked and/or abused by Web trackers. This was discussed in the 22 April FedID CG meeting (please find here notes of the meeting) and combinations of browser extensions and Enterprise Policies (for managed devices) were put forth as potential solutions. We welcome additional feedback on this issue here.

Fight spam and fraud

Private State Token API (and other APIs)

No feedback received this quarter.