dvorak42
commented
3 years ago Trust Token attempts to solve part of the problem, notably if you've determined traffic is non-fradulent at one location and are trying to propagate that to other places, but I agree that alone it doesn't really completely solve the fraud problem of being able to classify traffic that doesn't have any previous trust decision included.
Its the partial solution of Trust Tokens in the CAPTCHA space, where having a token proves to an endpoint/login system/etc that the user has previously done some amount of verification that they are a 'real' user and allows them to bypass any costly verification step (image/audio recognition/login/etc). (so things like Selenium and puppeteer would end up being routed to doing whatever CAPTCHA verification, while real users would be able to skip that state)
But how to perform verification is still an open issue that isn't really solved by Trust Token itself.
bakkot
I work at Shape Security on our anti-fraud product, which is widely used by banks, retailers, and other organizations to defend against credential stuffing, user account takeovers, and other forms of abuse. For illustration, we block hundreds of millions of malicious login attempts on banks every day, which would have amounted to many thousands of compromised bank accounts.
I saw that trust tokens are being offered as a tool to prevent fraud with less reliance on fingerprinting. I can see how they'd be very useful for click fraud and similar cases, but because trust tokens are opt-in there are other kinds of fraud for which they do not meet that goal.
For example, consider the case of large-scale automated attacks on login systems and other pre-authentication endpoints, typically carried out by using tools such as selenium or puppeteer and routing the traffic through residential proxies. In many cases it is possible to identify individual transactions as automation without further context - if they fail to interact with the page at all before submitting a request, for example, or if their claimed user agent does not match their observable capabilities - but sophisticated attackers may be able to create traffic which will pass as human for a time. Defense in those cases generally requires being able to correlate all visits from the attacker despite said visits originating from different IP addresses, which is done using identifying characteristics of their traffic which distinguishes it from traffic from other users - in other words, fingerprinting.
Note that the case I'm concerned with is when someone is visiting the same site repeatedly. There's no tracking in the sense of following the user around the internet; the "fingerprinting" is strictly first-party.
Crucially, attackers can represent themselves as having never visited the page before. As far as I can tell, trust tokens do not offer anything for the case of a totally new visitor, such as someone logging in from a library computer which resets its profile between users. So attackers can always represent themselves as belonging to this class of traffic. (Or they could harvest tokens, which just pushes the problem down the road to the token issuers.) And by contrast to deciding whether to count a click as real for the purposes of charging for advertising, this categorization has direct consequences for the user: it's not acceptable to simply decide that any user you've never seen before can't log in to their bank. Trust tokens are fundamentally an opt-in mechanism and therefore fundamentally unsuited for defense against this kind of fraud.
I'm very interested in the privacy budget proposal and in trust tokens as a replacement for fingerprinting, but I'm concerned that trust tokens aren't going to be effective for the kind of fraud discussed above. If the web platform makes it harder to defend against this kind of fraud without providing an effective alternative, we risk making these attacks much more prevalent, at significant cost to users. I'd love to be involved in any further discussions about new web platform capabilities for fighting fraud.