Specify when the Save-Impression HTTP response header is processed

[apasel422]

For example, is it processed on potentially every single response, or only a subset? And how do things like redirects work? Do pages have to opt in on the HTML side, like they do in Attribution Reporting (e.g. <a href="..." attributionsrc>)? If so, which HTML elements support it (e.g. <img>, <script> like in ARA)? And are there background requests or only subresource ones?

ARA supports source registrations on responses initiated from:

• <a href="..." attributionsrc>
• <area href="..." attributionsrc>
• <script src="..." attributionsrc>
• <img src="..." attributionsrc>
• window.fetch(..., {attributionReporting: { ... }})
• window.open(..., ..., 'attributionsrc')

[martinthomson]

The need to decorate a bunch of points in HTML seems bad, so we might instead decide on having a fixed set of fetch destinations that always have the API enabled. The main reason I can see for giving sites control is similar to the reason we have permissions policy integration, they might not want to police all of their third-party vendors in terms of how they access the APIs.

We could also be more permissive for saveImpression() than measureConversion(). It's less likely that measureConversion() is going to need the full diversity of options given that it is invoked more deliberately and less often via HTTP. I'm not sure that we get much value out of that though in the end.

[martinthomson]

Discussion at F2F 2025-06:

Decided not to go with attributionsrc approach, but instead rely more heavily on Permissions Policy and then limit the set of fetch destinations that can invoke the API. Permissions Policy has a default allow for both of these. Double check that permissions policy allows for per-site controls in a way that can be used.

NOT "document" (though maybe same origin); uncertain about "frame" and "iframe" (these seem fine, but ARA didn't need them); but we would definitely want "" (the empty string: <a ping> and friends), "image", and "script".

On the conversion side, the ability to spend privacy budget is the main risk. Some people suggested that retagging conversions is hard (very hard). Tags for ads churn a lot, but conversion tags are once-in-a-lifetime. It's too hard to re-tag, so the API opens the possibility that random images can exhaust the budget, but that is what Permissions Policy is for (or, in a pinch, CSP).

We could make a different permission policy split for JS vs. HTTP, with different defaults. Decided not to do that for now.

[apasel422]

@martinthomson How do you envision redirects working? I think we'd like to allow impressions to be registered on each redirect, but I'm not clear how to integrate that with fetch.

NOT "document" (though maybe same origin)

What's the reasoning for this? I assume that a major use case, as in ARA, will be registering an impression on navigation.

[martinthomson]

I'd say limiting it to media, documents, and scripts would do. I think that's : "audio", "document", "frame", "iframe", "image", "script", "track", "video". Plus "" (for fetch and <a ping>).

I forget why I didn't want "document". Edit: I remembered. A "document" fetch is triggered by a different site, which means that who the call is associated with is unclear. That's why "frame"/"iframe" is tricky as well, if you consider a frame that is opened by some other site.