Difference between revisions of "Trust Tokens"

From Bitnami MediaWiki
Jump to navigation Jump to search
m
m (Reverted edits by Jkoran (talk) to last revision by AdminUser)
Tag: Rollback
Line 1: Line 1:
−
== Overview ==
 
−
The goal of Google's Trust Tokens is to "show that a user is who they say they are."<ref>https://web.dev/trust-tokens</ref>
 
−
 
 
Google's Trust Tokens are “issued” by one organization (a trust provider) and “redeemed” across different publishers.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Redemption requires the consent of the issuer. The token state is stored local to a web client.<ref>https://github.com/dvorak42/trust-token-api</ref>  
 
Google's Trust Tokens are “issued” by one organization (a trust provider) and “redeemed” across different publishers.<ref>https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers</ref> Redemption requires the consent of the issuer. The token state is stored local to a web client.<ref>https://github.com/dvorak42/trust-token-api</ref>  
−
 
−
Each individual browser stores a bank of cryptographic signed tokens that are accessible in third party contexts.<ref>https://web.dev/trust-tokens</ref> The issuer of the token validates the individual is who they say they are, but redeeming organizations are informed only that the individual was previously designated to be a person and not a robot script.<ref>https://web.dev/trust-tokens</ref> Each token can be redeemed only once.<ref>https://web.dev/trust-tokens</ref>
 
−
 
−
Each issuer's tokens are unique so that for any given redemption event, "the issuer can't tell the token apart from other tokens it has created."<ref>https://web.dev/trust-tokens</ref> The issuer can use the redemption requests to understand which sites its visitors also visit.
 
  
 
== Impact ==
 
== Impact ==
 
By removing the technographics that are often used to detect [[Non-human Traffic|non-human traffic]] via [[Privacy Budget]], marketers would not be able to rely on existing fraud detection and prevention services. Moreover, by not being able to detect which publishers' sites have relatively more non-human traffic more of marketers budgets will be spent on fraud.
 
By removing the technographics that are often used to detect [[Non-human Traffic|non-human traffic]] via [[Privacy Budget]], marketers would not be able to rely on existing fraud detection and prevention services. Moreover, by not being able to detect which publishers' sites have relatively more non-human traffic more of marketers budgets will be spent on fraud.
−
 
−
There is also a privacy concern that if publishers and marketers can no longer rely on a competitive market of fraud detection services, but instead the only means of validating whether a user is a human requires the web client to remember this individual has previously authenticated on at least one other web property, individuals may be forced to authenticate on more sites to generate more tokens. This would impact people's ability to navigate the web in an unauthenticated state as freely as they do today. 
 
−
 
−
Additionally, trust tokens do not actually solve for fraud. For example, a valid user who is authenticated by a trust issuer, does not ensure their client is not infected by a malicious script to fire fraudulent traffic (e.g., open multiple tabs after the user steps away from the machine). Without granular tracking over time, most of fraud detection will suffer.
 
−
 
−
== Regulator Perspectives ==
 
−
The UK CMA noted (5.20) that "Websites currently rely on identifiers and cross-site tracking to establish whether a user is trustworthy or engaged in spam or fraud."<ref>https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/992975/Notice_of_intention_to_accept_binding_commitments_offered_by_Google_publication.pdf</ref>
 
−
 
−
Centralizing this functionality solely within the browser raises many similar concerns to those the CMA noted with Google's [[FLoC]] proposal, such as reducing competition among ad tech services currently engaged in fraud detection and advantage Google given its better ability to generate authentication events from its extensive owned and operated web properties and services.
 
  
 
== Open Questions ==
 
== Open Questions ==
−
* How can the reliable quality of issuers of Trust Tokens be compared?
+
* Can organizations other than Google create Trust Tokens? And if so, how can their quality of trust be compared?
 
* What validation service can redeeming organizations rely upon to ensure that a token is not copied from one web client to multiple others?
 
* What validation service can redeeming organizations rely upon to ensure that a token is not copied from one web client to multiple others?
  

Revision as of 00:24, 4 February 2022

Google's Trust Tokens are “issued” by one organization (a trust provider) and “redeemed” across different publishers.[1] Redemption requires the consent of the issuer. The token state is stored local to a web client.[2]

Impact

By removing the technographics that are often used to detect non-human traffic via Privacy Budget, marketers would not be able to rely on existing fraud detection and prevention services. Moreover, by not being able to detect which publishers' sites have relatively more non-human traffic more of marketers budgets will be spent on fraud.

Open Questions

  • Can organizations other than Google create Trust Tokens? And if so, how can their quality of trust be compared?
  • What validation service can redeeming organizations rely upon to ensure that a token is not copied from one web client to multiple others?

References

  1. ↑ https://iabtechlab.com/blog/explaining-the-privacy-sandbox-explainers
  2. ↑ https://github.com/dvorak42/trust-token-api
Retrieved from "http://wiki.prebid.org/index.php?title=Trust_Tokens&oldid=549"