I would like to unship the proprietary "storage" attribute in
indexedDB.open()[0]. It allows developers to prevent their indexedDB
storage from being evicted as part of quota management[1]. However,
there is a web standard which specifies a better persistent storage
mechanism and has broader vendor support[2].

There are several issues with the old proprietary version:

- It's only supported by Firefox.
- It can be used over insecure HTTP, which is against the persistent
storage spec.
- Its internal mechanism is only concerned with indexedDB and does not
integrate with other quota managed storage.
- We actually need to maintain two separate permissions that do more or
less the same thing ("indexedDB" and "persistent-storage"). The UI for
managing these looks almost exactly the same and it's impossible to
clarify the difference. It's a pretty annoying security/privacy UX issue
and difficult to justify to users.

The plan is to ignore the "storage" attribute and label all databases
opened from iDB.open as default (i.e. dependent on the persistent
storage mechanism).

Before doing this, we will issue a deprecation warning in the browser
console and write a blog post on Mozilla Hacks. Affected websites could
lose their indexedDB data (equivalent to the user clearing their
cookies), unless they migrate to the new storage model.

We are tracking this work in bug 1354500

We have seen very low usage on beta[3], with the exception of a spike in
November which we attribute to about:home usage from a/b testing. After
we stopped counting usage from about: pages on Nightly, the telemetry
probe stopped signaling completely[4].

I personally consider these numbers (prior to any evangelism or console
warnings) low enough to unship within the Firefox 62 timeframe, without

Chrome callers should not be affected by this, since we upgrade the
system principal to persistent storage automatically.

Please let me know what you think.



[0] https://developer.mozilla.org/en-US/docs/Web/API/IDBFactory/open#Syntax
[2] https://storage.spec.whatwg.org/
[3] https://mzl.la/2GVyQ7g
[4] https://mzl.la/2FqW0FH
dev-platform mailing list

Reply via email to