Feedback Report - 2022 Q1

Quarterly report for 2022 Q1 summarising the ecosystem feedback received on Privacy Sandbox proposals and Chrome's response.

Published on

Translated to: 日本語

As part of its commitments to the Competition and Markets Authority, 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 and technologies.

Feedback received recently may not yet have a considered Chrome response.

Glossary of acronyms

W3C
World Wide Web Consortium
PatCG
Private Advertising Technology Community Group
IETF
Internet Engineering Task Force
DSP
Demand-side Platform
SSP
Supply-side Platform
OT
Origin Trial
UA
User Agent string
UA-CH
User-Agent Client Hints
IP
Internet Protocol address
WIPB
Willful IP Blindness
IAB
Interactive Advertising Bureau
openRTB
Real-time bidding
CHIPS
Cookies Having Independent Partitioned State
FPS
First Party Sets
FedCM
Federated Credential Management
IDP
Identity Provider

Common themes from all feedback sources

A common theme across our discussions and feedback channels is questions about the timing, traffic levels and availability of testing. In particular, testers have consistently wanted confirmation of when APIs will be available for testing and whether testing will be available globally.

To address this feedback, Chrome has communicated broadly, and Chrome will post an FAQ confirming the same, that testing will be available globally. Furthermore, Chrome will continue to update public timelines in consultation with the CMA regularly.

Show relevant content and ads

API / TechnologyFeedback Theme

(Ranked by Prevalence)

Questions and Concerns SummaryChrome Response
TopicsUsefulness of coarse-grained topicsConcerns have been raised that the coarse-grained topics taxonomy may not be useful enough for interest-based advertising.The usefulness of the API will be explored through testing. Chrome expects the taxonomy to evolve based on testing results.
TopicsTaxonomyIndustry stakeholders wish to have a voice in influencing the taxonomy.Chrome remains open to input on the taxonomy. Chrome is very interested in feedback on the governance model for modifying the taxonomy, and discussion of how other industry bodies can play a more active role in developing and maintaining the taxonomy in the long term.
TopicsUsefulness for different types of sitesConcerns have been raised about the usefulness for sites depending on their level of traffic or how specialized their content is.The usefulness of the API will be explored through testing. Chrome expects the taxonomy and other parameters to evolve based on testing results. The evolution of the taxonomy or parameters may not require backwards incompatible changes. Further, Chrome expects feedback to continue influencing the Topics API evolution after third-party cookie deprecation.
TopicsSite-classification methodologyRequest that sites be able to decide or influence their Topics classification.Chrome is exploring this request, but have heard concerns (from the web browser community and from DSPs) about the potential risk of sites being able to "game the system” to target users in a privacy-invasive way or reduce relevance of ads. Chrome is seeking feedback and weighing potential changes.
TopicsNoisy signalsDelivering a random topic 5% of the time might create too much noise / false signal.Noise is an important method for protecting user-privacy, and the noise levels versus usefulness of topics will be explored through testing.
TopicsSite-controlled third-party permissioningRequest that sites be able to choose which ad techs can call the Topics API from their site.This requested capability is already supported via the ‘browsing-topics’ permissions policy as mentioned in the explainer.
TopicsTopics API effect on page performanceConcerns around time delays to first ad as a result of depending on Topics APIChrome is discussing possible support for Topics in HTTP Request Headers to improve performance. We’re relying on testing to see if such changes are necessary.
TopicsPrivacy / PolicyQuestions around the purpose of filtering responses by caller if some third parties will share their topics with anyone that callsBased on feedback from many in the ecosystem, Chrome chose this design to limit access to information to those that otherwise wouldn’t have had access to such information. Of course, publishers and third parties that receive Topics could decide for themselves what information they will share with parties on their site. If they do this type of sharing, Chrome strongly encourages them to be transparent to their users about such sharing, and offer them controls.
TopicsDocumentationInterest in documentation that covers the details of the classifier model and taxonomy used by Chrome as you did for FLoC, such as how often the classifier and taxonomy will changeChrome already provides the taxonomy being used as part of the Origin Trials, and the classifier model that categorizes websites into Topics is made available within Chrome’s code base as part of the open-source code. As part of the Origin Trials, Chrome reserves the right to make changes to either as feedback is received and learnings are gathered about how well it works.
FLEDGEFrequency cappingDesire to be able to control the per-user frequency within a campaign or within an ad group.FLEDGE will support frequency capping for on-device auctions. There is an open issue where this is covered for FLEDGE to support contextual/branding campaigns as well. Shared storage, another in-development API, and site-specific caps can also be used for additional frequency capping controls.
FLEDGEFLEDGE impact on performanceConcerns have been raised about the potential impact of computationally-intensive bidders in the FLEDGE auctionChrome is in active discussions with developers about the potential impact on site performance. Chrome welcomes the opportunity to learn more during testing.
FLEDGETesting FLEDGE with other featuresWhen and how will testing with other features (k-anonymity server, key-value servers, etc) take place.Chrome is intentionally rolling out features in phases for our initial origin trials to make testing easier. Chrome recognizes that providing clarity on timeline for other features is important and will clarify when possible.
FLEDGETesting coordinationHow to coordinate testing across multiple ad techs.Chrome is investigating providing additional support to help coordinate experiments so that different ad-techs experiment on the same users. This is also a key focus of Chrome partnerships outreach; industry trade bodies have also expressed interest in playing a role.
FLEDGEInterest groups limitsWill there be limits on the number of interest groups a user can be added to or that can be included in the auction?Chrome is open to refining these limits for web page performance or user experience reasons during the testing period based on feedback and measured latency impact. There is an ongoing discussion amongst testers of additional ways to let buyers and sellers tune resource usage.
FLEDGECross-API CapabilitiesHow will attribution reporting work with FLEDGE?Full details are still TBD, and Chrome expects to have an update on this in Q2. Chrome expects to continue providing event-level reporting for auction outcomes (wins and losses) during the origin trial.

