darobin
commented
2 years ago I fully support documenting this, but I would like to ask that two things be treated separately: what the server needs to do, and how it can be trusted.
The reason I ask is because there are several proposals that rely in one way or another on a trusted server, and I think that we would benefit from trying to pool the "how it can be trusted" part, ideally alongside looking at what requirements might be managed in common. Otherwise we're going to end up with a whole menagerie of servers with different properties.
I have a proposal (in need of an update, coming) that was designed for PARAKEET-like things and the PATCG has been chatting about it in support of other proposals like IPA (possibly as a hybrid with MPC). I think we could all benefit from alignment.
p-j-l
chris-wood
dvorak42
We propose developing a high-level document to capture use-cases and requirements for trustworthy anti-fraud servers. This is a call for collaboration among interested members of the community group.
Fraud detection and enforcement is one common use case that relies on third-party cookies and sensitive user data. There are more details about the need for this functionality in advertising use cases here. As browsers proceed to remove support for third-party cookies, this is an important use case that needs to continue to be supported.
One avenue to support this use case is the use of trustworthy servers to process relevant data. There are existing technical proposals that allow sensitive user data to be safely sent from the browser to a server, provided that there are guarantees for what the server does with the data (this is what makes it trustworthy). An example of this is the Aggregate Reporting Service that uses cross-site user data. Note that non-technical guarantees, such as auditing, are out of scope for this proposal at the moment.
We would like to use this discussion to then propose developing a similar scheme where the browser would send a minimum set of signals necessary for running ad fraud detection algorithms to one or more servers that could determine whether this is fraudulent traffic or not. One assumption we’re making here is that the algorithms are compute-heavy and therefore too costly to run in the browser itself (e.g. Machine Learning model evaluation) - we’d like to validate that first and determine whether it introduces a DoS risk. Another assumption is that attackers control the browser and so moving processing out of that environment may be beneficial.
There are many open questions in this area that we’d like to explore:
We’d like to start an effort to explore this approach, starting with requirements gathering, in the Anti-Fraud Community Group, and would welcome collaboration.
Related work: