Discuss limits applied to storage.session API

[oliverdunk]

storage.session allows extensions to store a small amount of data in memory which persists across background lifetimes. This can be useful for extensions such as password managers which need to store unlock secrets (which should never be persisted to disk) or other extensions which have session data like an authentication token from a server.

Since this API is intended for small amounts of sensitive data, and uses memory which is often a limited resource, the API in Chrome is currently limited to 1MB of data. However, we've had feedback that an increase would be beneficial. We've discussed with other browser vendors, and we're supportive of increasing the limit to 10MB.

There could also be some interesting discussion here about how sizes are calculated but there is not an intention to block on that short term.

Opening this to discuss further and reach some alignment.

[frivain]

Hi @oliverdunk my understanding is that Google was already planning to increase the limitation based on https://developer.chrome.com/docs/extensions/mv3/known-issues/#increased-session-storage-quota
Do we have more details about this?

[oliverdunk]

@frivain Yeah, exactly. We (Google) have tentatively settled on 10MB but wanted to raise it in the group before finalising a decision there 🙂

(In case the affiliation is confusing, I recently moved from 1Password to Google and am now working in DevRel there)

[xeenon]

Safari recently bumped the limit to 10 MB in Safari Technology Preview 163.

[Rob--W]

Firefox has yet to implement the storage.session API (https://bugzilla.mozilla.org/show_bug.cgi?id=1687778), but we're supportive of a 10 MB quota.

[tophf]

Just because the motivational case was about a password, it's not the only case that needs a solution. Conceptually, this API should be considered a replacement for the variables of a persistent background script. Ideally it could hibernate the entire JS heap, but it's unlikely to happen any time soon, so for now the API should at least support all structured cloneable types by design even if the other API in chrome.storage family don't support it (e.g. in Chrome) because the serialized string is 2-10 times bigger than the internal binary data, which quickly exhausts the limits. Also, to serialize binary things like Uint8Array or ArrayBuffer/Blob extensions have to waste a lot of time in JS even for 1MB of data (~20ms on a moderately fast PC).

[tophf]

Maybe the limit should be dynamic and depend on the amount of available RAM, the extensions should query the limit by using a new method chrome.storage.session.getQuota or getAvailable or getBytesAvailable. The same should probably apply to all storage areas - because this is how browsers already behave in regards to allocating disk storage. I've heard of corporate setups where users had hundreds of force-installed extensions (auto-generated, I presume), so multiply it by 10MB and you'll get gigabytes of mandatory RAM allocation, which would be infeasible on a lower tier device. On a beefier device (32GB+ of RAM isn't that rare) with just a few extensions installed I would expect the limit to be [much] higher than 10MB, as well as the default SW kill timer to be much longer than 30 seconds.

[lukeselker]

Very excited about the support behind this! Do we know in what Chrome version the upgraded 10MB limit might be available?

[bershanskiy]

Out of curiosity, is there anything preventing extensions from storing lots of data in storage.local and then storing only encryption keys in storage.session? I understand the concern about latency associated with extra processing, but is it really that significant? From my experience, I most of the time I am able to find a way (case-specific) to prefetch data before it is actually needed.

[tophf]

Even if we disregard the extra time to encrypt/decrypt the data, storing volatile data to disk is 1000+ times slower than storing it in-memory, it unnecessarily reduces overall performance of the browser and computer, it also wears down an SSD and incurs significant latencies on an HDD once the data is flushed.

ManifestV3 was designed to increase performance by switching to a service worker, but this won't be true for extensions that have to waste time and resources to rebuild a complex state every time the SW restarts in case it happens frequently i.e. every minute.

[oliverdunk]

Do we know in what Chrome version the upgraded 10MB limit might be available?

Nothing to share at the moment. Given it's just bumping a limit I'm hoping we'll be able to do it soon.

Out of curiosity, is there anything preventing extensions from storing lots of data in storage.local and then storing only encryption keys in storage.session? I understand the concern about latency associated with extra processing, but is it really that significant?

Nothing prevents extensions from doing that, but I do think the latency can be significant. For example, if an extension wants to know if it has data relating to a specific website, this is the difference between decrypting a wide range of data or just looking at an in-memory list of domains.

[Rob--W]

Chrome has implemented this: https://bugs.chromium.org/p/chromium/issues/detail?id=1385167

It will be available in Chrome 112.

[Rob--W]

Firefox does currently not enforce any limit in storage.session; the bug about enforcing a limit is at https://bugzilla.mozilla.org/show_bug.cgi?id=1908925

[polywock]

@oliverdunk Not sure if this is already known, but It seems like the storage.session API becomes non-functional if a user enables chrome://flags/#enable-experimental-web-platform-features. Very peculiar.

To reproduce (Mac - Chrome 128)

1. Enable chrome://flags/#enable-experimental-web-platform-features
2. Restart Chrome.
3. Inspect the service worker, popup or options page of any MV3 Chrome extension and try accessing chrome.storage.session through the console.

[oliverdunk]

@oliverdunk Not sure if this is already known, but It seems like the storage.session API becomes non-functional if a user enables chrome://flags/#enable-experimental-web-platform-features.

Hmm, I'm not able to reproduce this on either 128.0.6613.137 or 130.0.6713.0. If you're still seeing this in the latest Canary, could you file a Chromium bug? It is likely best to avoid discussing this too much here regardless :)

[polywock]

Looks like it's no longer an issue on Canary.