Don't disable cookie setting in ReportEvent API until 3PCD

[bhedgehog-google]

Background Post 3PCD, ARA (Aggregate Reporting API) will be used to measure the conversions that are tracked by third party cookies (3PCs) today. In Google Ads, best use of ARA and improvements in integration with ARA are ongoing efforts at the time.

Today’s PA API restrictions disable setting 3rd party cookie (3PC) in ReportEvent API. As a result, for this traffic we are not able to measure conversions tracked by 3PC, which is currently one of the most effective approaches for conversion tracking.

Challenge Prior to 3rd party cookie deprecation (3PCD), Adtechs need to run experiments using PA API. Many of these experiments will be outside of mode B. We want to measure the conversions on this traffic as accurately as possible, so that we can report the correct number of conversions to the advertisers and also provide correct training data for our backend models without the results being confounded by our ARA integration efforts.

Additionally, the verbose debug reporting feature of ARA, which has been critical for our integration testing and experimentation, is dependent on the ability to set the ar_debug cookie in response to source registration requests. Lack of 3p cookie support makes it difficult to validate source registration is working correctly.

Proposal Given that after 3PCD, ARA will cover these conversions, we propose to have a transient solution in which prior to 3PCD, Chrome doesn’t disable the ability to set 3PC in ReportEvent API for at least the automatic navigation pings.

[MattMenke2]

If we do this, I think we're going to need to enable CORS on these requests, and act as if the initiator were the origin of the bidder/seller worklet that provided the URL.

Otherwise, e.g., https://bad.actor.com could create an ad for some ad https://my.bank.com/real_ad for a bank it has no association with, and send reports to https://my.bank.com/?send-Matt-Menke-all-my-money, and https://my.bank.com/ would think those requests came from itself, and all legacy 3P cookies would be included in the request (I don't think we want to introduce a new concept of setting but not sending cookies for the however-many-months-until-3P-cookies-are-deprecated). Hopefully my.bank.com is using 1P cookies by now (and presumably fancier techniques as well), and this attack won't work, but this seems like the classic situation where CORS is needed.

[michaelkleber]

Additionally, the verbose debug reporting feature of ARA, which has been critical for our integration testing and experimentation, is dependent on the ability to set the ar_debug cookie in response to source registration requests. Lack of 3p cookie support makes it difficult to validate source registration is working correctly.

Yikes. It's certainly bad that the PA design makes it impossible to use ARA debugging mode; we did not realize that problematic interaction.

@MattMenke2 is totally right that we need to be careful here, so that cookies can't be revealed to anyone using this mechanism that they couldn't get revealed to in normal circumstances. But we should definitely try to fix this if possible.

@shivanigithub for visibility.

[MattMenke2]

Small clarification: My attack didn't let anyone view anyone else's cookies, it let someone send requests to a third party with that third party's cookies, which normally requires CORS to do, except under certain circumstances (disclaimer: I am not a CORS expert).

[michaelkleber]

(@MattMenke2 Wait isn't that something you can already do with an <img> tag? Yeah okay I'm also not wise in the ways of CORS, obviously. In any case, yes let's be sure we don't break any web security invariants, but seems like we should be able to fix this either way.)

[MattMenke2]

I'm not sure if image tags use CORS or not now-a-days. Image tags don't have POST bodies, and only have safelisted headers, so if they did use CORS, they would not need to send preflights. I'm totally not an expert here - my knowledge is mostly "enable CORS, set the right initiator, and things magically work out without too much effort unless you do something not considered safe for some value of safe, in which case a preflight is sent, making things safe(ish)".

[shivanigithub]

@bhedgehog-google A few follow up questions: Do you care about this specifically for fenced frames, or just urn iframes? If the latter, do you specifically need the ability to set cookies on automatic beacon requests/responses, as opposed to just setting the cookie via JS (since urn iframes don't have partitioned storage)?

[bhedgehog-google]

1. We need the support on iframe as soon as possible. For fenced frame support, ideally we should also have it since we will be switched to fenced frame in the future and we hope to test and verify our mechanisms on it early. Though if enabling cookie setting on fenced frame may significantly slow you down, we don't need to have it urgently. Again, we hope to have it on iframe soon. Thank you!

2. We Do need to set cookie on request/responses via headers, not JS.

[tprieur]

Hi all, On the Criteo side, we prefer fixing the verbose debug reports to make them work with PA, instead of allowing cookies. This approach guarantees thorough testing of the final solution during market testing.

[dmdabbs]

They already posted a CR and requested merge for M120: https://bugs.chromium.org/p/chromium/issues/detail?id=1498474.

[michaelkleber]

Hi folks, we are indeed working to support ARA debugging within PA by allowing 3rd-party cookies on PA reporting beacons the same way we allow 3rd-party cookies elsewhere. This was the only way we found to enable this debugging flow in Chrome M120, which gives us a shot at fixing any integration problems during the market testing period.

This will have no effect on the traffic in "Mode B" testing, since on that 1% of Chrome instances, 3rd-party cookies will be unavailable across the board. Thomas, I hope that addresses your desire to be sure that the Mode B test reflects the final state as accurately as possible.

[gtanzer]

A followup on @MattMenke2 's attack:

The issue here is that the current implementation of reportEvent sends beacons with the ad creative (who called reportEvent) as the request initiator, even though they don't get to see the destination URL. And they don't even know which origin set the destination URL due to how Protected Audience works. The request initiator really should be the origin that determines the destination URL (and in particular, the destination origin). For reports to registerAdBeacon destinations this is the reporting worklet origin, and for reports to URLs substituted with registerAdMacro this is the ad creative (the caller of reportEvent with destinationURL).

So the current behavior is not exactly semantically correct. But it only becomes a security issue when credentials are added, because it would become a vector for CSRF as Matt says. Before credentials, it is no worse than requests that an attacker could simulate from a fake browser without access to user data.

So in order to fix this, we are changing the request initiator for reportEvent beacons to registerAdBeacon destinations to be the reporting worklet origin. (For destinationURL and registerAdMacro there is no change.) This change will roll out gradually at the same time as credentialed beacons (finched starting with M120, https://chromestatus.com/feature/5170880732987392), but unlike credentialed beacons, it will stay after 3PCD because it is a bug fix. There is no change to e.g. the origins associated with ARA support on the beacons; it is purely about the Origin header attached to the request. reportEvent beacons already have CORS enabled but do not require preflight requests due to the set of headers they have, so there is also no change there.

We don't expect this to cause breakage because it is a relatively minor change to headers that servers should handle automatically, but just be aware/on the lookout and please let us know if you have any concerns. Thanks.