Open Bug 934640 Opened 9 years ago Updated 9 days ago

Implement IDBFactory.databases() to enumerate IndexedDB databases

Categories

(Core :: Storage: IndexedDB, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: daleharvey, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, leave-open, Whiteboard: DWS_NEXT, [wptsync upstream])

Attachments

(3 files)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16137 + http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1537.html for some history

Webkit have implemented a proprietary webkitGetDatabaseNames, implement a matching API with the same semantics (Jonas mentioned adding the version to the information)
Priority: -- → P5
This is actually part of the spec now. See: http://w3c.github.io/IndexedDB/#dom-idbfactory-databases
Let's set this to P3.
Priority: P5 → P3
Spec discussion issue at https://github.com/w3c/IndexedDB/issues/31 and pull request at https://github.com/w3c/IndexedDB/pull/240
Summary: Implement ability to enumerate databases → Implement IDBFactory.databases() to enumerate IndexedDB databases
Whiteboard: DWS_NEXT

Could we get indexedDB.databases() implemented please?

On Firefox it's not possible to remove indexedDB databases by domain. The reason is the lack of indexedDB.databases() support and chrome.browsingData.remove() doesn't support "hostnames" parameter for indexedDB (it only works for cookies and localStorage). So on Firefox WebExtensions can only remove ALL indexedDB databases for all websites or none.

The implication is that privacy related WebExtensions are seriously handicapped on Firefox compared to Chrome and Firefox is supposed to be the go-to-browser for people who care about privacy.

Chrome supports indexedDB.databases();

Assignee: nobody → sgiesecke
Status: NEW → ASSIGNED
Type: defect → enhancement
Status: ASSIGNED → NEW
Depends on: 1593365
Pushed by sgiesecke@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/81e2f38dbf3d
Let 'Ensure that databases() returns a promise' test case accept a rejected Promise to match its description. r=dom-workers-and-storage-reviewers,ytausky
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/20637 for changes under testing/web-platform/tests
Whiteboard: DWS_NEXT → DWS_NEXT, [wptsync upstream]
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Upstream PR merged by moz-wptsync-bot
Assignee: sgiesecke → nobody

The leave-open keyword is there and there is no activity for 6 months.
:jstutte, maybe it's time to close this bug?

Flags: needinfo?(jstutte)

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #12)

The leave-open keyword is there and there is no activity for 6 months.
:jstutte, maybe it's time to close this bug?

Simon?

Flags: needinfo?(jstutte) → needinfo?(sgiesecke)

This is still waiting for Bug 1593365.

Flags: needinfo?(sgiesecke)

The attached patches only provide a stub for the IDBFactory.databases method right now, returning a rejected promise. They work as such, but landing them might confuse feature-detection code. Further work was halted as it turned out that we can't currently query the set of IndexedDB database for an origin from the quota manager in the parent process. Once the quota manager provides this capability, we can implement a an operation on PBackgroundIDBFactory adding another variant to FactoryRequestParams, and call that from the child process.

At the moment, the Storage view in DevTools makes up for this missing functionality by reading all the databases in the profile, which could of course break if the storage format changes.

It would be great to replace this once we have a standard way to list databases such as this API.

Quota manager is also used for centralized storage management (for example, the unified directory structure on disk), so it's not only about quotas. However, we might implement a workaround which doesn't depend on new quota manager features.

Severity: normal → --
OS: macOS → Unspecified
Hardware: x86 → Unspecified

I was directed here from https://github.com/facebook/sapling/issues/148 because https://reviewstack.dev does not work in Firefox right now because this API is not supported.

From my perspective, I consider this a security issue because not being able to enumerate the databases means that a website has no API it can use to ensure it has removed all of a user's data when they run a "Logout" action of sorts within a web application.

It also prevents a website from removing all IndexedDB data when a user logs in to ensure they start from a clean state.

Note that the Clear-Site-Data header exists and when used with the "storage" key will comprehensively clear storage API data for the origin and should be preferred if the high level goal is to remove all of a user's data for an origin. This is the most reliable and comprehensive mechanism available. In the future, https://github.com/WICG/storage-buckets should allow more granular but still comprehensive clearing on a per-bucket basis as well.

(In reply to bolinfest from comment #19)

I was directed here from https://github.com/facebook/sapling/issues/148 because https://reviewstack.dev does not work in Firefox right now because this API is not supported.

From my perspective, I consider this a security issue because not being able to enumerate the databases means that a website has no API it can use to ensure it has removed all of a user's data when they run a "Logout" action of sorts within a web application.

It also prevents a website from removing all IndexedDB data when a user logs in to ensure they start from a clean state.

Surely a website knows the set of names it may or may not have created ... so can delete all whether they exist or not.

(Unless someone is naming their DBs in a non-deterministic way, which seems unlikely and unwise)

Surely a website knows the set of names it may or may not have created ... so can delete all whether they exist or not.

For a large complex application, this might be true in theory, but in practice keeping track of all databases and making sure they are all cleaned up on logout might not be very practical.

You need to log in before you can comment on or make changes to this bug.