1639542 - (idb-private-browsing) [meta] Support IndexedDB in Private Browsing Mode (with encrypted disk storage)

Status: RESOLVED FIXED

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

Comment 1

[Simon Giesecke [:sg] [he/him]]

Depends on Bug 1593365 for removing exposure of origin information in disk paths.

Comment 4

[Simon Giesecke [:sg] [he/him]]

Attachment: Bug 1639542 - Adapt browserchrome tests to support of IndexedDB in private browsing mode. r=#dom-workers-and-storage

Comment 5

[shivarajnaidu]

Any update or temporary fix available to workaround the issue ?

Comment 6

[shivarajnaidu]

I mean this error DOMException: A mutation operation was attempted on a database that did not allow mutations.

to handle it gracefully in private mode

Comment 7

[Phabricator Automation]

Comment on attachment 9181986 [details]
Bug 1639542 - Adapt browserchrome tests to support of IndexedDB in private browsing mode. r=#dom-workers-and-storage

Revision D93757 was moved to bug 1699055. Setting attachment 9181986 [details] to obsolete.

Comment 8

[Jeff Griffiths]

Is this bug still being worked on?

Currently Netlfix is still broken for playback, and on a much smaller scale things like https://drive.fission.codes will never work in a private window without this.

Comment 9

[Marti Raudsepp]

There's an about:config workaround by setting

dom.indexedDB.privateBrowsing.enabled to true

Of course this will forego the privacy guarantees of private browsing, but it's a tradeoff you can make.

Comment 10

[Pawel Mostek]

In my opinion the mechanism that grant access to the indexedDB in private mode should be very similar to the one grant access to microphone or camera.
Example scenario:

1. user visit website A (he can be in a private mode or in apublic mode)
2. website A request to "access indexedDB in provate mode" (eg. via dedicated API)
3. user can see a popup and can make decision if he wants to grant permission (decision is permament - if user say yes, he do not have to confirm it again)

If user grant permission to "access indexedDB in private mode", then website "A" can store all data in the browser. If user does not grant access then webside "A" can make decision to store all data on the server.

With this approche it's very clear for the user and for the developer how to handle data storage.

Comment 14

[David Mediavilla]

Maybe you could make it work like cookies: keep the storage content during the session and delete it at the end of the session.

Comment 15

[Jan Varga [:janv]]

https://twitter.com/cedric_infosec/status/1658455734349070338

IndexedDB in private browsing works in FF 115 beta and if everything goes well it will be available in FF 115 release.

Comment 16

[Maxime RETY]

First of all, I can only express my greatest relief and gratitude at seeing this problem corrected, 11 years after I first encountered bug #781982.

So thanks again to everyone who made this possible.

Second, I have two questions:

1. Is it expected that created indexedDBs do not appear in developer tools (Storage > Indexed DB) in private browsing mode? As a comparison, it is possible to inspect Local Storage in private browsing mode, so there would be a difference in behavior.

2. The correction of this issue is not (yet) mentioned in upcoming release notes (Firefox Beta 115, Firefox 115 for developers
   ). Wouldn't it be relevant to communicate on the subject?

Comment 17

[Jan Varga [:janv]]

(In reply to Maxime RETY from comment #16)

1. Is it expected that created indexedDBs do not appear in developer tools (Storage > Indexed DB) in private browsing mode? As a comparison, it is possible to inspect Local Storage in private browsing mode, so there would be a difference in behavior.

Yeah, that doesn't work yet. There are some complications specific to the way how IndexedDB stores data in private browsing mode.

2. The correction of this issue is not (yet) mentioned in upcoming release notes (Firefox Beta 115, Firefox 115 for developers
   ). Wouldn't it be relevant to communicate on the subject?

I'm sure it will be added to release notes soon.

Comment 18

[Maxime RETY]

Understood, thans Jan for your feedback.

Comment 19

[Jimmy Warting]

I can't wait to see those utterly bad sites who dose private mode detection with IDB on visitor to limit the sites availability go away!

Comment 20

[Jens Stutte [:jstutte]]

The remaining defects this depends on look a bit like regressions rather than blocking bugs ? Should we close this and unlink and mark them accordingly ?

Comment 21

[hankamolpol]

So, was this ever fixed? I came here after realizing that addons that rely on IndexedDB don't work in tor (but do without private mode), and was wondering if I should ask in tor or firefox. Currently tor is using firefox 115.7.0esr.

Comment 22

[Harveer Singh]

All the gating bugs for this meta bug has been closed already. Hence, closing this meta bug.