The specification has 5 places where we create network requests, and 4/5 of them use no-cors as the request mode, which is unfortunate since it is a highly discouraged request mode to use, and should not be used for any new web platform features without proper justification:

• https://wicg.github.io/turtledove/#check-interest-group-permissions: "cors"
• https://wicg.github.io/turtledove/#fetch-script: "no-cors"
• https://wicg.github.io/turtledove/#fetch-webassembly: "no-cors"
• https://wicg.github.io/turtledove/#fetch-trusted-signals: "no-cors"
• https://wicg.github.io/turtledove/#interest-group-update: "no-cors"

We should evaluate which of these "no-cors" requests could take one of the following paths:

• Use "same-origin" (possibly changing the initiator origin to match the URL, when it is the same for each request)
• Use "cors"

As far as I can tell (going off of memory from internal discussion, not my present evaluation of each request right now), none of the "no-cors" requests would trigger preflights if they switched to CORS, which is good. On the other hand, the initiator of the request would be exposed via the Origin header, which at least for some requests might not be desirable (are there some where this wouldn't be bad though?? I think that needs to be answered). I like the "same-origin" route when possible, so we should try and use it wherever we can. We did this with a similar client-less fetch request in attribution reporting and I think it was a great outcome (WICG/attribution-reporting-api#546, WICG/attribution-reporting-api#817).