Measuring digital ads

API / TechnologyFeedback Theme

(Ranked by Prevalence)

Questions and Concerns SummaryChrome Response
Attribution Reporting (and other APIs)Testing trafficConcerns if there will be enough traffic for testingChrome is starting the origin trial at very low traffic to ensure that there aren’t any serious bugs or issues with user controls. Early testers play an important part in confirming that the APIs are working as intended from a technical standpoint, which helps to ramp up to a larger traffic faster. Once there is confidence that the APIs are functioning as expected, Chrome will increase the origin trial to support utility testing.
Attribution ReportingErgonomics for registering eventsQuestions about supported forms of registration for events.Chrome has published a response on github to clarify what forms of registration are supported today. Chrome is collecting feedback from the ecosystem on the current design to see whether the proposed changes sufficiently address these concerns or further updates are needed.
Attribution ReportingNoise generationWant more detail on how noise is generated for aggregate reports.Chrome has published a response on GitHub to provide more detail on the systematic way noise is generated. Chrome plans to provide a library to simulate noise and test with a range of parameters during OT. Chrome also plans to provide additional developer documentation and guides for the aggregate reporting mode.
Attribution ReportingLess accurate data for small sitesConcern that smaller sites or campaigns will receive less accurate data.Chrome recognizes that noise based privacy protections have greater impact on smaller data slices. However, it’s possible that methods like aggregating over longer periods of time would solve this problem; it’s also unclear if the conclusions based on very small data slices (like one or two purchases) are meaningful to advertisers. During the origin trial, Chrome encourages 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.
Attribution ReportingConversion delays impact on utilityConcern that conversion delays will interfere with campaign setup and verification or campaign optimization.Chrome has heard some conflicting feedback on the impact of conversion reporting delays. However, given that the Attribution Reporting API does introduce randomized delays in reporting to protect users’ privacy, Chrome expects that specific use-cases or concerns will become clearer during the testing period, and may be addressed by additional debugging support or developer guidance.
Attribution ReportingLonger attribution windowRequest to extend the 30-day attribution windowChrome has published a response seeking more feedback on the length of the attribution window, taking to account both data minimization and utility.
Attribution ReportingNon-viewable impressionsQuestions about whether non-viewable impressions are counted for view-through conversion reports.Chrome has published a response on GitHub to provide more clarity on viewable impressions.

Limit covert tracking

API / TechnologyFeedback Theme

(Ranked by Prevalence)

Questions and Concerns SummaryChrome Response
User Agent ReductionPerformanceThere are concerns about the latency of getting hints via Critical-CH (on the first page load).Chrome is investigating ways to improve performance.
User-Agent Reduction / User-Agent Client HintsAnti-Fraud / Anti-Abuse concernsHaving as much information as possible is important when debugging certain types of attacks, including Denial of Service. Losing some info from the UA string may pose challenges.Chrome is in discussions and evaluating ways to maintain privacy while providing sufficient information that will be useful for debugging.
User Agent ReductionConfusion around OT setupMultiple Origin Trial participants recommended improving documentation with examples of how to enroll in the Origin Trial.The Reduced UA Origin Trial is ending, but Chrome intends to improve the instructions for the Deprecation Trial (including making the example demo more prominent).
User Agent ReductionConcern about values of specific hintQuestions around if the Sec-CH-UA-Model is the same as <deviceModel> in the User-Agent string.Sec-CH-UA-Model is the same as <deviceModel> in the User-Agent string. Chrome will try to make this more clear in future documentation.
User-Agent ReductionConcern about enrolling in Deprecation TrialQuestions around how to enroll a large number of domains into the Deprecation TrialChrome has considered centralized approaches when designing the Deprecation Trial, but Chrome believes the existing Origin Trial is the best option as it gives all control to developers (since they can choose to send the header or not).
User-Agent Client HintsConcerns around prescriptive nature of UA-CHThere is a concern that UA-CH is overly prescriptive when compared to the flexibility the User-Agent header offers, as defined by rfc7231.Chrome sees the prescriptive nature of UA-CH headers as an important improvement over the flexibility of the UA string, both from the point of view of eventual cross-browser interoperability and user privacy protection (by preventing arbitrary additions of high-entropy identifiers).

