attributionsrc request referrer header behavior

[johnivdel]

EVENT.md currently doesn't document how the browser is issuing attributionsrc requests, and whether these are treated like other subresources on the page, or are treated more similar to which does not include a referrer header: https://html.spec.whatwg.org/multipage/links.html#hyperlink-auditing

[bmayd]

I assume it would make sense to treat it like the request to the ad-server that responds with the attributionsrc, i.e. like other sub-resources on the page. If it was omitted, I assume those who want it would add it in parameter in the attributionsrc URL.

[csharrison]

I think I agree with @bmayd here that it makes sense to treat this like a normal request to the ad server. There is no reason (that I know of) from a privacy POV to avoid the referrer and it seems cleaner to encourage users to embed this information in a structured way vs. an unstructured way by embedding it in the URL.

However, I really don't feel too strongly about it, so if there are differing opinions I'm happy to hear them.

[johnivdel]

As an additional data point: while <a ping=> doesn't send the referrer (it send no-referrer), navigator.sendBeacon() does include it.

There is some context on the rationale for excluding from <a ping=> here: https://lists.w3.org/Archives/Public/public-html/2008Feb/0194.html

For the most part, this doesn't seem to be applicable so I would also lean towards explicitly including the referrer for these requests and aligning with sendbeacon().

[csharrison]

Talking with @apasel422 offline, we are trying to think through whether these requests need to abide by Referrer Policy. To me, it seems like it should, i.e. an attributionsrc parallel request on an <a> tag should have the same effective referrer policy as the navigation request on that would result from. Ditto for an <img> tag.

cc @mikewest in case this doesn't sound right. For context, we are designing a system where the browser will issue parallel subresource requests alongside existing request paths. We are trying to figure out how Referrer should work for these new requests.

[mikewest]

If it's a "normal request to the ad server", then it certainly makes sense to respect the referrer policy of the page responsible for the request. By default, that will strip the referrer down to an origin for cross-origin requests, but the page could reasonably choose something more or less restrictive.

[apasel422]

If it's a "normal request to the ad server", then it certainly makes sense to respect the referrer policy of the page responsible for the request. By default, that will strip the referrer down to an origin for cross-origin requests, but the page could reasonably choose something more or less restrictive.

That makes sense, but should these requests also respect the element-level referrerpolicy / rel="noreferrer" attribute if present?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy#integration_with_html

[mikewest]

That makes sense, but should these requests also respect the element-level referrerpolicy / rel="noreferrer" attribute if present?

Is there a good reason not to?

I think the philosophical discussion could go either way as to whether specifying an attributionsrc attribute means something useful about the site's intent to reveal a specific piece of information, but if the site specifies how it wants us to handle referrer for a given element, it makes sense to me to be consistent in the way we generate requests from that element.

[apasel422]

Is there a good reason not to?

I agree that we should support it. We will have to consider whether to augment the window.attributionReporting.registerSource JS API with the ability to set the referrer policy this way, or whether it makes sense to rethink that API entirely so that it can avoid duplicating functionality already built into, e.g., window.fetch.