Here's the demo: https://evanstade.github.io/web-storage-demos/idb-txn-scopes (it's also linked in the chromestatus.com entry)
Yes, when/if the feature is enabled for just incognito and not on-disk, it would create an incognito detector. However, we want to perform A/B measurements during rollout, so it's not a waterfall rollout, which means it's often not a perfect oracle. We can close this loophole, but not without drawbacks. We could impose the same behavior on the LevelDB backend in Chromium (for IDB in normal profiles). That would be technically easy to do, and could potentially flush out any breakages in Chromium-only sites before the full SQLite rollout. The problem is that it might have a negative perf impact for LevelDB. (We think that overall SQLite will be as fast or better than LevelDB, but this one detail can potentially reduce parallelization, so in isolation it is a detriment.) And this would impede our ability to fairly compare SQLite and LevelDB performance. Is the goal to eliminate incognito detection altogether (which seems a little bit on the restrictive side, since there are existing unpatched incognito signals), or just to deteriorate the quality of them, or just to make sure none of them become permanently baked into the platform? To deteriorate reliability of the incognito detection, we could: * hold back 50% of the incognito population indefinitely (which probably still gives us a chance to collect enough metrics/bug reports), or * impose the same transaction behavior on LevelDB some small percent of the time (to minimize perf impact, but make the detector flaky). The cost in both of these cases is the headache of non-determinism. ________________________________ From: Mike Taylor <[email protected]> Sent: Wednesday, December 10, 2025 6:23 AM To: [email protected] <[email protected]> Cc: [email protected] <[email protected]>; Abhishek Shanthkumar <[email protected]>; Evan Stade <[email protected]> Subject: [EXTERNAL] Re: [blink-dev] Web-Facing Change PSA: IndexedDB: SQLite backend (in-memory contexts) On 12/9/25 5:34 p.m., Chromestatus wrote: Contact emails [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> Specification https://www.w3.org/TR/IndexedDB Summary Chromium's IndexedDB implementation is rewritten on top of SQLite, to replace the previous implementation that uses a hybrid of LevelDB and flat files. There is no change to the Web API. This is expected to improve reliability and, to a lesser extent, performance. For now this is applied only to in-memory contexts such as Incognito mode in Chromium and Google Chrome. This limits the impact of any new bugs, as well as puts off the need to worry about migration of existing data persisted to disk. Blink component Blink>Storage>IndexedDB<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EStorage%3EIndexedDB%22> Web Feature ID indexeddb<https://webstatus.dev/features/indexeddb> Search tags [/features#tags:sqlite]sqlite, [/features#tags:idb]idb, [/features#tags:indexeddb]indexeddb, [/features#tags:leveldb]leveldb Risks Interoperability and Compatibility Interop: this work entails a web-visible behavioral change concerning an edge case in IDB transaction scheduling. This change brings Chromium in line with Firefox and Safari. (Both new and old behavior are standards-compliant.) See demo. Compatibility: This PSA exists primarily to warn of the risk of unintended breakage. The later step where persisted databases are stored with SQLite, and existing data is migrated to SQLite, will have higher associated risks and will have its own PSA. Is there a link to a demo? I wonder if this creates a new Incognito mode oracle. Gecko: No signal WebKit: No signal Web developers: No signals Other signals: Security All data on disk is still segregated by storage bucket (origin). Both new and old implementation are newly fuzz-tested. WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? No information provided Debuggability existing IndexedDB DevTools support is unimpacted Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? Yes https://wpt.fyi/results/IndexedDB Tracking bug https://issues.chromium.org/issues/436880911 Estimated milestones Shipping on desktop 144 DevTrial on desktop 144 Shipping on Android 144 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5126896685809664 This intent message was generated by Chrome Platform Status<https://chromestatus.com/>. -- 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 [email protected]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6938a409.710a0220.1d2509.0190.GAE%40google.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6938a409.710a0220.1d2509.0190.GAE%40google.com?utm_medium=email&utm_source=footer>. -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH0PR00MB10314C5B42189873AB9BA8EDBAA0A%40PH0PR00MB1031.namprd00.prod.outlook.com.
