Combatting non-ad fraud

[bakkot]

(I'm reposting this from this issue.)

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 the part of the privacy sandbox intended to prevent fraud in the absence of 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 cross-site tracking involved; 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 or any other replacements for fingerprinting, but I'm concerned that trust tokens aren't going to be effective for the kind of fraud discussed above, and I don't see any other proposed tools in the privacy sandbox effort aimed at this use case. 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.

[rowan-m]

Hi @bakkot - thank you for kicking off the inaugural discussion in this repo! I've also only just noticed the Discussion notifications, so I'm going to make sure that filter is a bit more prominent in my inbox. I'll also get a reply together for you!

[bakkot]

Hi @rowan-m! It's been a couple weeks; any updates?