Feedback Report - 2022 Q4
Quarterly report for 2022 Q4 summarising the ecosystem feedback received on Privacy Sandbox proposals and Chrome's response.
Published on
Anusmita Ray
Technical Writer, Google Chrome
As part of its commitments to the CMA, Google has agreed to publicly provide quarterly reports on the stakeholder engagement process for its Privacy Sandbox proposals (see paragraphs 12 and 17(c)(ii) of the Commitments). These Privacy Sandbox feedback summary reports are generated by aggregating feedback received by Chrome from the various sources as listed in the feedback overview, including but not limited to: GitHub Issues, the feedback form made available on privacysandbox.com, meetings with industry stakeholders, and web standards forums. Chrome welcomes the feedback received from the ecosystem and is actively exploring ways to integrate learnings into design decisions.
Feedback themes are ranked by prevalence per API. This is done by taking an aggregation of the amount of feedback that the Chrome team has received around a given theme and organizing in descending order of quantity. The common feedback themes were identified by reviewing topics of discussion from public meetings (W3C, PatCG, IETF), direct feedback, GitHub, and commonly asked questions surfacing through Google’s internal teams and public forms.
More specifically, meeting minutes for web standard bodies meetings were reviewed and, for direct feedback, Google’s records of 1:1 stakeholder meetings, emails received by individual engineers, the API mailing list, and the public feedback form were considered. Google then coordinated between the teams involved in these various outreach activities to determine the relative prevalence of the themes emerging in relation to each API.
The explanations of Chrome’s responses to feedback were developed from published FAQs, actual responses made to issues raised by stakeholders, and determining a position specifically for the purposes of this public reporting exercise. Reflecting the current focus of development and testing, questions and feedback were received in particular with respect to Topics, Fledge and Attribution Reporting APIs.
Feedback received after the end of the current reporting period may not yet have a considered Chrome response.
Glossary of acronyms
Glossary of acronyms
- CHIPS
- Cookies Having Independent Partitioned State
- DSP
- Demand-side Platform
- FedCM
- Federated Credential Management
- FPS
- First Party Sets
- IAB
- Interactive Advertising Bureau
- IDP
- Identity Provider
- IETF
- Internet Engineering Task Force
- IP
- Internet Protocol address
- openRTB
- Real-time bidding
- OT
- Origin Trial
- PatCG
- Private Advertising Technology Community Group
- RP
- Relying Party
- 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 |
|---|---|---|
| (Also reported in Q3) Usefulness for different types of stakeholders | Concerns that the Privacy Sandbox technologies favor larger developers and that niche (smaller) sites contribute more than generic (larger) sites | Our response is unchanged from Q3: "Google has committed to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising and on publishers and advertisers, regardless of their size. We continue to work closely with the CMA to ensure that our work complies with these commitments. As testing of the Privacy Sandbox progresses, one of the key questions we will assess is how the new technologies perform for different types of stakeholders. Feedback is critical in this respect, especially specific and actionable feedback that can help us further improve the technical designs. We have worked with the CMA to develop our approach to quantitative testing, and are supportive of the CMA publishing a note on experiment design to provide more information to market participants and an opportunity to comment on the proposed approaches." |
| (Also reported in Q3) Documentation requests | Requests for more resources detailing how to manage testing, analysis, and implementation | Q4 Update: We appreciate that developers have found our current material helpful, and continue to be committed to providing more material so developers can understand how the new technologies can work for them. Over the past quarter, we added a "News & Updates" section to privacysandbox.com and published an extensive review of how the Privacy Sandbox can help drive ad relevance in the future. We've also held public developer office hours sessions to share best practices and demos, along with Q&A sessions with product and engineering leads to allow for live discussion/questions. |
| Core Web Vitals | How does Privacy Sandbox API latency impact Core Web Vitals? | Keeping latency to a minimum is a key design goal of the Privacy Sandbox APIs. Our current expectation is that API latency should have minimal impact on a site's Core Web Vitals, as the majority of APIs are called after the initial rendering of the website. We continue to monitor and make improvements to reduce latency further for each of the APIs, and encourage continued testing and feedback. Latency in the real time bidding process is addressed in the FLEDGE section under "Performance of FLEDGE Auctions" |
| Interoperability | Concerns regarding interoperability with other potential solutions | The goal of Privacy Sandbox is to protect users against cross-site tracking while supporting the needs of the web ecosystem. We seek to accomplish this by moving away from legacy browser technologies that enable such cross-site tracking, like third-party cookies, and providing in their place new technologies purpose-built to support specific use cases. The Privacy Sandbox proposals improve privacy by limiting the data that leaves a user's device. The proposals do not place technical restrictions on a website's ability to share or otherwise process data once collected from the browser. The technologies therefore do not prevent companies from entering into "data stewardship" agreements or any other similar contractual relationship. Likewise, they do not restrict the ability of users to consent to sharing their data via other means. For clarity, Google has committed to apply the Privacy Sandbox technologies in the same way to all websites, including Google products and services. After Chrome ends support for third-party cookies, the commitments also make clear that Google will not use other personal data, such as users' synced Chrome browsing history, to track users for the targeting or measurement of digital advertising. |
Show Relevant Content & Ads
Topics
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Impact on Google search ranking | Enquiry on whether a website's Topics API support will be used as a potential signal for Google Search results ranking | Some websites may choose to opt-out of the Topics API. 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 has confirmed to the CMA that Google Search will not use a site's decision to opt-out from the Topics API as a ranking signal. |
| Topics classifier | Add url and page content in addition to hostname to determine a webpage's Topic in order to improve utility for various stakeholders. | A user's browsing history is currently classified using a website's hostnames. Chrome continues to evaluate options for considering page level metadata (such as all or some components of the page URL and/or content) in Topics classification. Any utility improvements must be weighed against the privacy and abuse risks. For example, with respect to metadata in particular, a few of the risks include: - Sites modifying page-level metadata as a method to encode different (and potentially sensitive) meanings into topics; - Sites modifying page-level metadata to misrepresent their topics for financial gain; - Sites modifying page-level metadata dynamically as a method of cross-site tracking |
| (Also reported in Q3) Impact on first-party signals | Topics signal may be highly valuable and as a result devalues other first-party interest-based signals. | Our response is unchanged from Q3: "We believe interest-based advertising is an important use case for the web, and Topics is designed to support that use case. As described [in our Q3 report], other ecosystem stakeholders have expressed concerns that Topics may not be useful enough to provide value. In all cases, improvements to the taxonomy are an ongoing effort, and we expect the taxonomy to evolve with ecosystem testing and input." |
| Updating Taxonomy | How will the taxonomy list be updated? | We are actively seeking feedback on the taxonomy that would be most useful for the ecosystem. The taxonomy included in the initial Topics API proposal was designed to enable functional testing. Chrome is actively considering multiple approaches for updating the taxonomy. For example, Chrome may utilize a notion of commercial value for each topic to determine which category to include in future iterations. |
| Topics regional classifier performance | Topics classifier performing poorly in regional domains | Improvement to the classifier is an ongoing effort. Based on the feedback we have received, one possibility under consideration is to expand the Topics override list, which our analysis shows will increase global coverage and improve accuracy. To explain, the Topics API classification has two relevant components: (1) An override list containing the top 10k sites and their topics, and (2) an on-device ML model that classifies hostnames into topics. By expanding the override list (1), we can improve performance of classification for those regions in which the classifier may be performing poorly. |
| One week epoch | The one week epoch is too long for users looking to make shorter term decisions. | We are actively looking at what the suitable length of epoch should be and we welcome further feedback on what would be a better epoch for the ecosystem. |
| HTTP header retrieval | Concern that there is not enough information regarding the HTTP header retrieval of topics | Work is in progress for headers and fetch(). We also have information available here. We have also added skipObservation information to the explainer. |
| Topics only aims to help advertisers, not users | Topics/Privacy Sandbox appears to be an industry focused approach. Benefit for users is not as clear as benefit to industry. | We believe the benefit to users is that Topics supports interest-based ads that keep the web free and open, and we also believe it significantly improves privacy compared to third-party cookies. Removing third-party cookies without viable alternatives may negatively impact publishers, and could lead to worse approaches which are less private, are not transparent, and are not realistically resettable or controlled by users. Many companies are actively testing Topics and Sandbox APIs, and we're committed to providing the tools to advance privacy and support the web. The W3C Technical Architecture Group has recently published its initial view about the Topics API, which we will be responding to publicly. At this stage, since Google has received questions from the ecosystem about what this review may imply for the development and launch of the Topics API, we would like to reaffirm our plan to make it available in Chrome Stable this year. While Googles appreciates the input of the W3C Technical Architecture Group, it considers it of paramount importance to continue the efforts to develop and test Topics in consultation with the CMA and the ecosystem. |
| Data leakage | Concern that Topics may be leaked to other sites without permission | The design of the Topics API makes it quite unlikely that data from a single publisher (and even a smaller group of publishers) can be leaked in any way. Publisher websites are also in full control over the Topics API and they can prohibit access to this API via permission policy. |
| Lack of advertisers for testing | Publishers are concerned that they currently are unable to demonstrate the value of Topics to advertisers. | In the second half of 2023, we plan to have all the ads related APIs available for integration testing and enable ecosystem analysis of the value of Topics for advertisers. Testing and publication of the results will be supervised by the CMA, which will review the data, analysis and methodology. The ecosystem is encouraged to share feedback with Google and the CMA. |
| Topics and FLEDGE | Request for more information on how to use Topics within FLEDGE's bidding logic | It is possible to use Topics within FLEDGE's bidding logic. An integration guide is also in progress, and will include additional details on implementation. |
| Custom ranking for topics caller | Allow rankings to be tailored by caller | The challenge with custom topic ranking or values for each ad tech is that this could become a mechanism by which an ad tech can influence the topics that are returned, therefore a fingerprinting vector. |
| Topics caller priority list | Allow callers to provide a ranked priority list of topics that the Topics API will return based on eligibility. | We are currently discussing this idea further and welcome additional inputs. |
FLEDGE
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Google Ad Manager | Concern that Google Ad Manager is the end decider for FLEDGE auctions and would favor Google Publisher Tags and Google Ad Manager. | FLEDGE allows each publisher to choose the structure of the auction, including the choice of top-level and component sellers. Each buyer and seller in a component auction knows who the top-level seller is, and can choose whether or not to bid. |
| Not enough participants testing FLEDGE | Request to encourage more companies to test FLEDGE, for example by improving the API's functionality and discouraging privacy-intrusive alternatives like fingerprinting | The Privacy Sandbox is proceeding in stages, in close partnership with the guidance of the CMA and ICO, and functional FLEDGE testing has demonstrated necessary stability and capability. Google continues to encourage the ecosystem to test the Sandbox APIs, recently publishing its "Maximize Ad Relevance" documentation to showcase how FLEDGE and other APIs can help support critical use cases for the ad industry after third-party cookie deprecation. Other parts of the Privacy Sandbox already support mitigations to cover tracking (see UA-CH, IP Protection, and Bounce Tracking Mitigations) and will continue to improve over time. Google's goal is not to make FLEDGE the only viable targeting solution, but instead remains committed to working in partnership with industry and regulators to drive the best privacy-preserving ad technologies in the Chrome browser. |
| Machine learning use cases | More guidance on how machine learning use cases to train auction bidding algorithms will be supported in FLEDGE and Attribution Reporting | We recognize the need to help testers find the most useful ways of applying the Privacy Sandbox technologies. We have begun to publish guidance specifically related to the use of the various aspects of the Privacy Sandbox APIs as inputs to machine learning. The most recent piece, "Maximize Ad Relevance", discusses how the ads industry can leverage these signals for machine learning, and we plan to continue publishing such guidance going forward. |
| Querying FLEDGE Key Value (K/V) Server | Why is the K/V server publicly queryable? | The K/V server aims to provide real time signals to FLEDGE auctions. As such, the K/V server needs to be accessible from where those FLEDGE auctions execute, which is on user devices, requiring that it be publicly available. A value stored in the K/V server can only be retrieved by a party that already has its key — so if an ad tech only gives the keys to browsers that are in the Interest Group, and does not use keys that can be randomly guessed, then only browsers that need the Value to run their auction will be able to retrieve it. |
| How to do date/time targeting? | Support for date objects in the bidding logic function. | There are multiple ways to do this. Buyers can ask their seller to provide the current date and time, and it should be easy for sellers to provide this information to all buyers. Buyers can also provide the date and time in their real time key-value response. Finally, buyers can provide the date and time as part of their contextual response in the per-buyer-signals, which a seller could pass to the buyer's generateBid script. |
| User preferences | Ability for users to choose to block creatives by advertiser when served via FLEDGE, or alternative solutions. | Users have the ability to opt out of Ads APIs in Chrome. For specific ads, the relevant ad tech is the party best positioned to offer controls over which creatives are shown or how they are selected. |
| Clearer timelines | Request for more information on availability of privacy protections in FLEDGE, such as requiring Fenced Frames. | We plan to publish more detailed timelines in Q1. |
| Reporting confusion | Request for more clarity on how FLEDGE reporting will work with other APIs such as Fenced Frames and Private Aggregation API. | We plan to publish an explainer on the interaction between Private Aggregation API, FLEDGE, and Fenced Frames in the coming weeks. |
| Real-time bidding and FLEDGE | Guidance on how FLEDGE integrates with standard real-time bidding. | The two main things that complicate an ad-tech's ability to do real-time bidding are access to event level data and easier integration into ARA. We are planning on sending updates and explainers on both of these in Q1. |
| Performance of FLEDGE Auctions | Report from testers that FLEDGE auctions have high latency | We appreciate reports from testers sharing their results and use cases and have shared some suggestions on how to improve the performance of FLEDGE. In parallel, we have added tooling to the browser allowing developers to better diagnose what is making auctions slow, and have been systematically addressing the primary sources of latency observed. Recent improvements include timeouts for slow auctions, a fast bidder filtering technique, a way to reuse FLEDGE worklets to avoid paying startup costs, and ongoing work to allow the contextual ad request to run in parallel with the FLEDGE startup time and network fetches. We expect latency optimization to continue as an ongoing conversation between Chrome developers and FLEDGE testers based on their real-world experience using the API. |
| Interest Group size memory limit | Request to raise the limit on the size of a single interest group from 50kB. | We are actively considering the request and are looking for feedback on what limit value works. |
| Combining the FLEDGE served data with first-party cookie | Will FLEDGE support integration with an advertiser's first-party data? | FLEDGE was built to support advertising using the first-party data an advertiser already has. However, FLEDGE does not intend to support an advertiser learning a person's browsing behavior on any website other than the advertiser's own site. Attaching off-site browsing behavior to first-party data is contrary to the goals of Privacy Sandbox. We are planning to share integration guides with more details on how FLEDGE will support integration with first-party data in the coming weeks. |
| K-anonymity value | How will the value "K" to "k-anon" be decided and will it be published? | The "K" value is still being finalized and we will share more information as our plans develop. We are interested in learning more about how an unknown k value may hinder FLEDGE preparedness and scoping ML model training and we welcome additional feedback on this subject. |
| Supporting multiple SSPs | How will multiple SSPs be supported in FLEDGE? | FLEDGE supports multi-seller auctions as noted in this proposal. |
| Visibility of bidding logic | Concern that DSP bidding logic will be exposed in JavaScript | With the current design bidding logic JavaScript can be accessed by others, but we welcome more feedback as to why this could be a source of concern for DSPs. |
| prebid.js | What is the timeline in supporting prebid.js in FLEDGE? | Only versions 7.14 and later of Prebid.js support the FLEDGE module. Any publishers interested in testing must add the FLEDGE module and upgrade their Prebid instance. |
| User defined functions in FLEDGE | How will user defined functions (UDF) be supported in FLEDGE? These are functions that can be programmed by end users to extend the functionality of the API. | Explainer available here. This is still being fleshed out so we welcome additional feedback on use cases. |
| Relaxing same-origin constraint on Interest Group resources | Request to relax same-origin constraint on Interest Group resources to enable certain ad tech use cases | In the current implementation of FLEDGE, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl and trustedBiddingSignalsUrl must have the same origin as the interest group owner.The constraint exists to prevent certain exploits by attackers, as explained here. |
| interestGroup Ownership | Request to limit whether an ad tech can use joinInterestGroup for the same Interest Groups across sites | Our focus is on how audiences are used, not how they are built. We are discussing potential approaches here and welcome additional input. |
| Key Value Server Key Expiration | Discussion on removing server keys once the corresponding interest groups have expired | We are exploring ways to handle key expiration and are looking for feedback here. |
Measuring Digital Ads
Attribution Reporting (and other APIs)
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Origin Trial traffic | Current Origin Trial traffic is not enough to conduct utility testing. | The current Origin Trials are meant for ecosystem players to conduct functional testing in order to ensure the API is working as intended. We understand that larger amounts of traffic will be required to perform utility testing once the development of the various Privacy Sandbox API is more mature. The current testing timeline envisages that this will occur by General Availability (i.e. when the technologies for the use cases will be launched and available for 100% of Chrome traffic) at Q3 2023 (see our up-to-date timeline on privacysandbox.com).We welcome any additional feedback on use case testing that requires additional traffic. |
| Overlap in functionality of different Privacy Sandbox measurement APIs | Concerns in having multiple measurement approaches overlap through Privacy Sandbox will increase complexity, for example, Attribution Reporting API and Private Aggregation API. | We are working on better documentation to clarify the different use cases for the APIs, and welcome additional feedback on what areas are lacking explanation. For example, Attribution Reporting API is intended specifically to support conversion measurement, whereas Private Aggregation API and Shared Storage are general-purpose APIs intended to support a broader range of cross-site measurement use-cases. |
| Retry failed report request | Clarification on how many times a report request is attempted if it fails. | We have published guidance on this. To summarize, reports are only sent when the browser is running/online. After the first failure to send, the report is retried after 5 minutes. After the second failure, the report is retried after 15 minutes. After that the report is not sent. |
| Reporting Delay | What is the expected reporting delay? | We are looking to hear more feedback from the ecosystem on any reporting delays they are experiencing as we collect data to further assess these delays in parallel. |
| Prerender pages | Will ARA attribution work on prerender pages? | Attribution registration is deferred on prerender pages until activation (actual click or view takes place). This means we will defer the `attributionsrc` request ping. |
| Measuring conversion lift | How to measure conversion lift with AB testing on the same domain | Websites can measure conversion lift with A/B testing on the same domain through attribution reporting. They can encode their A/B parameters as keys using the aggregate API and then receive summary reports for the conversion values by those key buckets. |
| (Also reported in Q3) Cross-domain conversions | How to track the conversions that are cross domain, such as with 2 or more destinations | Q4 Update: We have published a proposal to remove the landing page destination restriction which enables cross domain conversations to be tracked. This proposal has been implemented. |
| (Also reported in Q3) Expiry setting in conversion report | Request to support report filter / expiry for less than 24 hours | Q4 Update: We have shared this pull request which will decouple expiry and reporting windows to mitigate the trade off of reporting delay vs conversion expiry. This is now launched in M110. |
| Fraud and Abuse | Requests from advertisers and marketers to be able to slice and aggregate data based on publisher sites where their ads are served, which would also give more insight into potential fraudulent ad practices | This feedback is actively being discussed here and we welcome additional inputs. |
| (Also reported in Q3) Event level reporting delay | The delay of 2-30 days in event level reporting may be too long for certain use cases. | Event level reporting has default reporting windows of 2, 7, and 30 days. This can be modified by using the "expiry" parameter. Ad-techs could configure the expiry, with a minimum of 1 day, to get potential reports in less than 2 days. We limit the granularity of expiries to 1 day as a privacy protection mechanism, as more fine-grained reporting could result in timing attacks. Additionally, we allow setting independent "expiry" parameters for event level and aggregate reports. See here. Additionally, Google Ads will not get any special reporting windows that other ad-techs do not get via the Attribution Reporting API. |
| Same reporting origin requirement | Request to remove requirement for source registration origin to be the same as the conversion registration origin | We propose using HTTP redirects to delegate registration to solve this use-case. We welcome any additional feedback on the new guidance. |
| Conversion tracking | Need to differentiate whether the conversion happened before/after certain hours set by the advertiser | Attribution Reporting API supports setting an expiry window and priority for source attribution. By using both, it will technically be possible to attribute a conversion that happened within X days window separately from a conversion that happened after X. |
| Noise simulation | Request to be able to simulate the different volume of conversions per bucket, to understand the impact on advertisers with less conversions | We are looking to add ways to simulate this in future versions of Noise Lab. We welcome any additional feedback. |
| Reporting on mobile | Will the report still be sent when Chrome is running in the background on mobile? | At the moment, even on mobile, the report will not be sent when Chrome is in the background. This is likely to change when the API integrates with Android Privacy Sandbox. See here. Note that Android Privacy Sandbox is not part of the Commitments accepted by the CMA. |
| Data availability | Concerns that Google will have additional access to data via Privacy Sandbox APIs | First, Google Ads does not receive any preferential access to data from the Attribution Reporting API or other Privacy Sandbox APIs. This issue is also addressed in the General Feedback section under "Interoperability" which includes more detail on Google's Commitments. Second, on the difference between larger and smaller sites, Google recognizes that noise-based privacy protections may have a greater impact on smaller data slices. However, there are some possible mitigations: for instance, methods like aggregating over longer periods of time would solve this problem. That said, it remains unclear if conclusions based on very small data slices (like one or two purchases) are meaningful at all to advertisers. During the origin trial, Google has encouraged testers to take advantage of the ability to experiment with a wide range of privacy and noise parameters so they can provide more specific feedback on this issue. |
Limit Covert Tracking
User-Agent Reduction
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Delay User-Agent Reduction until web ecosystem is more ready | There is not sufficient time to adapt to the coming User-Agent Reduction changes. | We address this feedback in the full report under "Stakeholder Concerns" in the section titled "Google's interaction with the CMA". |
| Delay User-Agent Reduction until web ecosystem is more ready | Request to delay User-Agent Reduction rollout until Structured User Agents (SUA) is deployed | The Google Ads team proposed the Structured User-Agent addition (see specification) to OpenRTB in October 2021 and it was incorporated in the 2.6 spec update released in April 2022. We have some evidence that SUA is deployed and available today, as demonstrated by the Scientia Mobile blog post demonstrating how to use UA-CH and the WURFL API to create a SUA. |
User-Agent Client Hints
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Test UA-CH with other anti-covert tracking techniques | Guidance on how to test all Privacy Sandbox APIs and fingerprinting techniques proposed together in a holistic approach | Our testing plan was designed in order to reflect the asynchronous timelines for developing some of the anti-fingerprinting measures as opposed to the rest of the Sandbox Proposals. It addresses the reality that some anti-fingerprinting measures (i.e. Privacy Budget, IP Protection and Bounce Tracking Mitigations) will be fully-developed and ready for launch to General Availability only after third-party cookie deprecation. While those anti-fingerprinting measures will not be included in quantitative tests, they will be subject to qualitative assessment based on the facts available at the time of Standstill. |
| (Also reported in Q2) Performance | Concerns about the latency of getting hints via Critical-CH (on the first page load) | See dedicated UA-CH section below |
| Insufficient Feedback | Feedback from the ecosystem about the UA-CH change may not be sufficient, leading to concerns about a lack of awareness from the ecosystem. | We've been proactively sharing our plans to ensure a careful rollout that minimizes disruption. The plans for User-Agent Reduction and the UA-CH API were presented to the W3C Anti-Fraud Community Group on March 18th, 2022 and to both the Web Payments Working Group and the Web Payments Security Interest Group on January 20th, 2022. No significant concerns were raised during or after the presentations. Google has proactively engaged with more than 100 site operators to obtain feedback. Furthermore, Google has also used Blink-Dev channels to communicate the roll-out of the user-agent reduction publicly based on feedback from ecosystem stakeholders. |
| Timing | Concerns raised regarding timing of rollout and industry preparedness | See dedicated UA-CH section below |
| Chrome Platform Status | Requested that the chromestatus page for UA-CH be updated | The chromestatus entry was updated on December 19 to "Mixed signals". |
IP Protection (formerly Gnatcatcher)
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Opt in or Opt Out | Is IP Address Privacy Opt In or Opt Out? | Our goal is to provide IP Protection to all users. With that goal in mind, we are currently evaluating user choice options for IP Protection. |
| IP Address use case for first-party data | Is it possible to use IP addresses to stitch together user journeys across first-party domains post IP Protection? | As previously published, IP Protection will initially focus on tracking in the third-party context, which means first-party domains will not be impacted. |
| Ad Tech use cases | How can companies set up anti-fraud measures with IP Protection? | We recognize the importance of IP address as a signal for anti-fraud efforts in today's web. As part of our Commitments to the CMA (paragraph 20), we have said that we will not implement IP Protection without making reasonable efforts to support websites' ability to conduct anti-spam and anti-fraud efforts. One of our top priorities is to understand how IP Protection impacts anti-fraud use cases and detection capabilities, so that we can further invest in privacy preserving technologies that help companies preserve web safety. We encourage feedback and input on new proposals aimed at supporting the needs of security and anti-fraud companies, even as signals change over time. |
| Fraud and Abuse | Does IP protection include Denial of Service (DoS) Protection? | We are committed to improving privacy while keeping the web safe, and protecting against denial-of-service attacks is an important anti-abuse use case to design for. We hope to minimize impact to DoS protections through both the design of IP Protection itself and through new anti-abuse solutions. Because IP Protection is initially focused on third-party embedded services, some stakeholders have indicated that it should have limited impact on DoS protection for first-party sites. However we continue to ask for public feedback to assess risk to DoS use cases, particularly to third-party embedded services. In parallel, we are exploring abuse-feedback and client-blocking mechanisms that would enable a site or service to block a spammy user, without identifying the user. |
| Content Filtering | Content filtering with IP Protection | Different companies have different needs with respect to filtering content and customizing user experience. Many such use cases do not currently rely on IP addresses and therefore should be unaffected by IP Protection. For example, a publisher looking to tailor its content and drive more engagement might use first-party cookies or third-party partitioned cookies (CHIPs) to understand a user's interests and previous interactions with the publisher. Or an ad tech partner focused on delivering the right ad to the right user can incorporate FLEDGE and Topics, for example, to deliver similar ad outcomes as they do today with third-party cookies or other cross-site tracking technologies. We are also exploring building new privacy-preserving capabilities into IP Protection, such as coarse geolocation, to further support content filtering where existing mechanisms may be insufficient. We welcome additional feedback on content filtering use cases that may be impacted by IP Protection. |
| (Also reported in Q3) Geolocation use cases | IP Protection may prevent legitimate geolocation use cases from working in the future, such as content personalisation based on geolocation. | Q4 Update: We are working with stakeholders to ensure that Chrome continues to support legitimate use-cases for IP addresses. We are seeking ecosystem feedback on IP Geolocation granularity here. |
Privacy Budget
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Clearer documentation | More examples so stakeholders can anticipate how things may be limited once Privacy Budget is implemented | The Privacy Budget proposal is still under active discussion and has not been implemented by any browsers. The earliest date of scaled availability represents the earliest date when Privacy Budget could be enforced. This will not happen before the removal of third-party cookies in 2024. We do not have any additional documentation to share at the moment. We will share additional details on the proposal when it becomes more finalized. In the meantime, we welcome stakeholders to share any feedback that would help in the development of the proposal. |
Strengthen cross-site privacy boundaries
First-Party Sets
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| (Also reported in Q3) Domain limit | Request to expand the number of associated domains | Q4 Update: We have released FPS for local testing, including a mock set submission process on GitHub and a flag to test rSA and rSAFor locally. We have also hosted two open meetings for developers on FPS to continue to address questions around use cases for the associated subset. We encourage developers to test out FPS functionality to provide feedback on how the domain limit for the associated subset would impact the usability of FPS for their use cases. We have clarified in WICG calls that Chrome is committed to providing a usable solution that considers users' privacy interests as well. In that vein, we would appreciate feedback from the community on specific use cases that may be impacted by the domain limit, so that the team can consider ways to address these use cases while continuing to protect user privacy. |
| Request for more details about the abuse mitigation measures | What happens if a domain is added to a set they did not consent to? | We have published submission guidelines for First-Party Sets here on December 2, 2022. As explained in the submission guidelines, any set change management will be following and respecting a validation process on GitHub, including validation on ownership, which should mitigate this risk. |
| Abuse mitigation | Concern that First-Party Set formations can be exploited | We are looking at ways to expand technical checks for subset types and are actively seeking additional input from the community here. |
| Ads use cases | Questions on whether First-Party Sets should be used to support Ad targeting | We're not trying to support Ads targeting use cases for First-Party Sets, and we recommend using the Ads APIs available for such use cases. |
| (Also reported in Q3) Policy | Concern that FPS is not consistent with the CMA Commitments regarding "Applicable Data Protection Legislation," on the basis that GDPR does not impose a limit on the number of sites in a set while FPS envisages a limit of 3 | Our response is unchanged from Q3: "Google is continuing to commit to the CMA to design and implement the Privacy Sandbox proposals in a way that does not distort competition by self-preferencing Google's own business, and to take into account impact on competition in digital advertising, publishers and advertisers as well as impact on privacy outcomes and compliance with data protection principles as set out in the Applicable Data Protection Legislation. The concern expressed does not disclose any incompatibility with GDPR. We continue to work closely with the CMA to ensure that our work complies with these commitments." |
| Alternative proposal | GDPR Validated Sets | In addition to the feedback provided by the ecosystem on the proposal to adopt "GDPR Validated Sets," Chrome has concerns about the following limitations of this alternative proposal:
Since this alternative was raised, Chrome has updated the First-Party Sets proposal and published submission guidelines for creating new sets. |
Fenced Frames API
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Fenced Frames restrictions during OT | What are the current restrictions around Fenced Frames for the Origin Trial period? | We are working on documentation on the restrictions and implementation status and plan to share it during Q1 2023. |
| Multiple ads in a single Fenced Frame | Request to display multiple advertisers in one Fenced Frame in one auction | Currently, this request is not being actively developed, but we welcome additional feedback if ecosystem players consider the feature important. |
| Web Bundles | What are the requirements and support planned for Web Bundles with Fenced Frames? | We currently do not have an update on whether this will be the requirement in the future. Any changes would be announced in advance and would not be enforced before third-party cookie deprecation. Please see this explainer for the current status. |
Shared Storage API
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Shared Storage for Ad Tech | Uncertainty surrounding the use of shared storage for Ad Tech use cases | Shared Storage and Private Aggregation API can be used for different kinds of measurement purposes that need cross-site storage measurement. Some examples are listed here. We are foreseeing DSP and Measurement solution providers to be the main integrator for ads use cases. |
CHIPs
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| (Also reported in Q3) Partitioned requirement | Add explicit behavior requirement for "Partitioned" attribute on first-party cookies. | Q4 Update: After discussions on GitHub and PrivacyCG calls, the behavior that we have aligned on is that Partitioned cookies set on first-party cookies will use a partition key of (A,A) where "A" is the top-level site. We will document this behavior on the explainer and specification. |
| Cookie Management | Are there tools for managing/governing first-party or third-party cookies? | Chrome DevTools and NetLog can be used to test sites with third-party cookie blocking enabled. Both tools report when cookies are blocked due to user configuration. We welcome feedback on what sort of additional auditing websites would like to see. |
FedCM
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| IdP requires knowledge of RP to allow a session | Issue when a user is trying to log into the Feide IdP from two different RPs | We are discussing potential solutions to this issue here. |
| Interoperability | Concerns regarding the impact of FedCM on the relationship between users and the websites they log into using FedCM, and "interoperability" among websites | FedCM aims to continue supporting federated-identity services that currently rely on third-party cookies once third-party cookies are removed from Chrome. We expect that FedCM will be just one option available to such services; identity providers (IdPs) and relying parties (RPs) are free to use other technologies that may better suit their needs. It appears that concerns regarding the user-RP relationship and "interoperability" owe to a misunderstanding of the FedCM proposal. FedCM leaves it to IdPs to decide what information to share with an RP, and in what form, once the user has chosen to sign in to that RP's site. FedCM does not require IdPs to "create a unique pseudonymous identifier for each [RP] with whom the user authenticates." Rather, FedCM is open for each IdP to choose whether to share the user's actual identifier, a per-site version of that identifier, or some other version of this information. (The FedCM specification does identify cross-site correlation as a privacy risk associated with the API and discusses directed (per-site) identifiers as a possible mitigation. However, the decision whether to use directed identifiers is left to IdPs, not imposed by the browser.) FedCM also already provides for user choice with respect to identity. For example, if a user has multiple identities with the same IdP (e.g., a work profile and a personal profile), FedCM provides a way for the user to select which one they want to use to log in to the RP's site. Beyond that, each RP decides for itself which IdPs to support on its site. One aspect of that decision is considering the mechanism that an IdP relies on, whether that's FedCM or a different technology. Again, the browser does not dictate these choices for RPs or IdPs. |
Fight spam and fraud
Private State Token API
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Handling Bots | What happens if the issuer discovers that Private State Tokens have been issued to bots? | To avoid tokens issued to bots from remaining in the ecosystem for a long time, issuers should rotate the keys they use to sign tokens regularly so that old tokens issued under potentially broken issuance logic expire and sites redeem newer tokens with updated issuance logic. |
| Same-site form submissions | Could Private State Tokens be used for same-site form submissions that involve full-page navigation (i.e. Content-Type: application/x-www-form-urlencoded) rather than a request from the fetch/XMLHttpRequest APIs? | This isn't currently supported in the first version of Private State Tokens. We welcome feedback from the ecosystem if there is a strong demand for this use case. |
| Server-side verification | Questions on whether Private State Tokens can be verified server side | Tokens are redeemed against the issuer, and then the issuer creates a redemption record that could contain the token itself or some signed value derived from the token, servers can use that redemption record to verify the authenticity of the token, and we expect different issuer ecosystems will come up with different standards for how to interpret their redemption records. |
Updated on • Improve article