Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trust Tokens for IVT detection #110

Closed
bvattikonda opened this issue Jul 28, 2022 · 2 comments
Closed

Trust Tokens for IVT detection #110

bvattikonda opened this issue Jul 28, 2022 · 2 comments

Comments

@bvattikonda
Copy link

Summary

Over the past two years, the Google Ad Traffic Quality team along with other teams at Google have experimented with the Trust Tokens API and Android Platform Provided Trust Tokens to defend against invalid traffic (IVT). The team found that the API appears to be better suited for authentication purposes (as illustrated by its use in the Privacy Sandbox k-Anonymity Server) rather than for IVT detection. To use the API for IVT defenses, the Google Ad Traffic Quality team recommends key improvements be made to enhance coverage (as described below).

Scale of Experiment

The team experimented with the Trust Tokens API on 100% and Android Platform Provided Trust Tokens API on 5% of the traffic for publishers with Google’s ad tags from Chrome instances supporting Trust Tokens Origin Trial (OT).

Coverage Feedback

We found several limitations in being able to use Trust Tokens for IVT detection. We need to maximize availability of trust tokens wherever ads are shown to maintain the integrity of our defenses against IVT. We suggest the following:

  1. Partition and cache the redemption records by the the redeeming site (https://example.com/) as opposed to the redeeming origin (https://foo.example.com/).
  2. Allow token redemption and request signing in cross-origin frames by not requiring the trust-token-redemption Feature Policy enablement.
  3. Enable trust token use on HTTP domains as ads continue to be served there.
  4. Adjust the limits on the number of issuers and redemptions to account for limits we will likely hit after widespread adoption of the API and lead to reduced coverage.

Debuggability Feedback

The API was easy to use with iframe/fetch/xhr, and the debuggability was great with DevTool support, but the API would further benefit from the following:

  1. Richer error states and messages. For example, sending a redemption record irrespective of whether one exists or not should not lead to errors. But, occasionally we see “XHR Error.” Lack of clear error states and messages makes it hard to identify the root cause of the error.
  2. The ability to detect scripts that override fetch (or other APIs) would help identify the gaps in trust tokens coverage.

Value of the APIs for IVT Detection

Both the Trust Tokens API and Android Platform Provided Trust Tokens API were found to be helpful in identifying IVT, but we anticipate that the Cross-Partition Cookie Age Signal and Device Integrity Attestation APIs may be easier to use and probably more beneficial for IVT use cases like the ones described in this comment.
(Note: For confidentiality reasons, we are unable to share the specific examples of IVT or the attack vectors these APIs would help against.)

@dvorak42
Copy link
Collaborator

To help with tracking each of these issues, I've split out the new ones into separate issues.

With those, I think these are all tracked by individual issues? Is there any that are missing or can this parent issue be closed?

#106
#120
#121
#4
#122
#123

@bvattikonda
Copy link
Author

Yup, the individual issues cover everything that this issue talks about. We can close this issue and follow up on the individual items.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants