WICG/kv-storage

Thoughts on sessionStorage

Zirro opened this issue · 5 comments

Zirro commented

This proposal only covers async localStorage at the moment, leaving its less common sibling sessionStorage unmentioned. Nevertheless I occasionally see those who recommend using it for handling temporary data.

I'm curious where you stand on this. Could you see it being added as part of this proposal later on? Do you think it should be a separate layered API? Or has the use case for sessionStorage proven small enough that it may not be justified at all?

domenic commented

Somewhat similar to #21, the issue here is again that:

  • We don't think sessionStorage is being used much
  • This is somewhat confirmed by none of the existing localStorage-but-better libraries having a replacement for it
  • But, we don't have any hard data

One point worth discussing though is that I'm not sure how to build a SessionStorage replacement yourself. I.e., when do you call clear()? There's no "new session" notification I'm aware of.

Zirro commented

I agree that sessionStorage is likely seeing little use now, but this might be due to a lack of knowledge about the implications or alternatives to localStorage. With stricter privacy laws such as the GDPR coming into play and requiring more careful handling of data, this might change soon.

There's no "new session" notification I'm aware of.

The data would ideally be cleared at the end of a session rather than when a new one begins, in order to protect against someone else who has access to the machine. I recognise that this might not be possible without new low-level capabilities, though.

Alternatively, a spec like https://github.com/w3c/webappsec-clear-site-data might be able to provide a mechanism which can clear data at the end of a session (or just keeps it in memory at all times), in which case there would be no need for the storage API itself to cover it.

Zirro commented

So, this would probably need whatwg/storage#11 (or w3c/IndexedDB#205, with a session-based rather than time-based option) to be resolved, for this to be possible to implement as a layered API.

I still think it would be nice to keep in mind a potential expansion of the API which could allow for this in the future, by passing an options object to the StorageArea constructor or a third argument to set(), for example. But otherwise - if the low-level capabilities for this just aren't there now - there might not be much left to discuss here at the moment.

developit commented

Just wanted to drop an idea here that came to me in another discussion about sessionStorage and a possible analog within async-local-storage

  • Export a sessionStorage analog as a second instance of StorageArea like we do with storage.
  • Expose a { session: true } option to the StorageArea constructor.