Charlie Harrison

Summarizing the [discussion from Jan 23](https://github.com/WICG/attribution-reporting-api/blob/main/meetings/2023-01-23-minutes.md) - @jfggit and I voiced concerns about _requiring_ listing out specific origins (per @clelland's comment [here](https://github.com/WICG/attribution-reporting-api/issues/558#issuecomment-1400441677)), but I suppose we don't have any conclusive...

After all the previous discussions, I feel a default permission policy of `self` is not feasible for a near-term launch of the Attribution Reporting API: 1. There are real-world deployments...

This should be supported in the aggregation service. Please re-open if there's any further issues here.

Closing as fixed

@domfarolino and I chatted about this a while ago and unfortunately the chat was lost to time, but from my memory, I think the conclusion was because the flow described...

> Can you clarify what behavior is confusing here? I'm not sure I follow. My preference would be to land this PR, which sets the `Origin` header to the reporting...

> Do we support this right now? If we allow that, then yes CORS is good, because if the request goes cross-origin we should be affirming CORS. Otherwise, we should...

IMO it'll be easier to get rid of the redirects, as I don't even think at our layer in the implementation (SimpleURLLoader) even supports CORS. Let's me circle back though.

> An alternative is to add the Attribution-Reporting-Support header on the subresource request if there's an attribution source registered with the top-level site as destination and subresource origin as reporting...

I was opposed to the proposal in this snippet (emphasis mine): > An alternative is to add the Attribution-Reporting-Support header on the subresource request **if there's an attribution source registered...