The R1 mechanism was reasoned from the code and checked on Chromium. Running it
on two genuinely different registrable domains with real certificates, across
Chromium, Firefox, WebKit and Safari 27, shows the arrangement working
everywhere except Firefox's opt-in block-all, and working by two different
mechanisms.
Chromium, WebKit and Safari refuse the server's pair, because AUTH_SAME_SITE
defaults to emitting no SameSite attribute and a cross-site cookie without one
is rejected; that refusal is what lets the widget's partitioned pair land.
Firefox accepts it, and since that cookie is HttpOnly the browser then forbids
the widget's script from replacing it, so Firefox holds no partitioned copy and
rides on an ordinary third-party cookie even with the flag on. Safari blocks
third-party cookies with nothing configured, which makes AUTH_SAME_SITE=none
alone already broken there rather than deprecated.
It also changes what the upstream Partitioned work is worth, which this section
had written off twice. Building go-pkgz/auth with the option and running the
same matrix gives the same persistence with the JWT still HttpOnly: on Safari,
document.cookie inside the frame returns the token under the header flag and
does not under the partitioned build. The header path's XSS cost is avoidable,
not inherent, so both paths are better with the upstream change even though
neither depends on it.