However the issue remains open in case others also share this concern and would like to provide feedback.

User-Agent Client HintsConcerns that the API is being used to block certain browsersConcern that a site is using the API to look for “Google Chrome” or “Microsoft Edge” and blocking all other browsers.The concept of a brand list was designed to handle this case - a browser can send “Google Chrome” in addition to their own brands.
User-Agent Client HintsRequest for a method to enumerate all supported hintsInterest in having a programmatic way to know all supported hints for a browser.Chrome is evaluating the feature request.
User-Agent Reduction / User-Agent Client HintsAnti-Fraud / Anti-Abuse concernsClient hints are not available on first load for HTTP1One of the Client Hints Reliability APIs (ACCEPT_CH) is only available over HTTP2 and HTTP3. For servers who are still served over HTTP1, they will need to rely solely on Critical-CH.
User-Agent ReductionImpact on Chrome for AndroidQuestions on how this impacts Chrome on Android in particular.UA Reduction as well as UA-CH will ship on Chrome on Android, in addition to Desktop. For Chrome on Android, the changes will only take place in “Phase 6”, currently scheduled for Chrome 110.
Gnatcatcher (WIPB)Non-conforming uses and methodsClarity around what non-conforming uses and non-conforming methods would be.Chrome will be updating the explainer with more details.
Gnatcatcher + User-Agent ReductionReducing signals for anti-fraudAnti-fraud impact of concurrently reducing IP and UA access.Expecting Willful IP Blindness anti-fraud policy stipulations (to allow use of IP for anti-fraud use cases) will resolve defensibility concerns around IP proxying.
Navigational TrackingConcern about future breakagesAdvertisers are concerned about potential breakages; identity providers have also expressed interest in Chrome’s plans.Chrome is not making imminent breaking changes, and is still exploring use cases.
SameSite CookiesInteroperability with other browsersQuestions around Chrome’s plans for fixing crbug.com/1221316, as it’s an area where Chrome’s implementations diverge from other browsers.Chrome discovered a bug in the metrics, and landed new metrics as a result. Chrome is gathering data to better understand the impact of fixing the bug.
Storage PartitioningConcern about partitioning message channelsQuestions around whether messaging channels (i.e., SharedWorker & BroadcastChannel) should be partitioned.Chrome is evaluating the feedback, however Chrome believes partitioning messaging channels along with storage is necessary to prevent covert tracking.

Strengthen cross-site privacy boundaries

API / TechnologyFeedback Theme

(Ranked by Prevalence)

Questions and Concerns SummaryChrome Response
First Party SetsCommon privacy policy requirementIt is infeasible to maintain a common privacy policy across all products, and jurisdictions that need to be part of the same set.Chrome is still defining our policy requirements; and will keep this feedback in mind.
First Party SetsThe Independent Enforcement Entity (IEE) is likely to receive a large number of challenges of FPS validitySummary of foreseeable challenges to determining FPS validity: text or privacy policy does not match across set members, clarity on how to define user-obvious set membership, bandwidth and timing challenges, and specialized expertise around corporate structure.Chrome is still defining our policy requirements; and will keep this feedback in mind.
First Party SetsProcess for maintaining the FPS list of browsersConcerns about barriers to entry for websites in non-western countries, inconsistent versions of the FPS list across browsers due to differences in update cadence, and ability of smaller/newer browsers to use the list.Chrome is still defining our policy requirements, acceptance process, and usage rights for the list; and will keep this feedback in mind.

Chrome will also look to learnings from other static lists used on the web platform, such as the Public Suffix List

