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) On Tue, Apr 30, 2024 at 11:34 AM Rick Byers <rby...@chromium.org> wrote: > Seems maybe like we introduced a bug in regressing from expected behavior > and this could arguably be handled as a bug-fix? > > Regardless LGTM1 > > On Tue, Apr 30, 2024 at 11:32 AM Mike Taylor <miketa...@chromium.org> > wrote: > >> On 4/30/24 7:15 AM, Ari Chivukula wrote: >> >> Contact emails >> >> aric...@chromium.org, johann...@google.com >> >> Specification >> >> https://html.spec.whatwg.org/multipage/system-state.html#cookies >> >> Summary >> >> navigator.cookieEnabled >> <https://developer.mozilla.org/en-US/docs/Web/API/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) >> <https://developers.google.com/privacy-sandbox/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 >> <https://developer.mozilla.org/en-US/docs/Web/API/Navigator/cookieEnabled> >> which indicated only if cookies were enabled/disabled for the site and rely >> on the cross-vendor function document.hasStorageAccess >> <https://developer.mozilla.org/en-US/docs/Web/API/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 >> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork%3ECookies> >> >> >> Motivation >> >> Divergence in the meaning >> <https://developer.mozilla.org/en-US/docs/Web/API/Navigator/cookieEnabled> >> 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 >> <https://github.com/whatwg/html/issues/10256> 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 >> <https://developers.google.com/privacy-sandbox/3pcd> 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 <https://chromestatus.com/metrics/feature/timeline/popularity/4937> >> 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. >> <https://github.com/whatwg/html/issues/10256#issuecomment-2049750772> 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 >> <https://developer.mozilla.org/en-US/docs/Web/API/Navigator/cookieEnabled> >> >> 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+unsubscr...@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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DLy9XBAFOyPdfRHE70nUStV0fAVWVSjL1xZDG7Mr4xnFQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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+unsubscr...@chromium.org. >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34b3594a-4d10-4eaa-a341-7b173aff1eee%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJvDPcQfy-v1c9Ls0XfGXc_nULjqK%3Dvh896xdN5cVK9Cg%40mail.gmail.com.
