Third-party redirects for conversion registration should be disallowed about attribution-reporting-api

[ehsan]

I think third party redirects between the first and last leg of the redirect chain should be fine though.

Why is that? The super popular "cookie syncing" technique employed in the ad-tech industry works through third-party redirect chains.

For example, given the privacy problem in #9, the reporting domain can learn about the identity of the user, and then transfer that information through a third-party redirect with a colluding cross-site tracking domain to them, and have them redirect back to the reporting domain. Am I missing something?

[csharrison]

@willgage there is some discussion of this use-case in #29, to allow multiple reporting domains to receive conversion reports.

[csharrison]

The main restriction is that the GET request should start and end (at the .well-known address) on the same domain. That is, if the publisher drops tags to a.com, we shouldn't allow that tag to ever cause reports to be sent to b.com.

I think third party redirects between the first and last leg of the redirect chain should be fine though.

[csharrison]

Hmm, let me try to see if I can understand your concern. Let’s say we have reporting domain D and third party redirector R.

If D acts alone, then it can recover a report with <64 bits impr, 3 bits conv>. If, in order to register a conversion, D redirects to R then back to D, D and R can cookie sync, which lets R also recover the information from the conversion report, as long as D and R both have third party cookies already, and D has already matched that cookie with the impression metadata. If D or R are not using third party cookies, then redirecting to R doesn’t reveal much extra with this API, since it is very hard to tie a conversion report to advertiser-side identity (which is all you have at conversion registration time without global identity).

However, if D and R are both using third party cookies, than this API doesn’t reveal anything that both parties wouldn't already know. From that perspective, this API doesn’t really make things worse in the status quo than an existing <img> tag.

Let me know if that helps clarify.

[willgage]

As a counterpoint to @ehsan's concern, there are valid use cases where

• Party C acts as an agent of Party A to bid within an advertising platform operated by Party B
• when a conversion event happens on Party A's site, it is not only Party B that needs to know about it, but also Party C, so that they can measure and tune performance.

In the existing model of 302 redirects and cookies, such compositions are relatively straightforward. The click goes through Party B (ad platform), then Party C (bidding agent) and finally arrives at Party A (advertiser). Each party has a chance to record the click event, and when a conversion is registered, each can be notified by pixel. Neither Party A, B or C has to fully "trust" each other's numbers -- they can independently verify.

This proposal already changes the game a little bit to say that Party B is now the gatekeeper of any conversion events related to clicks for which Party C is a stakeholder. That in itself is not ideal. Further restricting that by saying Party C can get no client-relayed information goes beyond privacy restrictions and reshapes business relationships all over the Internet.

[csharrison]

We ended up going with a model that matches the existing flows that take advantage of / supports multiple parties in redirect paths. Closing out this old issue for now