fetch icon indicating copy to clipboard operation
fetch copied to clipboard

Request with credentials included, but only if they are partitioned

Open csharrison opened this issue 4 weeks ago • 5 comments

What problem are you trying to solve?

I am trying to use fetch (and the Fetch spec more broadly) to send a cross-origin request where I am comfortable if the request has partitioned credentials, but not unpartitioned credentials. Currently I am forced to either a) omit credentials (hampering utility) or b) include credentials (hampering privacy if 3PC are available and used).

What solutions exist today?

Don't think there are any?

How would you solve it?

I am not an expert, possibly with a new property to sit alongside credentials. Maybe a new credentials enum value?

Anything else?

cc @DCtheTall @johannhof

csharrison avatar Dec 02 '25 21:12 csharrison

Note this came up in https://github.com/w3c/attribution/pull/280#discussion_r2582831115

csharrison avatar Dec 02 '25 21:12 csharrison

You write fetch (including code) in OP, but from the link it appears you only require this at the specification "fetch" level?

annevk avatar Dec 03 '25 07:12 annevk

My immediate use-case doesn't require exposing this to fetch(), only the Fetch spec. Still, I think this would be useful for web developers too.

csharrison avatar Dec 03 '25 14:12 csharrison

@arichiv is proposing https://github.com/explainers-by-googlers/third-party-cookie-allowlist-header to give sites HTTP-level control over how unpartitioned credentials are used. Adding this thread's feature to fetch() (so exposing it to JS) should probably be coordinated with the HTTP allowlist. I don't have a good sense of whether the specification-level feature needs to be coordinated with both.

jyasskin avatar Dec 05 '25 00:12 jyasskin

The allowlist definitely could accomplish this goal, but if you want a more targeted 3PC (but not CHIPS) denial via JS only then some sort of new fetch() credential option likely makes sense.

arichiv avatar Dec 05 '25 00:12 arichiv