Feature: Value for the crossorigin attribute that makes anon requests same-origin

[jakearchibald]

It currently isn't possible to make same-origin no-credentials requests for things that use the crossorigin attribute.

Notably, this means you can't <link rel="preload"> a fetch() or script module (unless you make the fetch/script send credentials).

A crossorigin attribute that changes same-origin behaviour is a bit weird, so maybe there needs to be some sort of fetchoptions attribute on everything that currently uses crossorigin.

+@yoavweiss @igrigorik

[annevk]

We should first decide on #2557 really.

[jakearchibald]

True, but only if it results in fetch() being unable to make an anonymous same-origin request.

[BenLubar]

Another solution would be to allow <link rel="preload" href="same-origin-url" as="fetch" crossorigin="anonymous"> to match fetch("same-origin-url", {mode: "cors", credentials: "omit"}) as part of the spec.

I can't think of any real-world scenario where this wouldn't do what the website wanted it to do.

[yoavweiss]

These 2 requests are quite different: the initial request for both (which is to a same origin URL) will be credentialed in the first case and non-credentialed in the second. Making them match doesn't make sense, and will result in correctness issues.

[mikewest]

In WICG/credentiallessness#3, @slightlyoff noted that it would be quite nice to be able to strip credentials from particular outgoing no-cors requests (as a more granular COEP:credentialless). Is something like a credentials=omit HTML attribute similar-enough to this bug to discuss here, or would a distinct issue be appropriate?

[jakearchibald]

I think it's fine to discuss here. The original issue was more pressing when fetch() and <script type="module"> didn't send credentials for same-origin requests, but that's no longer the case.

However, a generic "don't send credentials for this request" attribute/value still seems like a good idea to me.

credentials=omit would clash weirdly with crossorigin=use-credentials, although we could deprecate crossorigin=use-credentials in favour of crossorigin (which means use CORS) and credentials which controls credential sending.

[annevk]

I think adding credentials=same-origin is reasonable and would align with a desire for a granular credentialless, though:

1. It's unclear how long this is needed for as cross-origin credentials are on their way out. Though I suppose that applies to credentialless too.
2. We'd indeed have to define how it interacts with crossorigin. Overriding it seems fine.
3. It's unclear what the default value ought to be as it depends on whether or not crossorigin is specified. Normally the default would be =include, but for crossorigin or features that require CORS by default (<script type=module>) it'd be =same-origin. I guess that means there's no missing value default.

I don't see a lot of point in credentials=omit. For performance that can often be worse as you can end up with multiple same-origin connections, depending on the user agent. We could support it for completeness, but I'd be inclined to leave it out until demand is more solid and better articulated.

[mikewest]

To 1, both credentials=same-origin and credentialless are origin- not site-bound. I think that's still a boundary that's going to be interesting to control as we make more collective progress to limit access to cross-site (third-party) credentials.

Your suggestions for 2 and 3 seem reasonable to me as well.

Regarding omit, I didn't think about the performance implications, which I suppose would also flow through to the cache? If we have same-origin, I think I agree that omit is of pretty limited usefulness and could be a potential footgun. I wouldn't be opposed to adding it later if that simplified the story.

(Note, though, that I'm not sure what the priority of any of this actually is. It doesn't seem like a lot of effort, given that we already have the ductwork in place for things like referrerpolicy to have per-request effect. Perhaps @slightlyoff can weigh in with some motivating use cases that could help me figure out how this stacks up to other things we could be spending time on?)