Consider making source-side attributionsrc pings easier to associate with existing pings

[johnivdel]

Currently to declare a source in the API you must provide a separate url which can register attribution response headers:

<img src="https://adtech.example/existing_ping" attributionsrc="https://adtech.example/new_ping">

For the ad-tech, it may difficult to associate the new ping and existing ping unless certain query parameters are added. If there are multiple reporters within the attributionsrc redirect chain, this can become more complicated as there is a reliance on other parties setting these params.

This is related to ​​#347 where it was difficult to introduce a separate ping on the trigger side.

It's possible we can improve the developer experience here by having the browser make these pings strongly associated. A few (non-exhaustive) options:

1. Have the browser send a header on each of the requests to indicate that they are associated with each other.

<img src="https://adtech.example/existing_ping" attributionsrc="https://adtech.example/new_ping">

https://adtech.example/existing_ping receivers a header: Attribution-Reporting-Eligible: false, <uuid>

https://adtech.example/new_ping receivers a header: Attribution-Reporting-Eligible: true, <uuid>

<uuid> would be a random id generated by the browser to associate these two requests. The adtech is then able to associate these pings with each other server-side. Redirects for each of the requests would also have this ability.

2. Make the separate request optional. Instead, if the "attributionsrc" attribute is present without a value, it will allow registration on the existing src= request.

<img src="https://adtech.example/existing_ping" attributionsrc>

Here, https://adtech.example/existing_ping is able to register the Attribution-Reporting headers. We still retain an element level permissions model for whether a request is allowed to use the API.

In theory, a similar behavior could be applied to anchor tags, where the href itself could respond with headers. However, because these are potentially top-level navigations, these requests will behave very differently than attributionsrc requests. Namely, they would be in a different first party context.

It is possible (1) could be used in conjunction with (2) to provide additional flexibility. Sending a header itself on attributionsrcs may also make it easier for the browser to signal whether a request can actually register (e.g. permissions policy checks, browser support without UA sniffing).

(2) has the benefit that it uses less network bandwidth + avoids making two requests in some cases. 

Because (2) re-uses existing pings, the browser would have less flexibility in regards to performing+processing these pings. This may not be a problem in practice, but worth pointing out.

[bmayd]

Make the separate request optional. Instead, if the "attributionsrc" attribute is present without a value, it will allow registration on the existing src= request.

Making the separate request optional allows a future state in which a single URL is used to handle attribution registration and existing_ping functions. Wonder if it should be defined as: attributionsrc="src" so the definition is explicit.

[csharrison]

I am supportive of the idea of adding a new request header, and I am interested to see if it mitigates the risk of double-counting with the parallel path design. I want to add this to a future meeting agenda to discuss.

Making the separate request optional allows a future state in which a single URL is used to handle attribution registration and existing_ping functions. Wonder if it should be defined as: attributionsrc="src" so the definition is explicit.

I think attributionsrc="src" is not quite as elegant as an empty attributionsrc. An empty attributionsrc could mean that down the line if all these call sites migrate to stop using the parallel ping, we could move attributionsrc to be effectively a boolean flag rather than a string field.

[johnivdel]

Another idea for discussion specifically on the view registration side:

On the topic of (​​#347) and (2) it may make sense for the browser to allow "upgrading" of existing JS based pings (using xhr, and fetch). If a reporting origin is currently issuing attribution pings through those APIs there is no straightforward way to avoid a duplicate ping outside of moving to a different API.

One solution here would be for us to extend (2) with (1) such that:

Any request which contains an "Attribution-Reporting-Eligible: true" request header will be allowed to register attribution response headers. This achieves a similar "element level opt-in", and covers any JS request APIs/libraries which allow setting request headers.

Example:

xmlhttp.open("GET", impression_ping_url);
// Reporting origin just needs to add this line.
xmlhttp.setRequestHeader("Attribution-Reporting-Eligible", true);
xmlhttp.send(attributionData);

This also makes it relatively straightforward to coalesce the various surfaces. The <img src= attributionsrc> API would just ensure the request header gets set, so that there is a common flow.

[csharrison]

+1 to @johnivdel. This really just makes existing JS API simple syntactic sugar around the raw underlying APIs, so I think it makes sense to deprecate window.attributionReporting.registerSource in favor of this new mechanism.

[apasel422]

Attribution-Reporting-Eligible: true is a bit strange to me because the value is always true if the header is included at all, and it makes me wonder what's supposed to happen if the value is something other than true. It seems more useful to provide additional data and make the non-true issue irrelevant.

I propose that the header instead contain a set of tokens {event-source, navigation-source, trigger} represented as a structured header dictionary that specifies which registrations are allowed:

1. attributionsrc requests from <a> and window.open will include Attribution-Reporting-Eligible: navigation-source.
2. attributionsrc requests from <img> will include Attribution-Reporting-Eligible: event-source, trigger.
3. For all other requests, if the header is not included at all, the browser treats the request as if it contained Attribution-Reporting-Eligible: trigger, but does not actually include the header in the request, both as encouragement to migrate to attributionsrc and to reduce bandwidth consumption.
4. Requests from window.fetch and XmlHttpRequest can override this default behavior and opt in to registration by setting the header to a set of those tokens, but will not be allowed to include navigation-source.
5. Likewise, requests from window.fetch and XmlHttpRequest can disable registration entirely by setting Attribution-Reporting-Eligible: , i.e. the empty dictionary.

The reporting origin can use this header to ensure that it is sending the correct registration response, if any, and the browser will use the header to determine which registrations to actually permit when processing the response.