Feedback Report - 2022 Q2

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

Published on Wednesday, July 27, 2022

Translated to: 日本語

Rowan Merewood

Developer Relations for Privacy Sandbox.

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.

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

General feedback, no specific API/Technology

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Clearer timelines	Clearer, more detailed release schedules for the Privacy Sandbox technologies.	We set out our current plans for the deployment schedule on privacysandbox.com, and update it monthly. These take into consideration development time for both Chrome and web developers, as well as feedback we’ve received from the broader ecosystem on time needed to test and adopt the new technologies. Each technology goes through multiple steps from testing to release (launch) and the timing of each step is informed by what we learn and uncover in the prior step. While we don’t have committed releases at this time, as we do, we’ll be sure to update our public timeline on privacysandbox.com.
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.	We understand that some developers have concerns about the impact of the Privacy Sandbox technologies. Google has committed to the CMA not to design or implement the Privacy Sandbox proposals in a way that distorts competition by self-preferencing Google’s own business, and to take into account impact on competition in digital advertising and on publishers and advertisers, as well as impacts on privacy outcomes and user experience. 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.
Third-party cookie deprecation timelines	Requests to avoid further delay for third-party cookie deprecation	We have heard from some stakeholders who want Chrome to proceed with third-party cookie deprecation with no delay, and we have heard from others who believe more time is needed to test and adopt the Privacy Sandbox technologies. We are committed to proceeding responsibly given the complexity of the technologies and the importance to the ecosystem of getting things right. Feedback from the industry and from regulators has been critical to this process.
Third-party cookie deprecation timelines	Requests to delay third-party cookie deprecation, and to provide more time to test the APIs.	We have heard from some stakeholders who want Chrome to proceed with third-party cookie deprecation with no delay, and we have heard from others who believe more time is needed to test and adopt the Privacy Sandbox technologies. We are committed to proceeding responsibly given the complexity of the technologies and the importance to the ecosystem of getting things right. Feedback from the industry and from regulators has been critical to this process.
Documentation requests	Requests for more resources detailing how to manage testing, analysis and implementation.	We appreciate that developers have found our current material helpful, and we are committed to providing more material including developer office hours and technical documentation over the coming weeks and months so developers can continue to understand how the new technologies can work for them. We’ve also held public external 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.
Industry expertise	The Chrome team engaging with standards bodies lack expertise in the ads ecosystem necessary to properly balance privacy and utility.	We recognize we have a big responsibility, and we're depending on specific feedback to get this right. We also consider both privacy and effectiveness to be critical and necessary design criteria. Across the team working on Privacy Sandbox for the Web, the sum total number of years worked in the ads ecosystem is well in the hundreds.

Show Relevant Content & Ads

