Finish todos of fetching reporting URLs.

[qingxinwu]

@domfarolino PTAL. Thanks.

---

Preview | Diff

[qingxinwu]

The implementation uses the default 'NEVER_CLEAR'.
What does it map to in fetch's spec?

[domfarolino]

These aren't the same concepts. In spec you're pointing to https://fetch.spec.whatwg.org/#concept-request-referrer but in the implementation you're pointing to https://fetch.spec.whatwg.org/#concept-request-referrer-policy.

[domfarolino]

So I'd need to see the actual place in the implementation where this request is being set up.

[qingxinwu]

oh right, sorry about that. It seems "unsafe-url" is the mapped value to the implementation's "NEVER_CLEAR"
I'll ask Matt to review the whole request settings in the spec, since they're back and have the best knowledge about our request implementation here. I'll tag them under the issue

[domfarolino]

Right, so if you're using that referrer policy, what is the referrer you're using in the implementation? Are you explicitly providing one?

[domfarolino]

Regarding redirects, the spec already uses the "error" redirect mode, right? So maybe that's fine.

Can you explain the rationale for saying the "referrer policy doesn't currently matter"? I don't understand that.

[qingxinwu]

Referrer policy is not useful for the initial request, but for redirects only, if I'm not understanding it wrong? And our requests do not follow redirects.

Also I checked our implementation and there's no referrer being set (confirmed with Matt). Matt said "Seems like we should probably grab the referrer and add it, for consistency, at least for the URLs from the page (Seller URLs)". But before that happens, do I spec referrer as no-referrer (then referrer policy really does not matter) for now? I can add a note about some requests' referrer would be set.
As Matt commented in the other github issue, there's also a plan of thinking about changing the request's initiator, which would affect some other fields as well, but that's still not happening.

[qingxinwu]

after reading more about referrer policy, seems it does affect the initial request as well (Matt and I thought it does not), so the original statement (referrer policy does not matter when we assumed referrer was set) seems wrong. But turns out our current implementation does not set a referrer.

[domfarolino]

It sounds like the implementation does not manually set a referrer, but does one still get computed and sent anyways based on the URL? My understanding is that the behavior can vary depending on the implementation path taken, and since there are somewhat unique requests, I'd like to know way one way or another for sure if we send any referrer or not (regardless of if we manually set one). A WPT here would be great if possible.

[qingxinwu]

No, I used chrome://net-export/ to get network logs for the publisher page of our demo, and non of the requests (bidder and seller script, report url) have referrer. Didn't find signal requests in the log, but it uses the same code as script requests. Matt confirmed that network stack cannot add referrer for a request if it's not manually set, since it doesn't know what a page is.

Request header for seller script (bidder script and report request have very similar headers)
:method: GET
:authority: protected-audience-demo-ssp.web.app
:scheme: https
:path: /decision-logic.js
accept: application/javascript
sec-fetch-site: cross-site
sec-fetch-mode: no-cors
sec-fetch-dest: empty
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)

Created a task in backlog to add WPTs for referrer.