Contact emails
ari...@chromium.org, joha...@google.com
Specification
https://html.spec.whatwg.org/multipage/system-state.html#cookies
Summary
navigator.cookieEnabled currently indicates if “the user agent attempts to handle cookies” in a given context. A change in Chrome, shipping as part of third-party cookie deprecation (3PCD), would cause it to indicate whether unpartitioned cookie access is possible (causing it to return false in most cross-site iframes). We should restore the prior behavior of navigator.cookieEnabled which indicated only if cookies were enabled/disabled for the site and rely on the cross-vendor function document.hasStorageAccess to indicate if unpartitioned cookie access is possible.
Blink component
Motivation
Divergence in the meaning of navigator.cookieEnabled will cause confusion as Chrome rolls out 3PCD. We have a window, before 3PCD ships, to restore prior behavior now that there is some amount of consensus between browser vendors on what navigator.cookieEnabled should indicate in third-party contexts.
TAG review
This is a minor change to align browsers on standardized behavior so we did not request TAG review.
Compatibility
Some websites adapting to Chrome’s 3PCD rollout may have used navigator.cookieEnabled as a proxy for document.hasStorageAccess, but we will start recommending the use of hasStorageAccess moving forward. To be clear, the behavior change is only web-observable in Chrome instances where third-party cookie blocking is turned on. Metrics on third-party context use of navigator.cookieEnabled are being gathered in M125, but without 3PCD fully rolled out the impact should be minimal, especially where websites wish to support Safari (which already adopts the behavior we propose aligning with).
Safari is already aligned but Firefox mirrors current Chrome behavior.
Gecko: Preliminary positive feedback. We asked if they’d like us to file a standards position for this relatively minor change, and they said it’s not needed.
WebKit: Shipping
Web developers: No Signal
Access to cookies and unpartitioned cookies is visible in DevTools.
Is this feature fully tested by web-platform-tests?
Testing the effects of user-provided cookie settings on this function cannot be done in WPTs.
Tracking bug
Link to entry on the Chrome Platform Status
On 4/30/24 7:15 AM, Ari Chivukula wrote:
Contact emails
ari...@chromium.org, joha...@google.com
Specification
https://html.spec.whatwg.org/multipage/system-state.html#cookies
Summary
navigator.cookieEnabled currently indicates if “the user agent attempts to handle cookies” in a given context. A change in Chrome, shipping as part of third-party cookie deprecation (3PCD), would cause it to indicate whether unpartitioned cookie access is possible (causing it to return false in most cross-site iframes). We should restore the prior behavior of navigator.cookieEnabled which indicated only if cookies were enabled/disabled for the site and rely on the cross-vendor function document.hasStorageAccess to indicate if unpartitioned cookie access is possible.
I find it surprising that we changed the behavior of cookieEnabled in https://groups.google.com/a/chromium.org/g/blink-dev/c/RG0oLYQ0f2I/m/xMSdsEAzBwAJ - that wasn't clear to me when I LGTM'd. That said, HTML is shelling out to RFC6265 - and the eventual promotion of 6265bis and subsequent Cookie Layering work should make it all make sense in a 2024+ context one day soon (one can dream, anyways).
(Note I'm recused on voting from this one).
Blink component
Motivation
Divergence in the meaning of navigator.cookieEnabled will cause confusion as Chrome rolls out 3PCD. We have a window, before 3PCD ships, to restore prior behavior now that there is some amount of consensus between browser vendors on what navigator.cookieEnabled should indicate in third-party contexts.
TAG review
This is a minor change to align browsers on standardized behavior so we did not request TAG review.
Compatibility
Some websites adapting to Chrome’s 3PCD rollout may have used navigator.cookieEnabled as a proxy for document.hasStorageAccess, but we will start recommending the use of hasStorageAccess moving forward. To be clear, the behavior change is only web-observable in Chrome instances where third-party cookie blocking is turned on. Metrics on third-party context use of navigator.cookieEnabled are being gathered in M125, but without 3PCD fully rolled out the impact should be minimal, especially where websites wish to support Safari (which already adopts the behavior we propose aligning with).
Interoperability
Safari is already aligned but Firefox mirrors current Chrome behavior.
Gecko: Preliminary positive feedback. We asked if they’d like us to file a standards position for this relatively minor change, and they said it’s not needed.
WebKit: Shipping
Web developers: No Signal
Debuggability
Access to cookies and unpartitioned cookies is visible in DevTools.
Is this feature fully tested by web-platform-tests?
Testing the effects of user-provided cookie settings on this function cannot be done in WPTs.
Tracking bug
Link to entry on the Chrome Platform Status
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DLy9XBAFOyPdfRHE70nUStV0fAVWVSjL1xZDG7Mr4xnFQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34b3594a-4d10-4eaa-a341-7b173aff1eee%40chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-neGM13DGpkgwX-FDhZdAU9yR_vqGb-vf54pNqpTXcBg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJmt%2BQYtCXunjvFFjD_0O1ajUiC6ARCkN3z0eRzfjT3ow%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdps%3Du3UR9yxU%3D_BFDvszbQmE2CF1RQ4avDCtd91kAExw%40mail.gmail.com.