navigator.cookieEnabled in third-party contexts about html HOT 10 OPEN

I think I'm in camp "Build a better alternative that reflects the complexity of the situation and then fully deprecate and remove navigator.cookieEnabled". A lot of the discussions and misunderstandings we're having here are due to the overly simplistic nature of a single boolean for expressing cookie blocking / partitioning rules.

I like where Ari's "Cookie (Storage?) Capabilities API" idea is going, though I think it should include an HTTP request header variant to also solve the problem outlined in privacycg/storage-partitioning#32

cc @shuranhuang @krgovind

from html.

@johannhof @cfredric @sbingler @DCtheTall @bvandersloot

from html.

When we discussed privacycg/storage-access#171 I think I assumed 5.

It seems a bit weird if cookieEnabled returns false when partitioned cookies work.

from html.

I think there's still a question of whether navigator.cookieEnabled means:

• "does this UA support cookies (of any kind) in principle"
  • This seems like it is both 4 and 5? I'm not clear on how those differ, admittedly.
• "does this UA support (possibly partitioned) cookies in this context"
  • This option isn't listed above.
• "does this UA support unpartitioned cookies in this context"
  • This is 6 above.

If we choose the first bullet, every modern browser would return true unconditionally, IIUC.
If we choose the second bullet, Chromium-based browsers would return true unconditionally, while Safari/Firefox would take Storage Access, user settings, etc. into account (based on caniuse).
If we choose the last bullet, then the UA would take Storage Access, user settings, etc., into account.

Is an API that always returns true especially useful? I'm not sure that that's the best option here.

(It may be that that's the only viable option based on existing usage, though. It's plausible that this API is a relic from another time, and has lost its utility but has enough usage that it must still exist.)

from html.

I guess the specification doesn't explicitly mention end user preferences, but that's what I would expect to be taken into account. In particular because of "and false if it ignores cookie change requests" (which is true if the end user has disabled cookies for that website or in general).

from html.

When we discussed privacycg/storage-access#171 I think I assumed 5.

It seems a bit weird if cookieEnabled returns false when partitioned cookies work.

Just to be sure @annevk, you're speaking as a spec editor here right? If so, is there a position that WebKit has you could share?

I'm asking as WebKit, to my understanding, returns true in third-party contexts where no cookies could be set (at least prior to some call to requestStorageAccess). I'm not trying to argue WebKit is uniquely inconsistent for doing this, there are edge cases in Chrome where true is returned despite cookies not being settable, just trying to see if there is some common ground vendors could implement after a spec change or if this API will remain an 'agree to disagree' area.

from html.

It seems a bit weird if cookieEnabled returns false when partitioned cookies work.

Ditto.

Given that this hangs on navigator, I would expect this has to do with the cookie settings for a given UA, not with the context being used. So I would expect it to be true unless a user-preference to disable cookies has been set. If I follow that is what Safari does, and is a reasonable interpretation of the spec.

from html.

It seems we all basically agree on what the spec currently says, but given Safari seems to align while Chrome and Firefox differ, do any of us feel the spec should say something else?

Put another way, @bvandersloot-mozilla do you think cookieEnabled should return true in Firefox in 3p contexts where unpartitioned cookie access is blocked (yet the browser/origin-level cookie setting is enabled)? Or should the spec change?

from html.

Put another way, @bvandersloot-mozilla do you think cookieEnabled should return true in Firefox in 3p contexts where unpartitioned cookie access is blocked (yet the browser/origin-level cookie setting is enabled)?

Not sure what you mean by "(yet the browser/origin-level cookie setting is enabled)" but I agree with " cookieEnabled should return true in Firefox in 3p contexts where unpartitioned cookie access is blocked" generally.

from html.

I have metrics in chrome M125 to measure usage of cookieEnabled in third-party contexts. Once I have some data from that I'll write up a proposal to align Chrome with the spec as it currently exists instead of proposing a change to the spec. The timeline for that might be quite long depending on usage.

from html.