Intent to Deprecate: IDBFactory webkitGetDatabaseNames

[Joshua Bell]

Primary eng (and PM) emails

jsb...@chromium.org

Summary

Remove the non-standard webkitGetDatabaseNames() method on IDBFactory. 

Note that the spec has never had a non-prefixed version. This has always been Chrome-only.

Motivation

We added this feature when Indexed DB was relatively new in Chrome and prefixing was all the rage. The API asynchronously returns a list of existing database names in an origin, which seemed sensible enough.

The design is flawed, in that the results may be obsolete as soon as they are returned, so it can really only be used for logging, not serious application logic. The github issue https://github.com/w3c/IndexedDB/issues/31 tracks/links to previous discussion on alternatives, which would require a different approach. While there's been on-and-off interest by developers, given the lack of cross-browser progress here the problem has been worked around by library authors.

Compatibility And Interoperability Risk

Edge: Not supported

Firefox: Not supported

Safari: Not supported

Web developers: Requested, but only used in a handful of libraries due to lack of cross-browser adoption. Comes up on StackOverflow every so often.

Alternative implementation suggestion for web developers

Ostensibly, an origin should know a priori what code it has previously shipped and therefore what databases may have been created. In practice, many sites use libraries (like Dexie.js) which abstract away database creation in various ways. Due to the lack of cross-browser support here, libraries do things like storing such metadata in another database.

In general, origins can just ignore databases they don't care about. The case where this is problematic is if a database holds a sizable amount of data and is then "forgotten" by the developers, consuming the origin's quota. Without the ability to enumerate, the only recourse here for the origin would be via the Clear Site Data mechanism.

Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/1273

Usage was at 0.001% until a few weeks ago when it spiked up to 0.01% with a bimodal distribution which is a bit odd. Reading the tea leaves, I'd guess a big site (possibly an analytics provider?) started using it.

HTTPArchive shows 42 hits, all of which are one of these three libraries (mostly the first two):

• Dexie.js - https://github.com/dfahlander/Dexie.js/search?utf8=%E2%9C%93&q=webkitgetdatabasenames
  
• AlaSQL - https://github.com/agershun/alasql/search?utf8=%E2%9C%93&q=webkitgetdatabasenames
  
• MEGA - https://github.com/meganz/webclient/search?utf8=%E2%9C%93&q=webkitgetdatabasenames
  

All three libraries have fallbacks in case the method is not present.

OWP launch tracking bug

Will file if approved.

Regular tracking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=696010

Entry on the feature dashboard

Will file if approved.

Requesting approval to remove too?

No; proposing that we land deprecation in 58 (if this gets LGTMs in time) and remove in 60.

We'd also file bugs against the three libraries indicating that a deprecation warning and eventual removal is planned.

Trivia:

This was the first new feature I implemented as a Chrome Noogler.

[Chris Harrelson]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Dimitri Glazkov]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[TAMURA, Kent]

LGTM3.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--

TAMURA Kent
Software Engineer, Google

[nvi...@gmail.com]

How to delete all indexedDBs related to a domain, but without knowing the names of databases? Chrome extensions use this function thousands times a day and you want to remove it. Why you follow the specification if it only bears harm? So what is real reason to remove that function? Please do not tell the community about the spec, because this sounds very stupid. Any alternative to get names and delete all databases for a domain?

[Reilly Grant]

Please keep this conversation respectful. There is no need to call people or ideas stupid or assume there is an unstated ulterior motive.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4a86c42d-4a78-49ed-8909-740eefa4aa6d%40chromium.org.

[blake.a....@gmail.com]

indexedDB is a potential vector for tracking. For example if a 3rd party iframe is loaded on a site, that 3rd party can write some unique value to indexedDB. The next time that 3rd party origin is loaded it can check the indexedDB for the value, and use it to uniquely identify the client. 

This situation necessitates a way for clients to inspect indexedDB on some origin for its database names so that privacy compromising information can be deleted.

[jac...@gmail.com]

Would you consider adding a method that allowed deleting of all databases (available to the origin) without enumerating them (and hence obtaining any useful information about them)? This would be extremely helpful for some test runner code that I'm working with, and I don't think it introduces any new privacy concerns. It also aids with the previously described case of "forgotten databases" (or, perhaps more realistically, "accidentally created databases) since it would all developers to write migration/upgrade code for their sites to "start fresh".

BTW, as a pathological example regarding privacy, what is to stop someone from tracking users by storing a very large amount of data so as to use the estimated storage usage as a sort of loosely unique identifier? e.g. storage usage is available via `navigator.storage.estimate().then(est => console.log(`${(est.usage*Math.pow(2,20)).toPrecision(3)}MiB used`))`, so one could set 20MiB for one user, 30 for another, etc. Since storage used legitimately may be sufficiently negligible it would be possible to differentiate clients based on what range their storage usage falls into.

[PhistucK]

A standard way to enumerate databases is in the works, so while you will lose webkitDatabaseNames, the functionality will be otherwise supported.

See the intent thread for details.

☆PhistucK

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e1eb824f-631b-44d5-bd02-178d5650af8d%40chromium.org.