Risk of abuse due to lack of simple client-side storage API

[annevk]

@asutherland raised an interesting point which is that since we lack key-value-based storage in many of the environments this API will be exposed in, it might end up getting abused a lot to get those semantics, resulting in a lot more cookies.

[asutherland]

To elaborate a little, my argument is more that Firefox would want to expose something like https://github.com/domenic/async-local-storage (once the layered API standardization foot-gun issue is addressed) before exposing this API because of the risk of misuse in places like ServiceWorkers where LocalStorage is not exposed and IndexedDB is frequently avoided for both dubious and legitimate reasons. (And ideally all browsers would make a concerted effort to optimize for initial async-local-storage/other get() lookup to make sure the latency of the API is roughly on par with the cookies API much like LocalStorage is today.)

[pwnall]

This seems be a cross-API concern regarding how we deploy APIs in browsers. I'm not sure what this specification / explainer could do to address the concern.

FWIW, the API announcement on developers.google.com starts with "You (probably) don't need cookies". I'd be happy to discuss any concrete suggestions for helping developers choose the right storage APIs for their problems.

[annevk]

The problem is that we don't have an alternative API to recommend.

[annevk]

I would reopen this, but the way GitHub works prevents that.

[pwnall]

I reopened the issue.

It seems to me that "we don't have an alternative API to recommend" is not something that could be solved in this repository. Please help me understand better if I'm wrong.

[domenic]

I sympathize with the OP's perspective here, and think this is a genuine issue worth discussing about cookie store. (However, I'll note that @pwnall seems to prefer an issue management style where issues only track things that are fixable by changing spec text, whereas @annevk is assuming the perhaps-more-common issue management style of using the issue tracker to track issues in the space of the proposal.)

I agree that shipping async local storage is an ideal mitigation for this. However, at least for Chrome, I don't think it should be a strict blocker. The timelines don't line up very well; we have web developers in need of the new capabilities this API provides in the cookie space, and we should give it to them as soon as feasible. From what I understand, cookie store is ready to deliver that value now-ish. Whereas, shipping async local storage is blocked on both standards and implementation work around making built-in modules feasible. Resolving those things is my day-job P0, but I'd still estimate it'd be at least Q1 2019 before async local storage would be shippable.

In that hopefully-short interim period, I think we can do our best to mitigate the problem pointed out by the OP via outreach and education. The spec might be one place for this; developers.google.com is another; you can imagine more. And certainly other browsers might make different tradeoffs, weighing the use cases solved by this proposal vs. the risk of unknowing cookie abuse, which could lead to a different shipping order for the two specs.

Hope this helps!