Browser delayed redemption

[dmarti]

In some cases the browser may need to delay the redemption of a Trust Token in order to improve user experience.

• testdrive.expensivecars.example -- issuer of Trust Tokens to users who have registered to test drive a car
• crappysite.example -- top level site that a user clicked through to by mistake and is about to bounce from
• adtech.example -- domain requiring a Trust Token in order to serve an expensive ad to people who are interested in test driving a car

If adtech.example is able to redeem a Trust Token immediately when the user opens a page on crappysite.example, then crappysite.example is incentivized to engage in deceptive practices to bring in users of Trust Token browsers and run the expensive ads.

The browser may need to delay Trust Token redemption on sites that the user has only been on for a short time and has not taken any action on, so that a user who immediately "bounces" from a site will not carry valuable trust information to that site, and so that sites are not incentivized to engage in deceptive practices to get visits and ad revenue.

Currently, "If there are no tokens available for the given issuer, the returned promise rejects with an error." In order to handle the case of attempted Trust Token redemption by an untrusted site, the promise returned from document.hasTrustToken() may need to have a third value in addition to an error or success -- a value to indicate that maybe a Trust Token will be available in the future if the user stays on the site.

[dvorak42]

Not knowing the adtech industry too well, I'm curious how they deal with this issue currently, where instead of a Trust Token, they use some sort of 3P state? My guess would be they do some sort of display-time decision about whether the advertisement was displayed for a reasonable amount of time, and they could use similar strategies here instead of having additional delays to receiving tokens.

Another possibility is that adtech.example code would just not attempt to redeem the token until the user has been on the page for some time, and this is done as a JS-side decision, rather than being built into the API?

[dmarti]

@dvorak42 This issue is handled differently, and more or less well, by different ad campaigns. There are situations with existing adtech where a low-quality or untrustworthy domain is able to snag a high-paying ad, which means that the same user is then more likely to see a lower-bidding ad on a site they actually like. (The more money that a good campaign wastes on bad sites, the less it will be able to bid for impressions on good sites)

The adtech.example JS is probably the wrong party to rely on for timing of token redemption, since they're incentivized to try to redeem more quickly and catch a fraction of users before they close the tab, in time to serve a valuable ad or set a first-party cookie. Having the browser control the timing would allow the browser to set a timing that is more realistically timed to user behavior when bouncing or staying.

[dvorak42]

Oh is this the case that adtech.example JS belongs to a different adtech company from the one that is providing the high-paying ad? Is there additional information that could be bound to the redemption (for example binding the time since the page loaded as part of the redemption and the issuer can then use that to decide whether to redeem the token or not)?

Though then I'd guess the browser would need to provide that value, since the adtech code could lie.

[dmarti]

@dvorak42 Yes, in this case adtech.example already trusts crappysite.example so has an incentive to over-report the user's engagement with the site. (The ad is probably supplied by an agency via a separate DSP and the actual advertiser has no idea that the whole chain of companies is going to try to show it on crappysite.example)

In the case of a browser that already has a Site Engagement metric, the browser could use that to determine if the site is able to redeem a Trust Token right away.