[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #23745 [Applications/Tor Browser]: Tab crashes when using Tor Browser to access Google Drive
#23745: Tab crashes when using Tor Browser to access Google Drive
-------------------------------------------------+-------------------------
Reporter: angelotheram2 | Owner: tbb-
| team
Type: defect | Status:
| assigned
Priority: High | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Major | Resolution:
Keywords: tbb-crash, tbb-7.0-issues, tbb- | Actual Points:
regression, tbb-e10s, TorBrowserTeam201710 |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by arthuredelstein):
Replying to [comment:6 gk]:
> 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.
OK, I'm persuaded it's a good idea. Thanks!
Replying to [comment:5 arthuredelstein]:
> * indexedDB is a supercookie vector and has not yet been patched to
respect first-party isolation in Tor Browser or Firefox.
> * As [https://trac.torproject.org/projects/tor/ticket/16528#comment:7
mikperry pointed out], there wasn't a good way to programmatically clear
indexedDB databases. That issue may have been recently fixed in
[https://bugzilla.mozilla.org/show_bug.cgi?id=1047098 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:
1. I set "browser.privatebrowsing.autostart" to false and
"dom.indexedDB.enabled" to true in Tor Browser 7.0.6.
2. 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.
3. 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/`.
4. I restarted Tor Browser, visited the site again and confirmed that my
database entries were still present.
5. I clicked "New Identity", visited site once more and saw the the
database was now reported empty.
6. 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/`
FPI of indexedDB was also
[https://bugzilla.mozilla.org/show_bug.cgi?id=1405884 confirmed to me by a
few Mozillians]. And I noticed that code in torbutton here:
https://gitweb.torproject.org/torbutton.git/tree/src/chrome/content/torbutton.js?id=b3ff9863db338b2bd612f109e8bbce4c4af7cbd0#n348
is likely where the indexedDB wiping is happening. (It might be good to
update that code to better resemble this Mozilla patch here:
https://hg.mozilla.org/mozilla-central/rev/0fbe00ad0203#l1.42
because it doesn't require turning on the "dom.quotaManager.testing" pref;
I will make a note in #23768.)
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 #21308 patch, flip the "dom.indexedDB.enabled" pref to true and
call that a fix for this ticket. gk, what do you think?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23745#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs