Feedback Report - 2023 Q2
Quarterly report for 2023 Q2 summarizing the ecosystem feedback received on Privacy Sandbox proposals and Chrome's response.
Published on
Robert Yang
Robert is a Senior Partner Technology Manager at Google
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 (refer to 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, Protected Audience, 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
- TEE
- Trusted Execution Environment
- 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 |
|---|---|---|
| Data Governance & Regulatory Compliance | Ecosystem guidance on using Privacy Sandbox in compliance with regulatory requirements. | As with any new technology, each company is responsible for ensuring that its use of the Privacy Sandbox complies with the law; Google is unable to provide others with legal advice. We are aware, however, that this is a key area of interest for the ecosystem. For each API, we have published extensive technical documentation, which should provide the basis to make necessary legal assessments, and we are working on making available additional materials in support of companies' efforts to comply with regulatory requirements. |
| CMA Quantitative Testing proposal | More information on the CMA quantitative testing proposal | We are working together with the CMA to design experiments that will provide a picture of the impact of third-party cookie deprecation and the introduction of the Privacy Sandbox proposals on the ecosystem. In April, the CMA published high-level guidance on what to expect during the Testing and Trialing period followed by detailed guidance in June. We encourage questions or feedback on the CMA's Quantitative Testing proposal to be shared directly with the CMA. |
| Chrome-facilitated testing modes | More information and clarification on the testing schedules | We published a blog post on May 18 sharing more information on the two modes of Chrome-facilitated testing. These details are not final, and we'll publish further implementation guidance as we progress in Q3 2023. |
| Partitioned Storage | Will partitioned storage be used during Chrome-facilitated testing? | Storage partitioning will be shipping to all users prior to the third-party cookie deprecation experiment. Therefore it will be enabled for all arms of the experiment. Sites will have the option of enabling a deprecation trial to get back unpartitioned storage during this time period. |
| Production support | What is the process in place for Chrome to support Privacy Sandbox technical issues and escalations affecting the ecosystem? | Google provides a range of channels to allow ad techs to report issues and enable any necessary escalations. Please see our developer post for more information on the public and private forums for feedback and escalation. |
| Enrollment Timeline | The current timeframe for enrollment is too short | We are still evaluating the enforcement deadline and we would like to hear from the ecosystem on what timeline would be more suitable. |
| D-U-N-S Number | More information about the D-U-N-S number requirement for Enrollment and Attestation | Participants can find the requirements for obtaining a D-U-N-S Number on the Dun and Bradstreet website. The requirements vary depending on the market, so participants should be sure to check the website for the specific market they are interested in. In general, however, participants will need to provide basic information about their business, such as the name of the business, the address, and the contact information for the business owner or manager. Participants may also be asked to provide financial information, such as the business's annual revenue. Once the application is complete, D&B will review it and issue a D-U-N-S Number if the application is approved. |
| Transitioning from Origin Trial to General Availability | Will the transition from Origin Trial to General Availability affect current Origin Trial testers? | From July, testers will be able to access the relevance and measurement APIs in general availability. This will provide an overlap between origin trial availability and general availability. |
| AdExchanger Study | More information on survey methodology | The survey asked respondents to estimate sync rates and revenue for their businesses. Respondents' methodology for answering their individual questions was up to them. |
| Parameter values | How are parameter values such as noise level, anonymity thresholds, and privacy budget determined? | This GitHub explainer sets out the more general principles behind the Privacy Sandbox APIs. Many values are still being finalized and we welcome feedback on this subject. |
Show Relevant Content & Ads
Topics
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Privacy Preservation | Research evaluating the Topics API on privacy preservation | We are actively involved with the research community, presenting our research on the privacy properties of the Topics API in papers, reports, and workshop presentations. We are happy to see more external members of the research community engaging with this area. The Topics API protects users against general tracking on the web by making it too difficult to track users at scale. These papers show that we're successfully doing so with the Topics API. It's more private than third-party cookies and protects users while supporting the sites they enjoy visiting. |
| Topics taxonomy not granular enough | Broad topics taxonomy does not include more granular topics, including region specific. | In response to previous feedback from the ecosystem, we published a blog post on June 15 detailing a new updated taxonomy that incorporates numerous improvements following feedback from the ecosystem. As part of our work on the revised taxonomy, we've engaged with several companies across the ecosystem, such as Raptive (formerly CafeMedia) and Criteo. The updated taxonomy removes categories we've heard are less useful, in favor of categories that better match advertiser interests, while maintaining our commitment to exclude potentially sensitive topics. We encourage the ecosystem to review the latest taxonomy and provide feedback on the changes. |
| Taxonomy and classifier update process | More information on the Topics taxonomy and classifier release cadence and how companies can prepare for such updates. | As shared in the recent blog post, we expect the taxonomy to evolve over time, and for governance of the taxonomy to eventually transition to an external party representing stakeholders from across the industry. We also shared the ramp-up plan in the topics-announce group. |
| Impact on first-party signals | The increase in number of Topics in the recent Taxonomy update may be highly valuable and as a result devalues other first-party interest-based signals. | In the Q1 2023 report, the CMA commented that "We understand that Google has been discussing its proposed new taxonomy with several market participants across the ad tech supply chain. While a few large publishers have said that greater utility of topics would increase competitive pressure on their first-party data based solutions, our preliminary view is that greater utility is better for competition overall – in particular for the ability of smaller publishers to continue monetising their inventory after the deprecation of third-party cookies". Our view is aligned with this comment made by the CMA. |
| Usefulness for different types of stakeholders | Ad techs that act as SSPs and DSPs may have significant advantages over other ecosystem players. | Our response is unchanged from previous quarters: "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." |
| Descendant Topics | With Topic selection criteria being frequency of browser visits, will segment fragmentation lead to descendant topics never rising to the top? | Chrome is currently evaluating other ranking methodologies, and exploring other signals that may improve ranking. We will communicate our revised plans to the ecosystem in due course. |
| Sensitivity | The Topics API's goal should be to ensure user information obtained or derived from the Topics API should be less personally sensitive than what could be derived using today's tracking methods. | We believe the Topics API is significantly more private than current technologies, significantly limits re-identification of users, and is designed to exclude sensitive topics. We acknowledge that topics can be correlated or combined with first-party data to create sensitive categories, but we believe the Topics API is a step forward to user privacy and we are committed to continue improving the API. |
| Taxonomy Structure | Add ID, Versioning, and other metadata structure to the Topics Taxonomy | Currently, in the API response, we are including the taxonomy ID. As we move towards long-term governance, it makes sense to review the Topics object and include additional metadata on versioning if required. |
| Publisher control | Publishers should have a say in what Topics their sites should be classified as. | Misclassification of sites may make the Topics signal slightly less useful as a signal overall, but the specific sites that are misclassified are no more and no less harmed by this than any other sites. This is because a site's contextual information will always be available for auctions on their site, which would provide comparable information to the correct topic, even in the case of misclassification. We welcome feedback on this subject here. Allowing publishers to control their classification has risks. Sites may incorrectly classify their sites intentionally, reducing utility for all, or encode sensitive meanings in less common topics, harming user privacy. |
| Chrome extensions | Allow Chrome Extensions to manage and filter Topics, similar to current Cookie Management extensions | This should already be possible, as discussed on GitHub, but we welcome additional feedback from the ecosystem. |
| Transition to General Availability | Will there be any impact on the Topics API when transitioning from Origin Trial to General Availability? | There will be no data lost for users transitioning from Origin Trial to General Availability. |
| Privacy | Host Names may contain private information that may be revealed by the Topics API | We have a number of mitigations to ensure privacy, as outlined here. |
| Fraud and Abuse | How to prevent manipulation of Topics by fraudulent visits | Mitigations are explained here. |
| Topics classifier | Can websites request to alter their Topics classification? | We are interested in hearing from the ecosystem on this topic and welcome feedback here. |
| Topics provider sites | Designate certain websites that host content for many Topics as "Special Topics Provider Sites" and train classifiers based on tags provided on the web pages. | We are discussing the proposal here, and welcome additional feedback. |
Protected Audience API (formerly FLEDGE)
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Traffic Shaping | Performance impact of SSP-driven filtering to optimize queries-per-second (QPS) load | We have spent a considerable amount of time thinking about traffic shaping and the recommendation is for SSPs to take advantage of caching. |
| Testing volume | Challenging to test Protected Audience as SSPs and DSPs are struggling to get large traffic volumes. | We are constantly engaging SSP and DSP partners to adopt and test Protected Audiences. General Availability has begun and we are confident the percentage of traffic with PA enabled will make it more palatable to partners to test. |
| Complexity | Implementing Protected Audience solutions requires substantial effort and costs. | We acknowledge that new technologies are difficult to adopt, including Privacy Sandbox. The Privacy Sandbox team is working closely with a wide range of stakeholders to educate and support their efforts and are continuously evaluating other accelerants to support ecosystem adoption. |
| Trusted Execution Environments | Support for Trusted Execution Environments (TEE) in non-public cloud environments | While we are exploring potentially supporting options beyond cloud-based solutions, it is not currently feasible to support on-premise TEEs given on-premise security limitations that would require a time-consuming evaluation for Privacy Sandbox. Given Privacy Sandbox security requirements and the significant challenges presented by on-premise deployments, we believe that continuing to expand and improve cloud-based deployments (e.g. supporting GCP in addition to AWS) is the most beneficial for the ecosystem. However, we welcome additional feedback on why such a requirement is necessary. |
| Cost Structure | Bidding & Auction Services proposal will increase cost and complexity for Ad Techs compared to client-side models. | We are currently developing a guide for estimating costs of supporting bidding and auction workflows in the Bidding & Auction server, which will be correlated with ad-tech usage, fulfilling one of the goals of our designs. |
| K-Anon Timelines | When will the planned k-anonymity constraints be enforced on `renderUrl` ? | We are working on an explainer for the enforcement timeline that we will release soon. |
| runAdAuction restrictions | Can Chrome restrict runAdAuction to only be callable from the top page? | While our design fully supports runAdAuction to be callable from the top page, we believe it would be more harmful for publishers to restrict it to only be callable from the top domain.We have specifically heard from the ecosystem that the Privacy Sandbox needs to minimize the burden on publishers and advertisers. That feedback aligns with the general principle of web development that site owners can use third-party tools in running their sites. The Privacy Sandbox goal has been to encourage a healthy ecosystem without needing to prescribe how publishers and ad techs work. By allowing the publisher to choose how and who calls runAdAuction on their site, we believe we offer flexibility to publishers to find the best path for their requirements. |
| Implementation support | Can Chrome build or contribute to an open-source implementation of a multi-seller auction? | The Privacy Sandbox aims to develop privacy-preserving technologies that don't rely on third-party cookies or other cross-site identifiers. We want to encourage a healthy ecosystem without needing to prescribe how ad techs need to work. We have published guidance on how the APIs work on our GitHub repository and are open to exploring solutions with the industry. We do not plan to build any specific implementation as our core remit is to build platform technologies, not to dictate strategies for using those technologies. Our technologies will help enable ad tech companies to best serve their customers with the right privacy guardrails for consumers. |
| Multi-seller auctions | Will Chrome force sharing a "contextual" winner with component auctions? | The Protected Audience API is designed to offer the ability for parties initiating the multi-seller auction to pass information to the component auction (note: only prior to initiating the auction). That said, we see no way for the browser to distinguish whether a piece of information is a contextual winner or not, so we could not enforce blocking or requiring certain information. |
| User preference for consent tracking | Adtech asking PA how to implement user consent tracking correctly | Our response includes what we said in Q1: "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." We discussed a number of scenarios related to this issue during the May WICG Protected Audience Meeting and we welcome additional feedback and discussion on this issue. |
| Custom Audiences | Will SSP use cases related to creating Custom Audiences be supported by the Protected Audience API? | The Protected Audience API allows for SSPs and other ad-tech providers to own and manage Custom Audiences. Further guidance on how an SSP can integrate with the PA API is being developed and will be made available for SSPs and other ad tech providers to support their integration efforts. |
| Formats | Is video supported by the Protected Audience API? | Video ads are delivered in one of two ways: as VAST XML or HTML (an outstream ad that ultimately may load VAST XML into a video player as well). Buyers can return either format via a renderURL. The VAST specification was recently updated to support the Attribution Reporting API. Sites serving video ads will need to prepare for the way ads are delivered via the Protected Audience API. This means making sure placement tags can pass the URL from a Protected Audience iframe to a video player. For Fenced Frames we will work to address video needs ahead of the requirement to use Fenced Frames which is no sooner than 2026. |
| Pacing | How does Pacing use case work with the Protected Audience API? | We appreciate the feedback. We would be interested in seeing more instances of this request with more details coming from more SSP partners as this has been mostly a DSP concern to date. |
| Update frequency | The frequency of calls from dailyUpdate (up to 1 per interest group per day) may not be enough for certain use cases, such as updating product information. | We appreciate the feedback. There are other solutions available for allowing ad techs to use signals that are refreshed in different cadences like K/V lookups. |
| Ad Quality Control | How do publishers implement ad quality control? | Today, the Protected Audience API offers functionality for publishers to inform their SSPs on certain controls they can establish as part of the auction config, pre-bid (i.e. denylists based on labels associated with ads). We welcome feedback on any additional functionality the ecosystem may require. |
| Debugging | When will forDebuggingOnly functionality be removed? | We plan to retire forDebuggingOnly for loss events by third-party cookie deprecation. We plan to retire forDebuggingOnly for win events in 2026 at the earliest. |
| Cross Device Interest Groups | Proposal to enable cross-device interest groups for authenticated user agents | We are evaluating this proposal, but the high specificity of cross-device targeting poses significant privacy concerns, as discussed in this GitHub Issue. |
| (Also reported in Q1) Dynamic Remarketing | Will Dynamic remarketing still be possible with the Protected Audience API after third-party cookie deprecation? | We believe this use case is possible using Protected Audience, as explained here. |
| Click related data | Add click-related data to browserSignals. | We are currently asking for clarification on when the click happened to give a preliminary position. |
| (Also reported in Q4 2022) User defined functions in Protected Audience | How will user-defined functions (UDF) be supported in the Protected Audience API? These are functions that can be programmed by end users to extend the functionality of the API. | The ad tech who raised this issue also mentioned they are still evaluating what they could do with UDF so there is no actionable feedback here yet to react to, not until at least General Availability. |
| Currency | Currency amounts should not be represented using floating points. | We addressed this issue in detail here. |
| Non-DSP ad selection capabilities | What role do Ad Servers play in Protect Audience API auctions? | We are aware of the requests for Ad Servers to continue offering post-bid ad selection / dynamic creative optimization services. We are currently assessing the detailed gap analysis that exists between the current Protected Audience API and these requests. |
| GenerateBid | Support for Google Ads' proposal to return more than one candidate ad per ad interest group from generateBid and have those candidates scored in `scoreAd`. | This is being currently evaluated. We welcome additional feedback here. |
| Auction Order | Are Protected Audience API Auctions required to be the last one to run so that it can take input from the outcome of all other auctions? | There's no technical requirement for the Protected Audience API to run last. |
| Non-user initiated navigation | Expose non-user initiated navigation | We are reviewing this request and discussing it here and welcome additional feedback. |
| Caching | SSP should not build a given DSP's perBuyerSignals from a cache if the user state changes. | We understand that caching does not work for every use case for perBuyer signals and are evaluating further options. We welcome any additional feedback from the ecosystem on whether caching would work for their use cases. |
| Attribution Reporting and Protected Audience | How can the Attribution Reporting API and the Protected Audience Audience API work together? | Integrations are currently available for Protected Audience API for both Attribution Reporting API modes (event-level and summary reports). We have shared more information on improved Protected Audience API and Attribution Reporting integration on June 1. You can read about them here. |
| Server Endpoint | Will the server endpoint be the Trusted Aggregation Server in the final design? | The server endpoint is an ad tech maintained endpoint that is independent from the Trusted Aggregation Servers used to process the collected and transformed reports. We don't have any changes planned for the reporting endpoint at the moment. The current design aims to ensure that the aggregatable reports themselves (with encrypted payloads) don't leak cross-site data, so a trusted endpoint shouldn't be necessary. An additional complication is that different ad techs will likely have different desired batching strategies. We welcome additional feedback here. |
| WebIDL | The current Protected Audience API spec is not compatible with WebIDL spec. | We are evaluating this feedback and discussing the issue here. |
| Consent Management | How will consent signal passing be handled in the Protected Audience API? | Contextual information is not within the scope of Protected Audience API. We are discussing this issue and welcome additional feedback. |
| Account Based Marketing | Would account-based marketing use cases be possible? | Protected Audience API supports a variety of audience-based marketing use cases. We are continuing to understand how Protected Audience API can best support this particular use case, and welcome additional feedback on this issue from the ecosystem. |
| Component auction | What do component auction participants score? | The component auctions don't score Interest Groups directly – rather they score the ads and bids that a DSP submits from the generateBid function. The generateBid() function runs per interest group, and the DSP returns the following when executing generateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| External Contributions | Request to support external contributions on the Key/Value Server GitHub code base. | We are looking to update our relevant processes to support external contributions to the GitHub code. |
| Interest Group Size | What is the supported maximum number of keys the IG can support? | The current limit is 50 kb on the size of one IG and keys count as part of that. We welcome further discussion on the size limit. |
| Batching | How can the number of K/V server calls be reduced? | You can use HTTP Cache-Control Headers to reduce the number of K/V calls. For example, it could be cached across component auctions, and also across ad slots on a single page. |
| Version control | Support for multiple versions of ad-tech code | Bidding and Auction services will support multiple versions of ad-tech code. In the Bidding and Auction API, the SelectAd request can specify the version of the code used for the auction request (i.e. for bidding / auction and also reporting). |
| Shared Storage | Support writing to Shared Storage in the Bidding and Auction Service. | Currently, Bidding and Auction Services does not support Shared Storage, but we welcome additional feedback on why such use cases are important to the ecosystem. |
| Web-to-app | Support web-to-app sharing of interest groups. | Web-to-app is not currently scoped in the Protected Audience API deployment across Chrome and Android, but we are interested in hearing from the ecosystem on the importance of this use case. |
| K-Anonymity | How to handle K-Anonymity fallbacks | We are discussing the issue and welcome additional feedback. |
Measuring Digital Ads
Attribution Reporting (and other APIs)
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Alternative VTC Event Level Report Configurations | Feedback on Alternative VTC event-level report configurations | We've heard some feedback that the current event-level configurations are not optimal and we are asking for feedback on optimal global configurations. We are open to additional feedback regarding this and think that our flexible event-level explainer helps to address this as well. |
| Flexible event-level configurations | What is the status of the flexible event-level configurations feature? | We have shared documentation on flexible event-level configuration. The feature is still in the proposal stage and we are looking for more feedback on whether the feature will be valuable to the ecosystem. |
| Flexible event-level configurations | How can conflicting reports from different parties be reconciled? | Most reporting scenarios are addressed through the use of aggregate reports, whereas the flexible event-level configuration proposal is specifically for additional flexibility for event-level reports, which are most often used for optimization use cases. We welcome any additional ecosystem comments/feedback regarding this scenario. |
| Source registration | What if the source registration happens after the trigger registration? | Currently, if a source registration occurs after the trigger registration, then the source and trigger will not be able to be attributed to each other. This seems to be an edge case scenario. We welcome any additional feedback regarding this issue and will look to address it if it's a scenario many ad techs seem to face. |
| Working with multiple Ad Agencies | How can DSPs use the Attribution Reporting API when an advertiser is working with multiple ad agencies? | The API supports redirects and therefore can be used even when an advertiser is working with multiple ad agencies. Additionally, there are some limitations in place regarding redirects in order to ensure that the API is improving privacy. We have also identified a potential workaround utilizing the Shared Storage API for the specific scenario the ad tech has raised. We welcome any additional feedback regarding this scenario and will continue to iterate based on that feedback. |
| Destination Limits | The auto-refreshing ads use case may be impacted by having destination limits. | We discussed this issue in the May 1 WICG meeting and are looking for feedback on what a reasonable limit would be. We have added to the Attribution Reporting with event-level reports explainer stating that browser can limit the number of `destination` eTLD+1s represented by source-sites. (See pull request). |
| Attribution Reporting and Protected Audience | How can the Attribution Reporting API and the Protected Audience Audience API work together? | Integrations are currently available for Protected Audience API for both Attribution Reporting API modes (event-level and summary reports). We have shared more information on improved Protected Audience API and Attribution Reporting integration on June 1. You can read about them here. |
| Flexible event-level configurations | Share best practices for noise simulation now that the parameters are configurable. | We have shared code on GitHub that anyone can use to assess the information gain and noise impact for whatever flexible event-level configs they want to test. We would be interested in hearing from anyone who chooses to test with the code and would like to share feedback. |
| Cross App and Web Attribution Measurement | When will cross-app and web attribution measurement be available? | We announced on May 9 an experiment for Cross App and Web Attribution Measurement via the Attribution Reporting API. While General Availability is planned for the relevance and measurement APIs in Chrome 115, Cross App and Web Attribution Measurement is not currently planned to hit general availability with Chrome 115. |
| Deduplicate conversions | How can independent measurement solutions be reconciled against ARA? | As with current standard practice, advertisers would work with a third-party independent measurement provider to de-duplicate conversion reporting. We have offered resources on how to deduplicate conversions for event level reporting. |
| Data loss during Attribution Reporting database updates | Will there be any data loss when Chrome updates the Attribution Reporting Database as announced? | Starting with Chrome Stable 115, we will begin enabling the Relevance and Measurement APIs for a portion of Chrome users by default. This general availability will ramp up as we monitor for potential issues. The goal will be to reach 100% availability over a period of weeks, by Q3 2023. This will coincide with the end of the Relevance and Measurement origin trial. Starting in July, testers will be able to enroll for access to these APIs in general availability. This will provide an overlap between origin trial availability and general availability through enrollment. Your origin trial token will be valid until September 19, but we recommend you enroll for the APIs before the expiration in order to transition seamlessly out of the origin trial without interrupting any ongoing tests. As mentioned in this announcement, the data registered from older versions (M113 and earlier) will not be migrated after the update, therefore there may be a data loss. This data loss won't show up in debug reporting, and we will try to avoid data loss from 114 to 115. |
| Billing | Using Attribution Reporting for cost-per-conversion billing | As stated in this article, the Attribution Reporting API may not be suited for cost-per-conversion billing needs, because of the noise added to event-level and summary reports. We encourage ecosystem players to share feedback about the impact on various billing models by the Attribution Reporting API on GitHub. |
Aggregation Service
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Aggregatable report delay change | Positive reactions to the proposal to change the Aggregatable report delay to be from [10-60 mins] to [0-10 mins] following feedback from the ecosystem | We are pleased to see positive reaction to the proposed change, and encourage the ecosystem to continue providing feedback on our proposals. |
| On-premise solution | Can the Aggregation Service be deployed in on-premise data centers? | While we are exploring potentially supporting options beyond cloud-based solutions, it is not currently feasible to support on-premise TEEs given on-premise security limitations that would require a time-consuming evaluation for Privacy Sandbox. Given Privacy Sandbox security requirements and the significant challenges presented by on-premise deployments, we believe that continuing to expand and improve cloud-based deployments (e.g. supporting GCP in addition to AWS) is the most beneficial for the ecosystem. However, we welcome additional feedback on why such a requirement is necessary. |
| Reprocess reports for different time periods | Ability to reprocess reports for different time periods | We have heard similar requests to be able to split up batches for different date ranges. One proposal is to allow the ability to extend the shared ID with an ad tech-defined label so that reports may be split into different batches. We are in the early process of evaluating this process and will keep the ecosystem updated as this proposal evolves. |
| Privacy Implications of Trusted Execution Environment | Positive sentiment towards privacy implications of Trusted Execution Environments | We are pleased to hear of positive reactions from the ecosystem regarding our proposals, and we welcome additional feedback as we continue to iterate and develop. |
| Terms of Service | What is the deadline to accept the Aggregation Service terms of service? | While we have not yet specified a deadline to accept the terms and conditions, we would encourage ecosystem companies to accept the terms and conditions as soon as possible in order to prevent delays in enrollment. We encourage companies to reach out if they have any questions. |
| Key Discovery | The key discovery feature will enable testers to query aggregate reports without needing the explicit list of possible key combinations in order to process summary reports for cross-network attribution for improved performance and accuracy. | We are currently exploring possible solutions and workarounds and welcome additional feedback from the ecosystem. |
Private Aggregation API
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Reporting Origin | How is reporting origin defined? | Reporting origin is always the script origin of the Private Aggregation caller. |
| 128 bit key space | Clarity on the 128-bit key space limitation | We will make this keyspace limitation more clear and resolve the inconsistencies across pages. We recommend using hashing strategies to stay within this keyspace. |
| Maximum contribution per report | Current limit of 20 contributions per report is too low. | Rather than increasing the maximum number of contributions, we are open to considering splitting reports rather than truncating at the limit. We will engage the ecosystem as this proposal evolves. |
| Reach reporting | Request for reach cross-platform/cross-device reporting. Reach is a foundational metric of brand advertising. Advertisers rely on cross-platform/cross-device approximations for Reach and Frequency reporting to analyze their campaigns and allocate spend. Reach models use third-party cookies as a signal for measuring ads shown in third-party environments, and so ad techs have requested an alternative solution once third-party cookies are deprecated. | The Privacy Sandbox team is exploring features to support cross-domain reach methodologies after third-party cookie deprecation. We welcome additional feedback from the ecosystem. |
Limit Covert Tracking
User Agent Reduction/User Agent Client Hints
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| (Also reported in Q1 2023) Hints for additional form factors | Request for User Agent Client Hints (UA-CH) to provide additional form factors such as TV, VR | We are still working on some key design decisions (whether to provide a single value such as "TV", or a list of form-factor capabilities), but remain interested in prototyping this idea. |
| Privacy Budget | Privacy Budget restrictions could cause UA-CH requests to become non-deterministic when too many requests are sent. | We have no new updates on the Privacy Budget proposal at this time, but we have committed to not restrict requests for UA client hints before third party cookies have been deprecated. |
| Site Compatibility | Websites are using UA-CH brand to restrict certain browsers from accessing sites. | There are valid use cases for having a brand list, and one of them is precisely compatibility. A UA is free to have multiple brands to work around these issues. |
IP Protection (formerly Gnatcatcher)
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Fraud & Abuse | How can companies set up anti-fraud measures with IP Protection? | We understand the importance of anti-fraud use cases and the possible impact to those use cases. We plan to publish more details about supporting anti-fraud later this summer. We are seeking ecosystem feedback on how we can better support anti-fraud use cases. |
| GeoIP | More information on testing and deployment timeline for GeoIP | Chrome has recently published new information detailing our GeoIP plans. We are planning to publish more information about deployment timelines in Q3. We expect to launch IP Protection as a user opt-in feature on a small percentage of traffic initially. The reason for this is that we recognize that this proposal may involve some significant changes for companies, and we want to give the ecosystem time to adjust and provide feedback before the feature is rolled out more broadly. |
| Account authentication | How will account authentication with the proxy server work exactly? | We plan to publish more details about account authentication later this summer, though we have shared some initial considerations already. |
Bounce Tracking Mitigation
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Testing Guidance | Information on how to test Bounce Tracking mitigation | We published a blogpost in May with further information on how to test Bounce Tracking Mitigation. |
| Documentation | Clarity in the Bounce Tracking Proposal | The current proposal is very much a work-in-progress and Chrome is continuing to update the proposal to provide clarity and information to the ecosystem. We are working on providing more details and welcome any additional feedback. |
| Cookie deletion | Will Bounce Tracking Mitigation delete all cookies in a domain? | Bounce tracking mitigation (BTM) will clear all storage and all cache, as explained here. |
| Circumventing Bounce Tracking Mitigation | Bounce tracker classification may be bypassed by performing redirects with pop-ups or new tabs. | The Bounce Tracking Mitigation specification is still a work in progress. We've been mostly focused on same-tab redirections so far but we plan to work on pop-up flows in the future. We welcome additional feedback here. |
Privacy Budget
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Proximity Targeting | Privacy Budget may impact proximity-targeting use cases. | We have received feedback on this issue and would be interested in hearing more on the potential impacts from the ecosystem. |
Strengthen cross-site privacy boundaries
First-Party Sets
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| (Also reported in previous quarters) Domain Limit | Request to expand the number of associated domains | Chrome is evaluating the appropriate numeric limit for the Associated subset that will balance privacy and utility for the use cases that have been identified. From the very outset, Chrome shared that the exact number for the Associated subset was yet to be finalized. |
| Embedded Use Case | Support for Embedded use cases that require First-Party Sets, CHIPs and shared storage | Chrome has received the feedback on this use case, and the team is investigating and welcomes additional feedback. |
| Repository Management | Information on policies to remove First-Party Sets from the GitHub repository if there are discrepancies or neglect | Chrome has received the feedback on this use case. The team is investigating and welcomes additional feedback. |
| User Education | Chrome should increase user awareness and understanding of First-Party Sets to drive adoption. | Chrome is committed to educating users about First-Party Sets, and has published a Help Center article (linked from the Chrome UI) to this effect. Chrome is also invested in continuing to learn how to best educate users in the appropriate contexts. |
| Post 3PCD | Third-party cookies will continue to exist within a First-Party Set after third-party cookie deprecation. | While requestStorageAccess and requestStorageAccessFor do indeed make third-party cookies available again for specific, clearly-defined use cases, they now require active invocation by the site, instead of being available by default, as with the current state of third-party cookies (in Chrome).While this invocation within a single set will not require user approval, users have the ability to prevent this by opting-out of this behavior in Settings. Further information is available to users in the Help Center article (linked from the Chrome UI). We plan to expand upon the existing developer guide as FPS ramps up to 100%. |
| First-Party Sets submission | Rename the required .well-known/first-party-set to include a .json extension. | We have made this change to ensure certain web hosting plans are supported. |
| IANA Registration | first_party_sets.JSON should be registered with IANA | We are considering the proposal and welcome additional feedback here. |
Fenced Frames API
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Ad Blocking | Fenced Frames may make it easier for ad blockers to block ads. | Extensions can interact with fenced frames similar to how they would interact with iframes. The actual URL that the fenced frame is about to be navigated to will also be visible to extensions and therefore they can apply any URL matching rules for blocking as they would in iframes. Simply blocking all fenced frames unconditionally might break non-ads use cases of fenced frames. |
Shared Storage API
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Wider adoption | Shared Storage should be an industry-wide standard available across browsers. | We welcome and acknowledge this feedback. Chrome is continuing to actively participate in W3C fora to champion the proposal, seek feedback, and drive adoption. |
| Output Gates | Shared Storage output gates are too limited. | We are considering this feedback and welcome additional ecosystem feedback on why the output gates are too limited. |
| Regulatory Compliance | How will Shared Storage handle regulatory compliance such as data retention policies? | Shared Storage provides the flexibility to implement and customize logic to control the lifetime and expiration of any stored data. Ad techs can update or clear Shared Storage data on the basis of write timestamps. |
| A/B Testing | How can A/B testing for Shared Storage and Protected Audience API be conducted? | We are working to publish additional guidance on this matter and hope to share more details in the future. |
| Shared Storage Limit | What will happen once the Shared Storage limit is hit? | If the limit is reached, no further inputs will be stored. |
| Multiple access on the same page load | What happens when Shared Storage is accessed multiple times on the same page load? | The best way to handle this is through the window.sharedStorage.append(key, value) function. Rather than updating the value for each ad, which could cause collisions if there are multiple ads. The append function will just add the new value to the end of the preexisting one. |
| iframe Functionality | Will Shared Storage support certain iframe functionality once they no longer work after third-party cookie deprecation? | Post third-party cookie deprecation, local storage in iframes will be partitioned by the top-level site but the iframes themselves won't be blocked. The data in an iframe's local storage can't be replicated across multiple top level sites, but the local storage can still be used within the iframe. |
CHIPs
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Partition limit | 10 KiB per partitioned site is still substantial and would like to see it lowered. | Firefox has already indicated a positive position on CHIPS. For Webkit support, we encourage developers to provide feedback to Apple directly on this GitHub issue regarding their use cases where partitioned cookies are preferred over partitioned storage. |
| Authenticated embeds | CHIPs may affect current SSO sign-in flow due to different partitioning impacting authenticated embeds. | We intend to leverage the Storage Access API (with user prompts) to support the authenticated embeds use case, and recently sent an intent-to-prototype. |
| Lifetime Policies | Will potential lifetime policies apply to first-party cookies? | We currently have no plans to impose lifetime limits on first-party cookies. |
FedCM
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| OAuth Authorization Support | Align on authorizing non-profile Oauth scopes | We are actively seeking input from the Web Identity community through the W3C FedID CG on the best ways to support authorization beyond basic authentication post third-party cookie deprecation. |
| Support for SAML | Align on requirements for SAML support | The team is actively seeking input from the research and education communities on SAML support needs (in addition to OpenID-connect support) post third-party cookie deprecation. |
Fight spam and fraud
Private State Token API (and other APIs)
| Feedback Theme | Summary | Chrome Response |
|---|---|---|
| Exploring new signals | Several partners have expressed positive sentiment towards exploring browser-facilitated signals of device integrity or user trust. Generally, they are also cautious about new purpose-built signals being sufficient to retain current levels of fraud detection. | We are excited to explore new proposals together within the anti-fraud and web safety community, and also acknowledge and share their concerns - this is exactly why "fighting spam and fraud" has been a core workstream of Privacy Sandbox and why we continue to prioritize investment in preserving web safety as we improve user privacy. |
| Positive feedback on PST | Several partners have expressed interest in testing or utilizing PSTs for various anti-fraud or web safety use cases. | We are excited to hear support and interest in further exploring new solutions which utilize PSTs. We have resources and sample code available through the Chrome developer site, and welcome further feedback. |
| Fraud and Abuse | Guidance for Ad Fraud Prevention / Detection in measurement after third-party cookie deprecation when identifiers are no longer available. | We have introduced tools such as private state tokens, which help to recover some of the signal lost by third-party cookies for anti-fraud purposes, but with new privacy controls in place. We are actively investing in new anti-fraud and anti-abuse proposals to preserve capabilities with other Privacy Sandbox changes. |
| Issuer to origin information rate | Issuer-to-origin information rate is high enough to identify unique users. | We have updated the spec to be more clear about what user data is able to be conveyed using Private State Tokens. By design, up to six public keys can be used at a time, which may represent a "state" for a particular user. These sets of keys can only be updated every 60 days (except in rare cases where an emergency key rotation is necessary), which slows down the potential to join additional user data over time. With any new web API, there is a balance of utility provided and net new user information that it provides. We estimate that PSTs strike the appropriate balance in protecting user privacy while enabling key anti-fraud use cases impacted by third-party cookie deprecation. |
| Fetch Integration | The fetch integration is complicated and unnecessary. | There are pros and cons to utilizing fetch, and we would like to pursue further standardization within the web ecosystem, but we think it would be too early to make this change until we have a clearer sense of what the standard will look like. If and when a standard emerges, we are also committed to responsibly transitioning web developers to that standard. |
| Storage Location | Private State Tokens key configurations should be stored in the same location as PrivacyPass Protocol. | While testing during the Origin Trial, developers indicated they preferred the flexibility to store their keys at general URLs instead of in a .well-known directory. The key commitment format in PrivacyPass isn't particularly suited for a version where the keysets are intended to allow for an implicit "public metadata" value. If a variant of PrivacyPass ends up getting standardized with public metadata (either as a POPRF, partial RSA blinding, or keysets) we might move to a future version of PST to support that. |
| Header implementation of the API | Questions regarding the header implementation of the API | As the API gets standardized and the ecosystem usage of this API matures, we can hopefully either support both the standard non-header version of this API and potentially eventually deprecate the header version if usage is low enough or there's enough developer tooling/support for standard ways of correlating issuance/redemption requests with other data. We are discussing the issue here. |
| Registration | Is making issuers register with browser vendors practical? | We have updated the specification to describe the issuer registration process for Private State Tokens. While it uses its own process, it is similar to enrollment plans for the rest of the Privacy Sandbox work, where we ask issuers to make a public statement for how they intend to use PSTs and to acknowledge the technical restrictions which protect user privacy. |
Published on • Improve article