RFP: Cookie Change Events

[hsivonen]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Cookie Change Events
• Specification or proposal URL: https://patrickkettner.github.io/cookie-change-events

Other information

Currently, for a page to become aware of cookie changes made by another browsing context with a page from the same site open, the page has to poll document.cookie. The feature being proposed makes polling unnecessary by introducing an event that can be listened to instead.

See also an explainer.

[hsivonen]

CC @jdm based on the Gecko module owner page.

[hsivonen]

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.

[hsivonen]

CC @tefn3849

[jdm]

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.

[overholt]

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

[annevk]

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

[asutherland]

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.

[hsivonen]

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?

[annevk]

I strongly suspect this is abandonware at this point.

[marcoscaceres]

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

[marcoscaceres]

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

[patrickkettner]

Sadly

On Mon, Jun 24, 2019 at 11:44 PM Marcos Cáceres ***@***.***> wrote: @patrickkettner <https://github.com/patrickkettner>, you are no longer pursuing this, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#50?email_source=notifications&email_token=AADRUBQBWVK7VXAX5F4T2UTP4GIANA5CNFSM4EDNNVMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYO43UY#issuecomment-505269715>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADRUBQFXZTJJHPCB3DKC7LP4GIANANCNFSM4EDNNVMA> .

-- patrick