RFP: Cookie Change Events about standards-positions HOT 12 CLOSED

CC @jdm based on the Gecko module owner page.

from standards-positions.

Not being an expert in this area of the engine, the general idea of having an event instead of polling seems reasonable, but ChangeCause exposure in the API may be a problem in terms of allowing sites to detect more privacy-oriented browser configurations and discriminating against users who've chosen such configurations.

from standards-positions.

CC @tefn3849

from standards-positions.

From an email exchange with Overholt about this:

I'm not sure if the network team will have an opinion here, since this doesn't actually affect how 
cookies are processed by the network stack. My initial reaction is that we're not actually interested in 
making cookies easier to use (and certainly that's the IETF's position in regards to proposals to add 
new features to the cookie parsing and storage specifications), but I feel like people on the DOM team 
are in a better position to make that call. Figuring out how much use document.cookies sees would 
help guide that decision.

from standards-positions.

I forgot that @asutherland may have an informed opinion here.

from standards-positions.

I would be more comfortable if we worked through whatwg/html#804 first before exposing the underlying issues in more ways.

(There's also some inherent issues with cookies: eTLD+1 (though this is also why they continue to be popular); HttpOnly flag creating all kinds of trouble for JavaScript APIs).

from standards-positions.

From an implementation flexibility perspective, implementing this seems undesirable. Specifically, https://github.com/patrickkettner/cookie-change-events/ proposes an unfiltered DOM event, whereas the similar-but-different[1] https://github.com/WICG/cookie-store/ allows for specifying specific interests. Based on discussion with jdm, we currently do broadcast all cookie changes, so we could implement this as proposed, but it would limit future optimizations.

A perhaps stronger argument for not implementing cookie-change-event is to allow the async cookie-store API to have a carrot. When switching to its observer mechanism, developers might hopefully switch to using its async API at the same time.

1: patrickkettner/cookie-change-events#14 includes some discussion of the differences between the proposals.

from standards-positions.

My reading of the comments is that our position is negative. @dbaron, how do we proceed from here? Do you make a call for the position?

from standards-positions.

I strongly suspect this is abandonware at this point.

from standards-positions.

Dropping WICG label, as this was never adopted by the WICG either.

from standards-positions.

@patrickkettner, you are no longer pursuing this, right?

from standards-positions.

from standards-positions.