Intent to Prototype and Ship: Align navigator.cookieEnabled with spec

228 views
Skip to first unread message

Ari Chivukula

unread,
Apr 30, 2024, 7:15:41 AMApr 30
to blink-dev, Ari Chivukula, Johann Hofmann

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

Internals>Network>Cookies


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

https://crbug.com/335553590


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6227655153418240


Mike Taylor

unread,
Apr 30, 2024, 11:32:35 AMApr 30
to Ari Chivukula, blink-dev, Johann Hofmann

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

Internals>Network>Cookies


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

https://crbug.com/335553590


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6227655153418240


--
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.

Rick Byers

unread,
Apr 30, 2024, 11:35:00 AMApr 30
to Mike Taylor, Ari Chivukula, blink-dev, Johann Hofmann
Seems maybe like we introduced a bug in regressing from expected behavior and this could arguably be handled as a bug-fix?

Regardless LGTM1

Ari Chivukula

unread,
Apr 30, 2024, 11:36:51 AMApr 30
to Rick Byers, Mike Taylor, blink-dev, Johann Hofmann
We discussed having this be a PSA+fix, but since developers testing 3PCD have been living in this world for a while and Firefox also has the behavior, it seemed better to go the long route.

~ Ari Chivukula (Their/There/They're)

Rick Byers

unread,
Apr 30, 2024, 12:10:51 PMApr 30
to Ari Chivukula, Mike Taylor, blink-dev, Johann Hofmann
Ah good point, thanks. Thanks for your attention to web compat detail here. Really any bug fix has the potential to be a significant breaking change so the line is very context-dependent. 

Rick

Yoav Weiss (@Shopify)

unread,
Apr 30, 2024, 12:49:58 PMApr 30
to Rick Byers, Ari Chivukula, Mike Taylor, blink-dev, Johann Hofmann

Philip Jägenstedt

unread,
Apr 30, 2024, 6:40:33 PMApr 30
to Yoav Weiss (@Shopify), Rick Byers, Ari Chivukula, Mike Taylor, blink-dev, Johann Hofmann

Chris Harrelson

unread,
May 1, 2024, 11:51:21 AMMay 1
to Philip Jägenstedt, Yoav Weiss (@Shopify), Rick Byers, Ari Chivukula, Mike Taylor, blink-dev, Johann Hofmann
Please fill out the cross-functional reviews (privacy, security, debugging, etc) for your intent before shipping.

Reply all
Reply to author
Forward
0 new messages