Partitioned cookies no longer sent to other localhost domains
Categories
(Core :: Networking: Cookies, defect, P2)
Tracking
()
People
(Reporter: boreenpt, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: webcompat:platform-bug, Whiteboard: [necko-triaged])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
Steps to reproduce:
Set a partitioned cookie (that is, a cookie with the Partitioned attribute) on one localhost origin (e.g. https://localhost:44312).
Open a page on a different localhost origin (e.g. https://localhost:44311).
Actual results:
The page in the second localhost origin is not sent the cookie from the first origin. Also, the cookie cannot be seen in the Storage -> Cookies tab for either origin.
Expected results:
The cookie from the first origin should have been sent with the request to the second, and the cookie should be visible in the Storage -> Cookies tab.
Removing the Paritioned attribute, testing with non-localhost origins with the Domain attribute set, or repeating this test in Chrome causes the cookie to be sent to the second origin as expected. (Though the cookie still cannot be seen in the second case, where it is Partitioned on a non-localhost site).
Sorry, that last sentence should have read "still cannot be seen in the Storage -> Cookies tab in the second case".
Comment 2•1 year ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking: Cookies' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
The devtools aspect of this bug should be handled by the existing Bug 1895215.
I am able to reproduce the issue. Still investigating.
Updated•1 year ago
|
Note: this does not happen in chromium
It would appear that CHIPS is overly strict about the host in the partitionKey of the origin attributes rfc6265bis-15 says that cookies will be available across ports.
Tim, should we consider removing the port from the partitionKey string?
Comment 7•1 year ago
|
||
This is expected behavior. Our partitioning, which is opted into via the Partitioned attribute even in first-party contexts, uses the port as well.
I have opened an issue against the specification to see if this difference in behaviour can be addressed there: https://github.com/privacycg/CHIPS/issues/92
Comment 9•10 months ago
|
||
Maybe INVALID isn't right, as we are going to resolve this with Bug 1970207.
Regardless, I'm just going to make this see also there.
Comment 10•9 months ago
|
||
I'd call this RESOLVED FIXED now.
Description
•