First Party SetsDynamic per-site assertion designA dynamic design (as opposed to a static list) might be more prone to false assertions of common ownership, and page load latency/failures.Chrome is currently pursuing the static list approach; and will keep this feedback in mind if the signed assertions approach is re-evaluated in the future.
First Party SetsPotential use cases for First Party Sets (if trustworthy and equitable version of FPS list can be created)Single sign-on, customizable data prompts, possibilities for enhanced transparency reporting to users.Chrome will consider this feedback as it considers next steps for First Party Sets
CHIPSBrowser compatibilityInterest in understanding how other browsers have handled partitioned cookie attributesChrome continues to work within public standards groups such as the W3C to identify designs and implementations that can work across browsers.
CHIPSDesign requirementConcern that it may not be feasible to include the __Host- name prefixChrome has removed the naming requirement for the Origin Trial; and will consider whether to make it permanent at the end of the testing period.
CHIPSUsage of CHIPS for ads use casesQuestions about whether it is possible to use CHIPS for ads use cases.CHIPS allows for a third-party to create client-side cookies that are partitioned to the top-level site (or its First-Party Set). If the use-case needs partitioned state, and not cross-site state; then CHIPS can be used for that use case.
CHIPSIntegration of CHIPS with FPSConcern that testing with CHIPS may not be possible alongside other Privacy Sandbox proposals, like First Party SetsChrome is actively exploring how to facilitate testing environments that would allow for such tests to occur. Chrome has also published instructions for local testing for FPS, and CHIPS; which can be used in the interim.
FedCMExpressivityConcern that because the browser renders part of the federated identity flow, it is hard to capture all of the nuances that IDPs would like to present to their usersChrome recognizes the trade-off and will continue to work with the ecosystem to both cover as much ground as possible and to make it as expressive as possible. Some ideas Chrome is exploring include branding customizations (e.g. logos, colors) and string customization (e.g. “access this article” as opposed to “login with'').
FedCMBrowser involvementConcern that the browser is more involved in the identity federation flow than previously, so it is more explicitly aware of which websites the user is logged into (also with which IDP).Chrome recognizes that the browser now plays a more active role, but this extra level of involvement is necessary for the browser to distinguish and prevent cross-site tracking while still supporting federation.
FedCMApplicability and InteroperabilityConcern that other browsers will not adopt or implement FedCM.Chrome has also been working with other browser vendors to find common solutions for federation at the FedID Community Group.
FedCMVarious API challengesConcern that FedCM is still early / immature and will take a long time to offer all the features that the ecosystem needs.Chrome will explore this further as part of ecosystem testing.
FedCMEnterprises Policies & User ControlsConcern whether there is going to be a control (e.g. enterprise policies and/or user settings) that would allow enterprises to keep their deployment of federated identity without any changes. There are a lot of on-premise deployments of federated identity that are exceptionally hard to re-deploy / change, so there is a lot of resistance towards new browser API that require IDPs to redeploy.Chrome is exploring controls for enterprise admins and users that it believes will address these concerns. Chrome welcomes feedback from enterprises on specific use cases that they would like to see accounted for.

Fight spam and fraud

API / TechnologyFeedback Theme

(Ranked by Prevalence per API)

Questions and Concerns SummaryChrome Response
Trust Token APIRedemption limitsConcerns around 2 per page being too restrictive, especially for scenarios where one may be embedded on the same page multiple times or have a second issuer domain within their organization. One would likely hit the limit themselves without considering other market participants.Chrome is open to expanding the redemption limit per page slightly if it would increase adoption, but need to keep it relatively low in order to introduce excessive entropy. Further, caching a redemption record may reduce the need for one issuer to redeem multiple tokens for a single user in a short period of time.
Trust Token APILatencyTypically need to respond to bid requests within 10 ms or less, so redeeming a token on first page load makes it near impossible to include in pre-bid Invalid Traffic decisioningChrome is trying to understand how latency impacts pre-bid use cases via testing.
Trust Token APIOpenRTB adoptionFor prebid use cases, it is critical to pass the redeemed token information to SSPs and DSPs for use in ad decisioningChrome is open to collaboration with the IAB to help ensure any useful anti-fraud/anti-abuse signals can be propagated through openRTB, though they own the standard for adding any new default fields.
Trust Token APIPrivacyQuestions about long-term viability of any form of cross site data propagation, albeit a low amount of entropy (~2.5 bits)Given the robust user protections to avoid unique user identifiability Chrome believes there is a good case for ecosystem acceptance. Chrome is working closely with key stakeholders to ensure long term viability.
Platform Attestation SignalsGauging Interest in new idea/proposalStrong support for various feasible (and infeasible) signals, such as conveying device integrity signals that platform can provideChrome plans to take this idea to the W3C anti-fraud community group as a new idea for feedback.
Trusted Servers for Anti-fraudGauging Interest in new idea/proposalInteresting concept but likely requires more investigation into applicable use casesDepending on levels of interest, Chrome may conduct further ideation on this concept, and craft it into an explainer for future ecosystem feedback.

Last updated: Improve article

We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.