Topics

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Usefulness for different types of stakeholders	Concerns have been raised about the value created and distribution of that value 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.
Taxonomy	Industry 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.
Not enough browsing history	Proposal to surface topics the caller has seen in previous weeks if the user doesn’t have enough browsing history to create 5 topics for the most recent week	For our current design, they are chosen at random. We will investigate the correlation with past topics and consider whether there is a possibility to incorporate this, however, correlations may have adverse privacy considerations that need to be factored in.
Calling Topics on behalf of a publisher	Can a third-party service provider share Topics with a publisher?	Yes, that is a way in which we expect Topics to be used.
Potential attack vectors	Identifying the noisy topics	Based on feedback from many in the ecosystem, Chrome chose to filter topics and introduce noise. These decisions were made with privacy in mind - to limit access to information to those that otherwise wouldn't have had access to such information and introduce plausible deniability for users, respectively. We recognize that those decisions have drawbacks, such as the attack vector outlined here. However, our assessment is that the privacy benefits outweigh the potential risks. We welcome public discussion on this decision.
Origin Trial eligibility	Is there a way to detect if a user is eligible for an Origin Trial?	An origin trial feature might not be available to a user, because of browser settings or other factors, even if they're visiting a web page that provides a valid trial token and their browser is included in the group for which the trial is enabled. For that reason, feature detection should always be used to check if an origin trial feature is available, before attempting to use it.
Performance impacts	Overhead and latency concerns with Topics	We are soliciting feedback for approaches to avoid expensive and slow x-origin iframes and for the proposal to disentangle the Topics API such that getting topics does not change browsing state.
Split Topics API functionality	Providing more control over the three different aspects of the API	We understand the use case and have proposed a possible way to solve this within GitHub. We are currently awaiting further feedback from the ecosystem on whether to build the functionality. See ongoing discussion here.
Classifier timeline and documentation	Developers have requested more information about the classifier.	We have provided publicly more information about the classifier here. As well as here And here.
User controls and safety	Certain topics may be proxies for sensitive groups and users need more controls to prevent negative outcomes.	Topics represent a significant step forward for user control and transparency. Users will be able to opt out of topics, review the topics that have been assigned to them, remove topics, and understand which companies are interacting with their topics on a given page. In addition, users can also impact their Topics by deleting their browsing history. We welcome continued discussion regarding more advanced user controls, such as those suggested by developers; however we need to make sure that for the concerns raised in this bug, it actually removes the risks (for example, removing just the Topic ‘foreign language study’ but not the websites that generated the Topic from Browsing History does not fully protect the user).
Use of topics on sites with prebid.js	Can Topics API be used on websites with prebid.js?	Short answer is yes. More information has been published in our FAQ.
Use of Topics API in a recommendation widget	Can we use Topics API in Recommended widget (e.g. Outbrain)	We don't limit the use case of retrieved Topics after the API is called (that will depend on each developer’s data policy).
Privacy / Policy	Questions around the purpose of filtering responses by caller if some third parties will share their topics with anyone that calls.	Based 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.
Noisy signals	Delivering 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.

FLEDGE

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Testing coordination	Testing for performance and revenue impact	FLEDGE performance, and how we can best support ecosystem testing during Origin Trials as well as General Availability, are being actively discussed in the public WICG meetings.
Trusted Server for FLEDGE	When will the Trusted Server be available for testing?	We appreciate this feedback and are actively working on a more detailed plan that we can share for use of trusted servers in FLEDGE.
Protocol standardization	Will there be a common protocol for passing data between SSPs and DSPs, such as common labels for interest groups?	We welcome feedback from DSPs, SSPs and the broader ads ecosystem on potential standardization of the spec. For the purposes of initial testing at this time, we recommend working directly with your testing partners since they are in the process of experimenting with different approaches. We also encourage, and plan to continue working with, ads trade organizations to also weigh in to create standardization in case it is useful for their member companies.
Frequency capping	Per-user frequency controls within a campaign & ad group.	FLEDGE will support frequency capping for on-device auctions and contextual / branding campaigns as well. Shared storage and site-specific caps can also be used for additional frequency capping controls.
FLEDGE impact on performance	Computationally-intensive bidders in the FLEDGE auction	Chrome is in active discussions with developers about the potential impact on site performance. Chrome welcomes the opportunity to learn more during testing.
Testing FLEDGE with other features	How will the event-level reports from the Attribution Reporting API and FLEDGE fit together?	This was discussed in a recent WICG/conversion-measurement-api call, with a link to the detailed minutes here. A summary of the meeting is that the current design for Fenced Frames Ad Reporting makes it possible to associate an id generated inside the Fenced Frame with contextual information. Event-level reports generated inside the Fenced Frame will therefore be joinable to the same contextual information on the server (using 2 server-side joins instead of 1).
Impression counting	Which Impression counting methodology should or could be used between buyers and sellers	The FLEDGE API already supports alignment on methodology between the seller and buyer during the auction. We’ve received suggestions on alternate implementations without feedback on why our current design can’t work for the ecosystem.
Displaying Multiple Ads	Whether one can display multiple ads in one auction in a given Fenced Frame	This is currently possible via component ads (not to be confused with component auctions). To do this, all ads must be in the same interest group.
"Seller Defined Audiences (SDA)" specification and FLEDGE	Could FLEDGE become a mechanism to keep buyers from building profiles from SDA on ad requests?	FLEDGE is designed to avoid information leakage that isn't relevant when the publisher already knows what SDAs its visitors are in and targeting is same-site. If it is important to support buying on SDAs within all of the protections built into FLEDGE, then one solution may be for a seller to pass SDA labels into the on-device auction, and a buy-side ad tech to create their own Interest Group whose bidding logic says "I want to buy Audience X."
Support for currencies besides USD	Support for testing FLEDGE with currencies beyond USD	We appreciate this callout and have added building in support for other currencies within our backlog of feature requests. We hope this is made available very soon.
Support for negative Interest Group targeting	An API to support negative IG targeting: showing ads only if a user does not belong to an IG.	Ongoing discussion, including some proposed options to support, in the github issue.
Multiple SSPs in FLEDGE	Risk of favoring Google when implementing multi-level auctions in FLEDGE	Support for multiple SSPs in FLEDGE was added in order to provide for a fair and equitable playing field. Google has promised under the Commitments not to design, develop or implement the Privacy Sandbox proposals in ways that will distort competition by self-preferencing its advertising products and services. Google takes this seriously, and is very open to discuss any concerns that stakeholders may have about specific aspects of the technology. For information, Chrome has publicly documented the component auction mechanism here.

