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?

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

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

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.

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

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.

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

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.

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.

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.

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

It will be available in Chrome 112.