Using the Linux 64-bit Tor Browser, or the Tor Browser in Tails 3.0, 3.1 or 3.2, I log in to Google mail. After logged in I go to drive.google.com. The Google Drive page starts to render, then I get the message
Gah. Your tab just crashed. We can help you!
Choose Restore This Tab to reload page content.
Trac: Username: angelotheram2
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
Is that reproducible? Does it go away if you set browser.tabs.remote.autostart.2 to false in your about:config and try again after restart? Does it happen with a vanilla Firefox 52 ESR as well? (see https://www.mozilla.org/en-US/firefox/organizations/all/ for a download option)
Trac: Status: new to needs_information Milestone: Tor: unspecified toN/A Priority: Medium to High Keywords: Tor Browser deleted, tbb-crash added Severity: Normal to Major
Is that reproducible? Does it go away if you set browser.tabs.remote.autostart.2 to false in your about:config and try again after restart? Does it happen with a vanilla Firefox 52 ESR as well? (see https://www.mozilla.org/en-US/firefox/organizations/all/ for a download option)
Without e10s the crash does not happen and Firefox is not affected. mcs, brade, arthur: Can anybody of you take a look at that and figure out what is going on?
Trac: Cc: N/Ato mcs, brade, arthuredelstein Status: needs_information to assigned
It does go away when I set browser.tabs.remote.autostart.2 to false and restart the browser.
I then set browser.tabs.remote.autostart.2 to back to true and the problem returns.
This setting is a clue and a workaround, thanks.
I also confirmed that if I set "dom.indexedDB.enabled" to true, the browser no longer crashes. (Flipping this pref is not recommended for users, because of privacy/tracking implications. I mention it only for debugging purposes.)
gk observed that the crash is being caused by a block of code in ActorsParent.cpp:
if (principalInfo.type() != PrincipalInfo::TSystemPrincipalInfo && NS_WARN_IF(!Preferences::GetBool(kPrefIndexedDBEnabled, false))) { if (aContentParent) { // The DOM in the other process should have kept us from receiving any // indexedDB messages so assume that the child is misbehaving. aContentParent->KillHard("IndexedDB CheckPermission 1"); } return NS_ERROR_DOM_INDEXEDDB_NOT_ALLOWED_ERR;}
But this does not happen if "dom.indexedDB.enabled" is true. I have yet to investigate why.
In the meantime, I am trying to work out what our strategy should be for indexedDB. Update: I have learned two of the following items are no longer true:
indexedDB is a supercookie vector and has not yet been patched to respect first-party isolation in Tor Browser or Firefox.'(Actually patched as early as ESR52.)
There is a Mozilla ticket for enabling a memory-only indexeddb in Firefox but this has not been resolved. In other words, indexeddb always writes to disk.
As mikperry pointed out, there wasn't a good way to programmatically clear indexedDB databases. That issue may have been recently fixed in Firefox and we should investigate if we can use this in New Identity. (In fact, torbutton already apparently clears indexedDBs.)
In PBM, indexedDB is already effectively disabled, even when "dom.indexedDB.enabled" is true.
There was a concern that some users might disable PBM and then New Identity would fail to wipe indexedDB. Do we actually want to claim to protect users who turn off PBM? That seems possibly out of scope to me. If that's the case, it seems to me we can rely on indexedDB being disabled in PBM by Firefox's built-in mechanism and drop the legacy/trac#21308 (moved) patch?
But if we want to protect non-PBM users, then we should investigate whether New Identity can clear indexedDB (legacy/trac#23768 (moved)). That ticket would be useful in the future if we wanted to enable indexedDB in PBM as well.
If instead we want to ensure we have disabled indexedDB in non-PBM windows as well, then I would suggest writing a new patch that simply stops exposing indexedDB to content by modifying dom/webidl/WindowOrWorkGlobalScope.webidl, so indexedDB is not exposed when the pref "dom.indexedDB.enabled" is false.
There was a concern that some users might disable PBM and then New Identity would fail to wipe indexedDB. Do we actually want to claim to protect users who turn off PBM? That seems possibly out of scope to me. If that's the case, it seems to me we can rely on indexedDB being disabled in PBM by Firefox's built-in mechanism and drop the legacy/trac#21308 (moved) patch?
The point is that New Identity is not bound to PBM. In other words: we don't have a menu item saying "New Identity (if you are in Private Browsing Mode)" but rather "New Identity". It is supposed to (or I bet at least perceived as) give/giving you a New Identity no matter what. And I think that is good. Getting a clean slate should not depend on whether you are in PBM or are allowing disk records for some reason.
indexedDB is a supercookie vector and has not yet been patched to respect first-party isolation in Tor Browser or Firefox.
As mikperry pointed out, there wasn't a good way to programmatically clear indexedDB databases. That issue may have been recently fixed in Firefox and we should investigate if we can use this in New Identity.
I was behind the curve and learned in fact both these problems have already been solved:
New Identity does appear to wipe indexedDB.
indexedDB is first-party isolated in ESR52 (and TBB/ESR52).
To confirm these two assertions, I did the following experiment:
I set "browser.privatebrowsing.autostart" to false and "dom.indexedDB.enabled" to true in Tor Browser 7.0.6.
I opened a New non-PB window and visited https://codepen.io/caraya/pen/xVrXrG which allows one to make entries in an indexedDB database. I manually entered 3 entries.
I saw in tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/storage/default that there was a directory called https+++s.codepen.io^firstPartyDomain=codepen.io/.
I restarted Tor Browser, visited the site again and confirmed that my database entries were still present.
I clicked "New Identity", visited site once more and saw the the database was now reported empty.
I noted that tor-browser_en-US/Browser/TorBrowser/Data/Browser/profile.default/storage/ had been deleted, including its subdirectories default/https+++s.codepen.io^firstPartyDomain=codepen.io/
So to me it looks like FPI and clearing on New Identity mean that non-PBM indexedDB functionality is already the way we want it in Tor Browser, even when dom.indexedDB.enabled = true. And of course PBM windows already disabled indexedDB. So I'm inclined to do a little more testing to confirm FPI of indexedDB. If nothing bad is found, I would suggest we simply revert our legacy/trac#21308 (moved) patch, flip the "dom.indexedDB.enabled" pref to true and call that a fix for this ticket. gk, what do you think?
So to me it looks like FPI and clearing on New Identity mean that non-PBM indexedDB functionality is already the way we want it in Tor Browser, even when dom.indexedDB.enabled = true. And of course PBM windows already disabled indexedDB. So I'm inclined to do a little more testing to confirm FPI of indexedDB. If nothing bad is found, I would suggest we simply revert our legacy/trac#21308 (moved) patch, flip the "dom.indexedDB.enabled" pref to true and call that a fix for this ticket. gk, what do you think?
Sounds like a plan. Thanks for digging up all that useful info.
Another thought I had: it might be a good idea to take the old Tor Browser version Mike used back then for testing where he realized that IndexedDB related data is not getting deleted on New Identity. Just to be sure we are testing the same thing and it is indeed fixed now but not in the old Tor Browser.
Another thought I had: it might be a good idea to take the old Tor Browser version Mike used back then for testing where he realized that IndexedDB related data is not getting deleted on New Identity. Just to be sure we are testing the same thing and it is indeed fixed now but not in the old Tor Browser.
Although I could see evidence of FPI in comment:8, I haven't directly observed it. I will write code to test that tomorrow. I'm pretty confident FPI is happening, though, given the filenames I observed and also by confirmation from Mozilla folks, so if there isn't time to wait for that test, I would suggest trying it in the alpha anyway.
Looks good to me. Applied to tor-browser-52.4.0esr-7.5-1 (commits 03d6c603 and b4fc15a8).
The patches are straight forward so I applied them as well to tor-browser-52.4.0esr-7.0-1 to get the crash fixed in 7.0.7 as well (commits d3222cf5 and 00c8f9b8).
Please test the FPI, though. We might have time to revert things in the unlikely case FPI is broken. Leaving the ticket open for that part.
All,
I just downloaded and ran Tails 3.3, with Tor Browser 7.0.10, and Google Drive is now working for me without any about:config changes in Firefox. Thank you for the fix.