Measuring Digital Ads

Attribution Reporting (and other APIs)

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Multi-touch attribution	Publishers requesting support for multi-touch attribution	Current methods of multi-touch attribution require deterministically tying together a user's impressions (and therefore identity) across different websites. As a result, this functionality in its current form does not align with the goals of the Privacy Sandbox, which aims to support key ads use cases without cross-site tracking. In some cases, approximation of credit assignment (e.g., by using weighted, randomized priorities) is possible without tracking individual users.
Noise generation	Questions regarding the levels of noise within the reports	Our initial experiment allows for developers to set their own epsilon value so that they can experience how the reports change based on the level of noise. As of now, developers can choose an epsilon value up to epsilon=64. We have done this specifically to make it easier for developers to test the APIs and provide us feedback on appropriate epsilon values. We’ve also made a public request for such feedback.
Testing coordination	Can the local testing tool be used for the OT?	Yes, the local testing tool can be used for the duration of the OT. The local testing tool can be used with debug reports as long as third-party cookies are available.
Query Ergonomics	Enable querying aggregate of keys	We agree that this seems to improve API ergonomics with little to no apparent privacy cost. We will make a proposal and see whether there’s broad consensus that it is worth supporting.
Less accurate data for small sites	Smaller sites or campaigns may 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.

Limit Covert Tracking

User Agent Reduction

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Bot protection	UA-R impact to bot protection	We appreciate this feedback and are in the process of gathering information on bot protection approaches to inform our future designs.
Deployment Dependencies	Addressing Structured User Agent (SUA) deployment dependencies	We have rolled out "Phase 4", aka minor version version reduction to 100% of Chrome users in versions 101 and above. See update here.

User Agent Client Hints

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Enumerating all supported hints	Interest in having a programmatic way to know all supported hints for a browser.	We appreciate this feedback and are in the process of evaluating the feature request. We are interested in understanding if this is a common use case.
Flexibility of UA-CH vs. User-Agent header	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). The issue remains open in case others also share this concern and would like to provide feedback.
UA-CH: Anti-Fraud / Anti-Abuse concerns	Certain features that might be lost via UA-CH: Click redirect tracker, and fraudulent clicks.	The team is investigating these potential issues with anti-fraud and measurement stakeholders.
Performance	There are concerns about the latency of getting hints via Critical-CH (on the first page load).	Chrome is investigating ways to improve performance.

