Disable NoScript's XSS protection to avoid the whole computer freezing
We've had it numerous times now (see e.g. #25315 (moved), #24125 (moved), #22362 (moved)) that Tor Browser freezes the whole computer due to NoScript's XSS protection. This is currently visible on https://zeit.de again cause by an embedded https://facebook.com/tr.
I'd finally like to stop playing this whack-a-mole game and come to a better solution. Meanwhile, we can stop enabling XSS protection given that those experiences seriously risk users abandoning Tor Browser, claiming it is broken, and moving on to a much worse solution for their privacy requirements.
Activity
I doubt it's the same defect, or even similar, as the implementation of the filter has radically changed with WebExtensions, and now it runs asynchronously in its own process and shouldn't be able to block the browser, let alone the whole computer. Could you please provide me steps to reproduce reliably? Is it Tor Browser specific or does it affect Firefox too. Might it be related to the pseudo-modal warning dialog (which must go away anyway anyway, with the UI redesign), rather than the filter itself? Thanks.
-
NVM, I managed to reproduce. It freezes the browser for a few seconds on 8.5 (where browser.webextensions.remote is false) while the firefox.real process gets 100% CPU. What's more annoying, it appears to affect more than just the browser on my Ubuntu box if I turn extensions.webextensions.remote to true, which is counterintuitive (the extension should be doing its thing in its own process while the facebook HTTP subrequest is suspended) but might be due to some kind of IPC bug: this time nothing really freezes, but again for a few seconds other application become sluggish as well while a WebExtensions process takes 100% CPU. Do Tor Browser 9.0 have extensions.webextensions.remote set to false or true? Either way, since it's already executed asyncronously, I wanna try breaking the main InjectionChecker loop into time-capped chunks (e.g. 100ms max) which would relinquish the CPU back periodically while checking very costly payloads like this, and possibly (but it might not be necessary) move the whole in a dedicated worker.
ma1, if you just try to search the correct pref, you can get what you want: https://trac.torproject.org/projects/tor/search?q=extensions.webextensions.remote
Also see #29043 (moved).
-
Replying to cypherpunks:
ma1, if you just try to search the correct pref, you can get what you want: https://trac.torproject.org/projects/tor/search?q=extensions.webextensions.remote
No, the info was not there. However I've installed 9.0a1, and extensions.webextensions.remote is still false like in 8.5. The proposed fix should work either way, though.
Replying to ma1:
Replying to cypherpunks:
ma1, if you just try to search the correct pref, you can get what you want: https://trac.torproject.org/projects/tor/search?q=extensions.webextensions.remote
No, the info was not there. Oh, you mean the absence of other tickets is not the obvious proof for you. Then only https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/firefox.js?h=tor-browser-60.7.0esr-9.0-1#n78 However I've installed 9.0a1, o_0 Hey folks! Maone installed TB! and extensions.webextensions.remote is still false like in 8.5. Trust no one. The proposed fix should work either way, though. Did you test that in TB?
-
Replying to cypherpunks:
The proposed fix should work either way, though. Did you test that in TB?
No I couldn't, I'm sorry: I was paralyzed in awe of the grace and the usefulness of your comments. Not nearly as useful, and maybe exceedingly mundane, but would you by chance have also any patch (or idea for a fix) to contribute? Thanks.
-
Please check https://github.com/hackademix/noscript/releases/tag/10.6.3rc3
This should prevent any freeze, even on the heaviest payload. Tested on 8.5 and 9.0a1.
Replying to ma1:
Please check https://github.com/hackademix/noscript/releases/tag/10.6.3rc3
This should prevent any freeze, even on the heaviest payload. Tested on 8.5 and 9.0a1.
Not for me. While I can't reproduce on https://zeit.de anymore https://www.sravni.ru/kredity/na-1000000-rublej/ still freezes my browser (or makes it extremely sluggish) with 10.6.3rc3 (that's 9.0a1). Disabling NoScript's XSS feature gets back a smooth experience.
-
Replying to cypherpunks:
Replying to ma1:
Replying to cypherpunks:
ma1, if you just try to search the correct pref, you can get what you want: https://trac.torproject.org/projects/tor/search?q=extensions.webextensions.remote
No, the info was not there. Oh, you mean the absence of other tickets is not the obvious proof for you. Then only https://gitweb.torproject.org/tor-browser.git/tree/browser/app/profile/firefox.js?h=tor-browser-60.7.0esr-9.0-1#n78 However I've installed 9.0a1, o_0 Hey folks! Maone installed TB! and extensions.webextensions.remote is still false like in 8.5. Trust no one. The proposed fix should work either way, though. Did you test that in TB?
Please keep the tone civilized. It's quite embarrassing to see someone being so rude. That's not welcome here.
-
Replying to gk:
. While I can't reproduce on https://zeit.de anymore https://www.sravni.ru/kredity/na-1000000-rublej/ still freezes my browser (or makes it extremely sluggish) with 10.6.3rc3 (that's 9.0a1). Disabling NoScript's XSS feature gets back a smooth experience.
Sadly, it looks like my first asynchronous work around attempt is not doing as good as it could, because apparently the resistFingerprinting clamping of Date.now() affects not just web content but WebExtensions too, causing the CPU to be relinquished every 100ms (which is the artificially imposed resolution), rather than 10ms as intended, therefore making long-running checks 10 times more sluggish than they should :(
Trying something else, stay tuned...
-
Replying to ma1:
Replying to gk:
. While I can't reproduce on https://zeit.de anymore https://www.sravni.ru/kredity/na-1000000-rublej/ still freezes my browser (or makes it extremely sluggish) with 10.6.3rc3 (that's 9.0a1). Trying something else, stay tuned...
Please check https://github.com/hackademix/noscript/releases/tag/10.6.3rc4 Thanks!
-
Replying to ma1:
Replying to gk:
. While I can't reproduce on https://zeit.de anymore https://www.sravni.ru/kredity/na-1000000-rublej/ still freezes my browser (or makes it extremely sluggish) with 10.6.3rc3 (that's 9.0a1). Disabling NoScript's XSS feature gets back a smooth experience.
Sadly, it looks like my first asynchronous work around attempt is not doing as good as it could, because apparently the resistFingerprinting clamping of Date.now() affects not just web content but WebExtensions too,
That's a bug I think. I opened #30655 (moved) for that.
-
Replying to ma1:
Replying to ma1:
Replying to gk:
. While I can't reproduce on https://zeit.de anymore https://www.sravni.ru/kredity/na-1000000-rublej/ still freezes my browser (or makes it extremely sluggish) with 10.6.3rc3 (that's 9.0a1). Trying something else, stay tuned...
Please check https://github.com/hackademix/noscript/releases/tag/10.6.3rc4
That seems to work for me, thanks!
-
#30754 (moved) is a duplicate.
Trac:
Cc: ma1 to ma1, acat Replying to ma1:
Sadly, it looks like my first asynchronous work around attempt is not doing as good as it could, because apparently the resistFingerprinting clamping of Date.now() affects not just web content but WebExtensions too, causing the CPU to be relinquished every 100ms (which is the artificially imposed resolution), rather than 10ms as intended, therefore making long-running checks 10 times more sluggish than they should :( @gk: You should probably raise this with Mozilla, WebExt have now their own process in moz-central so it should theoretically be easy to let resistFingerprinting conquer almost everything except the WebExt process.
mentioned in issue #30754 (moved)
mentioned in issue tpo/applications/tor-browser#30754 (closed)