The mechanism paragraph said the server pair being refused is what lets the
widget's partitioned pair land. That is false: CHIPS makes the partition key
part of a cookie's identity, so the two are different cookies and coexist, and
#2218 measured all four at once on Chromium. Firefox is the exception because
Total Cookie Protection files the server cookie under the embedder's partition,
which makes the keys collide, and a script may not replace an HttpOnly cookie it
collides with. The section now reports the outcome per engine and stops
asserting a causal link the measurements do not show.
PartitionedCookies was called the better answer for either path with no limits
attached. Two apply. The option is global, so Service.Set puts it on the OAuth
callback too, and a cookie partitioned to the popup's own top-level context is
one the frame cannot see, which regresses OAuth on the permissive browsers
where it works today. And HttpOnly removes bearer-token theft, not authenticated
action during an XSS, since the XSRF value stays readable by design and script
on the widget origin can still make requests the browser attaches the cookie to.
The evidence claim was broader than any single run supports. The criterion asks
for sign-in, a post and a reload; the permanent suite does all three but only on
Chromium's default policy against a stack that is not the recommended recipe,
and the cross-browser campaign covered sign-in and reload on the recommended
recipe without posting. Both halves are now stated.
Also: 70 runnable top-level tests, not 71, which counted TestMain; and three
engines across four browser targets, since Safari is a WebKit browser.
Dmitry Verkhoturov
d5ede91a9f