Gnatcatcher (WIP)

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Latency concerns	Adding extra hop(s) could impact latency	We are considering a two hop proxy and exploring ways to find the right balance between user privacy and latency. We are open to feedback and would love further discussion in W3C forums.
Fraud and bot protection	Impacts to fraud and bot protection, including in less developed countries	Safety is a core requirement as we look for ways to improve user privacy in meaningful ways, such as proxying IP addresses. A two hop proxy partnering with reputable companies provides verifiable user privacy. We are also incubating ideas for new signals to help convey user trust.
Compliance with local privacy laws	Country-level geo data reporting makes compliance with more granular local regimes difficult	We have posted our proposed principles publicly, which includes potential approaches to that would allow for websites to remain in compliance with local requirements.

Strengthen cross-site privacy boundaries

First-Party Sets

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Usefulness for different types of stakeholders	Impact of FPS for small vs. large publishers	The primary goal of the Privacy Sandbox is to improve user privacy by replacing current practices with solutions that do not rely on cross-site tracking mechanisms. We want these solutions to be as broadly useful as possible for different types and sizes of stakeholders. We welcome specific, actionable input on how these solutions can be improved, and we expect they will continue to evolve with community discussion and testing.
Improving privacy	Too many sites in the same set could result in similar outcomes to third-party cookies	We appreciate this feedback and are evaluating whether or what the right limits could be, while also trying to provide both users and developers with treatment or signals such that they could understand when such a limit is hit. We don’t have a specific proposal yet to share but hope to very soon.
Ecosystem support of FPS	Collection of support and concerns for continuing to develop FPS outside of Privacy CG	While we would have preferred that the First-Party Sets proposal remain in the PrivacyCG, we look forward to continuing to pursue the proposal in the WICG. We were also encouraged by the numerous statements of support for continued discussion of First-Party Sets and the use cases it is intended to address. Google remains committed to finding solutions that allows the web to continue to grow and thrive in a way that protects and respects user privacy.
Browser interoperability	Implementation by other browsers	We recognize the importance of browser interoperability for developers and will continue to collaborate with other browsers to pursue standardization of FPS.
Common privacy policy requirement	It 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.

Fenced Frames API

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Documentation request	Differences with sandboxed iframes	We appreciate the feedback and suggestion. There’s current discussion on this on GitHub, where we’re hoping to get final clarity on the request to then be able to evaluate it completely. The public discussion is available here.
Cross-API Capabilities	Default support for Attribution Reporting in Fenced Frames	We are soliciting feedback on a proposal to allow the Attribution Reporting API in "opaque-ads mode" of fenced frames by default. We encourage developers who would find this valuable to weigh in on the discussion.

Shared Storage API

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Data limits	Will there be a restriction on how much data can be stored per partition?	Yes, there will be limits. See github issue for more details. We will need storage quotas. Our current proposal is to have a per-entry size cap of 4 KB, both keys and values will be limited to 1024 char16_t characters apiece, and a per-origin entry cap of 10,000 entries with a mechanism that prevents additional entries from being committed when an origins’ capacity is full. We are actively seeking feedback on the specific limits proposed here.
User transparency	User transparency for data sources versus data usage	We appreciate this feedback, and we think this is a promising approach worth exploring. In particular, we are evaluating whether it would be possible to do this in a way that offers sufficient transparency to users.

