Questions from a potential trust-token issuer

[benjaminsavage]

Hi there! My name is Ben, and I'm an engineer at Facebook. I am evaluating the idea of participating in the origin trials as a trust-token issuer and I would like to understand a few things.

1. If Facebook were to issue trust tokens that indicated something like: "At the time of issuance, Facebook deemed this browser to belong to a signed-in, authentic, human (not a bot / script)", who could potentially redeem those tokens? The explainer says:

[the issuer] can fail redemption (before the token is revealed) based on the referring origin

This seems like a way to implement either a block-list or an "approved list" of referring origins eligible to redeem those tokens. Is that correct? I am wary of the idea of issuing tokens without any control over who is redeeming them, or understanding of the purpose for which they will be used.

2. If Facebook were to issue trust tokens with the meaning explained above, would that leak the information to 3rd parties that "this is / is not a Facebook user"?

[dvorak42]

1) Its still an open question, but from use cases we've heard about, its likely we're going to need to support some sort of limitation on referring origins who could redeem tokens. Currently in our initial OT there isn't a great way of doing this sort of blocking (since we don't have a way to fail redemption that doesn't use up a token), if you fail the redemption its possible a malicious site might try to perform token exhaustion by repeatedly attempting to redeem, though perhaps this isn't an issue during the early portions of experimentation. Another option is to send an SRR independent of the token being redeemed from origins you don't want to send a real SRR to. I think it'll be valuable to investigate what sorts of referring origin restrictions we'll need to support long-term here, balancing ecosystem requirements on both sides.

2) As it currently stands, any 3rd party could discover whether or not there were tokens available for a specific issuer based on a redemption attempt as long as they're willing to use up their issuer slots on testing for the presence of a particular issuer. One potential solution here is if we had explicit allow lists for redemption, then for a site not on that list, the Trust Token redemption would behave identically whether or not there were Facebook trust tokens in the store. Another is using the private metadata extension and always issuing tokens, but only setting the private metadata bit to true if you have a good concept of the user's trustworthiness, though that doesn't prevent revealing whether a user has visited FB at all (since users who haven't won't have any tokens).

[benjaminsavage]

Leaking the fact that someone is or is not a Facebook user seems very concerning... The lack of controls over which websites can redeem those tokens is also concerning...

Can you help me understand the possible incentives Facebook might have for issuing these tokens? I feel like I must be missing something. How does doing this possibly benefit Facebook? How can we ensure bad actors don't just redeem them in an effort to scrape information about people? What positive, compelling use-cases do you see for this?

[dvorak42]

I agree that in the use cases where the Trust Token issuer cares about limiting what origins can discover the availability of tokens, the existing ways to prevent these issues are a bit hacky and non-ergonomic. I think it's worth exploring the use cases to see what sorts of changes would help support these uses. From comment #2, does having an allow list as the control for whether a redeeming origin can tell whether any tokens exist work for your use case.

The original use cases had mostly been for schemes like CAPTCHA and other services that act as a trust signal provider and whether an user has built up a trust signal on that service isnt something that needs to be hidden. Limitations on the number of issuers a particular origin can redeem against is intended to help defend against origins trying to scrape up aggregate signals from many different issuers.

[benjaminsavage]

I had been considering a use-case by which a 3rd party publisher, who would like to request ads from Facebook Audience Network would redeem Facebook issued trust tokens, and somehow send them back along with logging about ad impressions, as a way of proving that they are not a fraudulent publisher. There are tens of thousands of publishers on the network and the set is changing all the time, so an allow list sounds hard to manage. There would still be concern here about leaking the "is Facebook user" status.

[davidvancleve]

There are tens of thousands of publishers on the network and the set is changing all the time, so an allow list sounds hard to manage.

To re-post a suggestion I made a few days ago and proceeded immediately to delete (but have since reconsidered; it does seem useful after all): if these ad requests are coming from iframes with a common origin (facebook-ads.example, say) embedded in a variety of publishers' pages, you could just use a singleton redemption safelist containing only this frame origin. Redeemed tokens are scoped to a pair of (issuer, top-frame origin at time of redemption). This means that, when you redeem a token from an ad placed in a facebook-ads.example frame embedded in publisher.example, you get an SRR (cached receipt of redemption) scoped to the pair (FB [issuer], publisher.example [redemption top-frame origin]), just as if you'd performed the redemption from JS executing in the publisher's context.

Can you help me understand the possible incentives Facebook might have for issuing these tokens? How does doing this possibly benefit Facebook? How can we ensure bad actors don't just redeem them in an effort to scrape information about people? What positive, compelling use-cases do you see for this?

One of the motivations for conducting our origin trial is to find out how useful the feature is. We hope that condensing rich first-party state into a couple bits of cross-site information will provide a useful signal for fraud inference.

(Incidentally, as we go through the process of canvassing potential users, it's very helpful to get feedback on the ways in which others' requirements differ from what we built for in our prototype---thank you!)