- From: Martin Thomson via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 May 2022 01:30:58 +0000
- To: public-patcg@w3.org
My understanding of the position @csharrison espoused is approximately this. First, assume that sites will not do a whole lot in order to adapt to any changes in how measurement operates. The cost of adaptation will be borne by those to whom sites delegate responsibilities to (DSPs, SSPs, and other intermediaries). This means that sites will rely on active content from third parties (either executing with first party privileges ...ugh... or in frames) for managing the creation of information that will be used in any measurement system. It also means that the processing and maybe even interpretation of that information will be the responsibility of the same intermediaries. The concern is that - without sites taking action to specifically privilege their chosen delegate - any actor that is able to execute content in these contexts is in a position to generate measurement events. Sure, we might build policy mechanisms that control this, but those mechanisms will not be consistently used, especially in early deployments. This includes possibly active content in creatives, which means that there are lots of people who might be in a position to "attack" the system. Attacks here include dumping lots of fake impressions or clicks with a goal of falsely claiming credit for conversions. If events are generated through clicks on annotated links, an attacker might annotate every link with their own identity rather than an hoest one. The proposed mitigation is to have events bound to the entity that caused them to be generated. Without intervention at the site level, this seems like a losing proposition. If we assume that sites do not act and that there are adversaries with the ability to run script in the origin of the site, the game is already up. If events are generated in frames, where they can be attributed to the owner of the frame, that defense might be more effective. For clicks at least, because the browser is in a position to ensure that clicks are genuine. Impressions and opportunities (for lift) are fundamentally much harder to defend. Note here that while the incentive structure for opportunities is different, fake events are worth considering as the goal of the attacker isn't necessarily to claim credit. IPA takes a different approach in that events can be generated by any party that is present on the page, but the choice of whether to accept an event into the computation is made by the entity that is performing the analysis. Events that you generate yourself are somewhat easier to digest than those created by others, and you could certainly structure your system so that you only consider your own events, if you choose. This is not something that you can do if the browser is matching ad events with conversion events as the browser is responsible for enacting any such policy, so that would appear to be a structural advantage to IPA. For in-browser designs, it seems like you could have the browser apply some sort of policy, if it were possible to be confident in the provenance of events, but I'm not sure that this is always doable. Or maybe it just pushes toward using frames for every ad, which wouldn't necessarily be a bad thing (performance issues aside, that is). -- GitHub Notification of comment by martinthomson Please view or discuss this issue at https://github.com/patcg/private-measurement/issues/14#issuecomment-1129475189 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 May 2022 01:31:00 UTC