CHIPS

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Adoption impediments	Should CHIPS be hostname-bound? (the no-Domain requirement)	We are removing this requirement from the OT based on feedback from OT participants that this requirement added additional complexity and serves as an impediment to the adoption of CHIPS. We will discuss this requirement in the Privacy Community Group as part of standards incubation here.
Ads use cases for CHIPS	Can CHIPS be used for Ads use cases on a single site?	User tracking within one site is an allowed use case. We have updated our developer article to highlight this use case.
Authenticated embeds	Is sign-on state preserved with CHIPS?	Signed in state is not currently preserved, but it is not the intended use-case for CHIPS. We are aware of the authenticated embeds use case and are working to explore solutions.
Testing coordination	Are there any additional user actions needed to test partitioning?	As long as the OT token is valid and present in the headers of the pages visited, the feature should be available for users, without requiring any additional user actions
Browser compatibility	Interest in understanding how other browsers have handled partitioned cookie attributes.	Chrome continues to work within public standards groups such as the W3C to identify designs and implementations that can work across browsers.

FedCM

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Potential attack vectors	Potential attack vectors via link decoration and timing attacks	We are actively gathering public input and investigating potential ways to address this issue.
UX to allow for multiple IDPs	Only one IDP can be presented at a time	We believe in supporting multiple IDPs, and are actively working on approaches to support
Expressivity	Concern 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 users.	Chrome is exploring including branding customizations (e.g. logos, colors) and string customization (e.g. “access this article” as opposed to “login with''). Chrome 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.
Applicability and Interoperability	Concern 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.
Suggestion to remove personal data requirements in sign-up flow	(1) a UX that indicates to the user which IdP they are choosing, without signaling that their email, picture, and name will be shared would be more privacy friendly (2) Use-cases-sign-up is sparse in its user experience and selection of claims from the IdP	We are in agreement and are exploring how to implement the feedback in a more user, and privacy, friendly way.
User interaction with IdP	Need for direct interaction between user and IdP if a risk threshold is exceeded	We are actively investigating this feedback.

Network State Partitioning

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Performance	Partitioning network state could lead to increase in resource intensive connections to CDNs	We are still investigating the performance characteristics of Network State Partitioning, including measuring different possible keying schemes. We have not yet made a decision between the trade-offs of performance, security, and privacy and need to gather more data.

Fight spam and fraud

Trust Tokens API

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Regulatory feedback	Concerns about investing time and resources in Trust Tokens without clear signal from regulators about long-term viability	Our goal is to build technology that works for the ecosystem, making feedback from the industry and regulators critical to the process. We will continue to consult with regulators around the world as we develop the Privacy Sandbox and make the proposals available to developers, including Trust Tokens. As with all new technologies, companies should make decisions based on their own assessment of regulatory requirements.
Launch timing	When will Trust Tokens be launched to GA?	We provide our current estimates for delivery in our public timeline on privacysandbox.com. As soon as we make a final decision on its delivery date to GA, we’ll post it publicly via Chrome’s release processes and update the timeline on the website.
Trust Tokens vs others	What role do Trust Tokens play given the other tokens undergoing standardization, such as Private Access Tokens	We are engaged in standardization discussions and our goal is to align with other efforts as much as possible, while enabling the different use cases each technology affords. For example, Trust Tokens and Private Access Tokens both rely on the Privacy Pass protocol.
Data limits	Max 2 Issuers for token redemption per page potentially limiting	We are looking for long term options where we can safely allow companies to redeem tokens without risking more user entropy, perhaps by partitioning access to token redemptions.
Access restrictions	Only approved (and verified/not spoofed referrer) origins should be able to verify presence of a token and redeem	We are exploring approaches for who can see and redeem tokens.
Device support	Javascript runtime dependencies limit use on certain devices. Can TT support be extended to work across other types of devices?	This is something we could consider for future development and a topic we would love to hear more feedback from developers in W3C forums. We also have an open issue for discussing an HTTP Header triggered token redemption that we invite feedback on.
Use cases	Unclear what the right use cases for Trust Tokens are. Lack of clarity about intended uses.	Our goal is to facilitate innovation within the anti-fraud space, and understand each company may employ proprietary techniques with trust tokens, which is why we have not been prescriptive regarding intended use(s). However, we will likely expand our documentation to include more examples as starting points for partners who are considering experimentation or adoption.
Trust Token Coverage	Removing this 'trust-token-redemption' feature policy should significantly increase the trust token coverage.	This is in consideration as we collect feedback from the OT and make decisions about next steps.
Issuer trust	Why should we trust websites that issued trust tokens?	There are no guidelines on becoming an issuer - anyone can do it. It is expected that the publishers would only work with issuers they trust. Additionally, other legitimate actors in the ads ecosystem would eventually discount (or stop buying) traffic associated with suspicious or unknown issuers.
3P embedded services	Can 3P embedded services redeem and/or request trust tokens?	Yes, a 3P embedded service can issue and redeem Trust Tokens.
Ecosystem of issuers	Greater utility can be achieved if trust signals can be shared with other companies	Trust Tokens is designed to be a low-level primitive, and can be used by cooperating issuers/redeemers to share trust/reputation signals.
Maintenance overhead	The cryptographic implementation underlying Trust Token operations is in BoringSSL; which Google is the sole maintainer of. How will maintenance of the library be managed?	Trust Tokens relies on standardized cryptographic operations (see Privacy Pass protocol) that may also be implemented in other libraries. We recommend that developers request/develop/maintain support for these operations in the libraries of their choice.
Maintenance overhead	Not clear how long protocol versions will be supported	We are looking into developing and documenting more specifics on the expected support timeframes for protocol versions.
Issuer Limits	If you are further down the chain, your opportunity to execute Trust Tokens might not arise	As more organizations begin to use trust tokens, we could increasingly see these types of timing dynamics at play, and are investigating potential solutions. As described previously, we are looking for long term options where we can safely allow companies to redeem tokens without risking more user entropy, which would minimize the importance of location on page or loading order.

