WICG
Deprecating cookies
Per https://twitter.com/mikewest/status/1029260180456976384 @mikewest would like to deprecate cookies. That doesn't really seem feasible to me (depending on whether it implies eventual removal), but adding a new API dedicated to cookies certainly doesn't help.
How is this conflict resolved?
@mikewest does not like cookies. But @mikewest is also pretty clear on the point that deprecating cookies isn't going to happen tomorrow. Something on the order of years seems like a best case. Shipping an API that does a better job managing them than document.cookies does seems like a totally reasonable stopgap while I work on realizing my dreams of reinventing HTTP state management.
I don't see cookies getting removed in less than 5 years so, to the best of my knowledge, the use cases in the explainer will still be valid in the next 5+ years. Chrome is interested in addressing these use cases. I think that's enough justification to maintain this repository and develop the specification in it.
At this point, I think the discussion in this repository should be focused on improving the API. I would welcome any feedback in that direction.
Even if they aren't removed, if we don't want them to be used, we shouldn't be adding more API surface.
Where do you think this discussion should be had?
Sorry I missed your response earlier in the week, @annevk!
I don't really see how. It seems this will only further cement their use.
I don't think we can get much further than 100%. Cookies are the foundation upon which authentication (and state generally) is built. This API does not increase their usage, it instead gives folks the ability to use them more judiciously, and to make better decisions about whether they should be trusted.
The one place I do think it can be said to broaden scope is Service Workers, which don't currently have explicit access to cookies. These scopes do, however, have implicit access to cookies through terrible, server-side reflection APIs which folks periodically ping to determine things like signed-in status. That's bad! It would be better if folks didn't build those server-side endpoints!
(As an aside, are there folks at Mozilla interested in the cookie replacement scheme I'm proposing? The most recent response I got from @martinthomson (https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0257.html) was not exactly overwhelming in its effusive support. :) Regardless, I plan to have an I-D at least somewhat sketched out by TPAC... perhaps we can chat about it there?)
I've reopened the issue to track of the fact that there's still something to figure out here.
@annevk I don't understand what we'd be discussing, and I hope you can help. It seems to me that you're claiming that the use cases in the explainer aren't worth a new API. I'm stating that, as far as Chrome is concerned, the use cases deserve a new API, and we will ship something that addresses them.
Given that Chrome is interested in shipping an API, I think it makes sense to design the API using an open process. I would very much like to get feedback on what the API should look like. I suspect you're not suggesting that we should ship an API without a specification 😄
@mikewest this increases the scope of cookie access to all worker types, not just service workers, and makes it more convenient for documents as well. If your position is that cookies shouldn't be used, that doesn't make a lot of sense. I'm personally not really persuaded we can get rid of them, but as long as that idea exists I wouldn't want us to add to the problem.
@pwnall the use cases in the explainer center around the fact that cookies will continue to be valuable going forward. I'm questioning that assumption per OP.
@mikewest this increases the scope of cookie access to all worker types, not just service workers, and makes it more convenient for documents as well. If your position is that cookies shouldn't be used, that doesn't make a lot of sense.
My position is that we can and should do better than cookies, and should work towards phasing them out over time. My position is also that cookies' usage is already fully saturated, and that this API does not meaningfully increase their usage in a way that makes them any more difficult to remove than they are today. The use cases the API addresses are already heavily used today, in ways that are detrimental to either performance (polling document.cookie (or, worse, a server-side endpoint) for signed-in state), or security (because attributes aren't visible via existing APIs). Serving those use cases in less-terrible ways seems reasonable to me.
I'm personally not really persuaded we can get rid of them, but as long as that idea exists I wouldn't want us to add to the problem.
This is a difficult position to reconcile. If it's not possible to get rid of cookies, then objecting to this API doesn't make sense. If, on the other hand, it's likely that we can work together to get rid of cookies, wonderful. Let's do so! (Is that your position? Is it Mozilla's?) It's consistent with the ideals of that position to argue that we shouldn't extend their scope, period.
I personally think the short-term practical concerns briefly sketched above outweigh the principled concerns, mostly because I think we're already at 100% usage.
@annevk Cookie access from JS is a highly used feature -- the document.cookie setter and getter are used in about 75% of all page views in Chrome. Given prior experience around deprecating features, it seems fairly safe to assume that cookie usage will not get low enough in 5-10 years to admit deprecation.
You're welcome to argue that my assumption is incorrect. Your arguments would have to be incredibly strong to outweigh current data and the expressed interest from developers. Until such an argument is presented, I will not be engaging in conversations around the strength of the use cases.
I still hope we can collaborate on the API shape before Chrome ends up shipping it.
I'm not arguing you're incorrect, @mikewest is. And I'm willing to be persuaded by him that it's worth trying. And if we try, we shouldn't add APIs we'd end up removing anyway. New features should be around for the long term.
I'm not arguing you're incorrect, @mikewest is.
@mikewest is incorrect? Or @mikewest is arguing that @pwnall is incorrect?
And I'm willing to be persuaded by him that it's worth trying. And if we try, we shouldn't add APIs we'd end up removing anyway. New features should be around for the long term.
I guess this means that you disagree with my comments above?
The latter and yes, I disagree with your comments to some extent. I don't think features that would only be around for a short while are worth adding to the platform. We need to design for the long term.
I don't think features that would only be around for a short while are worth adding to the platform. We need to design for the long term.
A relevant question is what "short" means.
It seems like we're all agreeing in this thread that cookies are going to be around for a while. I think they're possible to remove eventually, I'm not sure if y'all agree with me. It seems like the position of someone who thinks they're impossible to remove would be "This is a better API than what we have and it solves some interesting problems. Let's ship it." It seems like the position of someone who agrees with me could be "This is a better API than what we have and it solves some interesting problems. Let's ship it while we work on solving more fundamental problems that are going to take a while to solve."
I don't think doing both is responsible. There's a cost whenever we add to the platform. In terms of implementation, documentation, getting folks to use the API, etc. If we already know we plan to remove it again we shouldn't impose that cost on the web. That might work for Google, but for many other players those tactics don't scale.
I don't think doing both is responsible. There's a cost whenever we add to the platform. In terms of implementation, documentation, getting folks to use the API, etc. If we already know we plan to remove it again we shouldn't impose that cost on the web. That might work for Google, but for many other players those tactics don't scale.
Then we come back to my original question: does Mozilla want to spend its resources working on a cookie replacement? If so, then sure, let's talk about prioritization. If not (and, as noted above, the indications I've gotten through now have been that Mozilla is not interested in engaging at this point), then there's no need to have a prioritization discussion.
- I can't really speak for Mozilla, but they're not the only player who'd need to be involved in such a decision.
- It's not about prioritization in my view. It's a mutually exclusive choice.
- Indeed. I look forward to chatting with more folks on the topic!
- I don't agree. Like, at all. :) Given the timelines we're looking at (and the complexity of the API we're talking about), a choice we make here does not preclude contradictory choices in the future.
(I speak as an individual developer, not for all of Google.)
Adding a feature to the platform does have a cost. This cost should be balanced with the benefits it provides by meeting developer demands. The Web is built by developers who have needs. If enough of these needs aren't satisfied, these developers will eventually go to a different platform.
We can't ask today's developers to wait 10 years for solutions to today's performance problems to become obsolete. The Web will become irrelevant if we ignore our developers' demands.
Chrome is planning to ship a form of the Cookie Store API, as the solution the cookie access problem for the next 5+ years. If you have any suggestions on concrete API changes that would make the cost more palatable to Mozilla, we're open to feedback.
I think its detrimental to spec conversations if folks can't discuss possible far-reaching architectural plans without freezing all related near-term work. It disincentives people to even consider larger changes.
It would be great if we could do a small sidebar on this at TPAC. This API is scheduled for Monday afternoon in WebPlat, so it would be nice if we could chat Monday morning or over lunch.
To address the original question: we should not wait on a potential replacement for cookies before providing better APIs that developers need.
While deprecating cookies may be what we do in the future, treating that long-term outcome as somehow being in opposition to solving a pressing problem is a false dichotomy. Separating these conversations is the only approach that will allow us to make forward progress in a timely manner.
I'm guessing that some of you have a sense of what a "modern" alternative for cookies would look like. If so, could this be made explicit?
If I had to guess, I suspect the intended direction might be that developers manually persist authentication data to relevant storage APIs (sessionStorage, localStorage, or IndexedDB), and these would presumably be communicated to/from the server through HTTP headers, with one key/value pair per header. Thus removing the need for a syntax or API to access key values, given we already have an API for creating and reading headers.
If that's the case:
- The upside of that is that for XHR/Fetch, browsers no longer have to awkwardly synchronise cookie state between all ways of sending and receiving requests (for origins where cookie aren't used). For authentication data, developers would only update their storage from the response headers on routes where they expect a session to start/end/extend, and not all other misc requests, like for cookies.
- On the other hand, it won't work for navigations. Main thread can't be read or send headers. . I suppose a Service Worker could be used for that, but do we really want to enforce use of SW for a all websites needing session/authentication within the realm of non-deprecated web platform features? Also, it'd need a guarantee that the SW can't expire before all the storage related with an origin. I might be wrong, but I thought that's not the case currently.
- IndexDB and LocalStorage don't support automatic expiration, which would it uncomfortable to use for authentication data. SessionStorage does expire, but has the problem of not working reliably across an origin during a browsing session, due to being limited to a single branch of tabs / browsing contexts. As such, which storage API would we recommend?
Just as a thought-experiment: Is it possible to create an API that is useful both for cookies in the short term and for whatever people are considering to replace them in the long term? Or are the proposed replacements sufficiently different from cookies that this is not really feasible or desirable? (Or are we unsure enough about said proposed replacements that we really can't say for sure?)
Is it possible to create an API that is useful both for cookies in the short term and for whatever people are considering to replace them in the long term?
https://github.com/mikewest/http-state-tokens/#a-proposal suggests that we deny JavaScript access to the HTTP state entirely, with a small carveout for a BroadcastChannel message when the token is reset (in order to handle cleanup after signout). That seems useful in a world where the browser controls the token's state, but is less viable in a world where the actual contents of cookies are useful for dealing with complex state like multi-login.
FYI, @mikewest just published:
https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