New Anti-Fraud Solutions in Incubation

Feedback Theme (Ranked by Prevalence)	Questions and Concerns Summary	Chrome Response
Device Integrity Attestation Signals	Generally strong support for pursuing device integrity signals attested by platforms and made available to the web	We will continue to gather feedback and pursue the proposal through public design and iteration.
Device Integrity Attestation Signals	Questions over how much user entropy could be conveyed through new signals, and whether certain use cases (such as a user logging into their bank) could justify higher entropy signals.	We lean towards providing high value signals with as little user entropy as possible to preserve user privacy.
Device Integrity Attestation Signals	Would this signal limit access for older devices or open-source/modified platforms?	Any new signals should consider universal access as a key principle in development, and these are important questions to address upfront as we continue incubation.
Device Integrity Attestation Signals	There was some concern if new signals cause security and anti-fraud companies to overly rely on the browser and platforms	Any new signal should be viewed as supplemental data and not an indication of “trust” from the browser. We fully expect security companies to continue to rely on their own proprietary data, models and decision engines with device attestation as an additional input. Hopefully any new signal will improve detection efforts across the ecosystem and make fraud more difficult to execute.
Cookie Age Signal	Interesting concept but likely requires more investigation into applicable use cases.	Depending on levels of interest, Chrome may conduct further ideation on this concept, and craft it into an explainer for future ecosystem feedback.
Trusted Servers for Anti-fraud	Interesting concept but likely requires more investigation into applicable use cases.	Depending on levels of interest, Chrome may conduct further ideation on this concept, and craft it into an explainer for future ecosystem feedback.

Published on Wednesday, July 27, 2022 • Improve article

Feedback Report - 2022 Q2

# General feedback, no specific API/Technology

# Show Relevant Content & Ads

# Topics

# FLEDGE

# Measuring Digital Ads

# Attribution Reporting (and other APIs)

# Limit Covert Tracking

# User Agent Reduction

# User Agent Client Hints

# Gnatcatcher (WIP)

# Strengthen cross-site privacy boundaries

# First-Party Sets

# Fenced Frames API

# Shared Storage API

# CHIPS

# FedCM

# Network State Partitioning

# Fight spam and fraud

# Trust Tokens API

# New Anti-Fraud Solutions in Incubation