Opened 3 weeks ago

Closed 2 weeks ago

Last modified 2 weeks ago

#27411 closed defect (fixed)

Security slider is broken in second RC for Tor Browser 8 on Windows

Reported by: gk Owned by: tbb-team
Priority: Immediate Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201809R
Cc: arthuredelstein, mcs, brade, boklm, ma1 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

In #27401 we fixed JavaScript being disabled in start-up and (I believe) the security slider not working.

However, testing with the second release candidate for Tor Browser 8 (https://people.torproject.org/~gk/builds/8.0-build4/) shows that this is (still) broken on Windows while at least on Linux it is working. On Windows both 32bit and 64bit bundles disabled JavaScript and the security slider is essentially not working.

Child Tickets

Change History (15)

comment:1 Changed 3 weeks ago by gk

Cc: ma1 added

In #27401 we moved adding the message listener to an earlier point during start-up as NoScript seemed to send its "startup" message before the listener got added. We chose the startup-observer and added the message listener essentially after receiving the profile-after-change notification. That fixed the problem on Linux and I think on macOS as well. However, on Windows we still hit this.

I see a message in the console indicating that the listener got set up. But we never reveice a message from NoScript. It seems we can't start the message handler much earlier, so I wonder what else we could do. Adding Giorgio, maybe he has some ideas.

comment:2 Changed 3 weeks ago by gk

Okay, I added the message listener earlier, into the constructor of one of our components. While the message listener is indeed called even earlier, that does not help for the Windows bundles. We still don't get a message from NoScript.

Last edited 3 weeks ago by gk (previous) (diff)

comment:3 Changed 3 weeks ago by gk

Looking closer at the log in the browser console I see the warnings related to web extensions loading indeed show up way later than all the XPCOM initialization foo as Giorgio indicates in

Anyway, if all the Tor Button initialization happens synchronously in a ​profile-after-change observer, like it was usually done in XUL extensions, it will definitely finish before NoScript starts.

(comment:39:ticket:26520).

So, I wonder whether something else breaks here on Windows.

comment:4 in reply to:  3 ; Changed 3 weeks ago by ma1

Replying to gk:

So, I wonder whether something else breaks here on Windows.

I'm almost sure that the problem on Windows (which is gonna be a problem on Linux and Mac OS X in next ESR, but not yet), is that WebExtension's background pages on that platform already run in a separate process from the main browser on Firefox 60, while this feature is enabled on Mac OS X in 61 and on Linux in 63.

Therefore, even if you add the listener in profile-after-change (the correct and earliest place to do it), on Windows there's anyway an unpredictable latency due to IPC.

Anticipating the registration in a component costructor won't help, because it's too early to do anything meaningful with a specific extension, since we're not aware yet of the profile in use and therefore of the installed extensions.

IMHO the only way to be sure we manage to get in sync is NoScript knowing from the start that it's running in the Tor Browser (I suggested by customizing the browser.runtime.getBrowserInfo() API to return something meaningful, but maybe there's an easier way) and, if that's the case, either repeating the "start" message every 100ms until it gets acknowledged or waiting for an "updateSettings" message to arrive.

comment:5 in reply to:  4 ; Changed 3 weeks ago by gk

Replying to ma1:

Replying to gk:

So, I wonder whether something else breaks here on Windows.

I'm almost sure that the problem on Windows (which is gonna be a problem on Linux and Mac OS X in next ESR, but not yet), is that WebExtension's background pages on that platform already run in a separate process from the main browser on Firefox 60, while this feature is enabled on Mac OS X in 61 and on Linux in 63.

Therefore, even if you add the listener in profile-after-change (the correct and earliest place to do it), on Windows there's anyway an unpredictable latency due to IPC.

Anticipating the registration in a component costructor won't help, because it's too early to do anything meaningful with a specific extension, since we're not aware yet of the profile in use and therefore of the installed extensions.

IMHO the only way to be sure we manage to get in sync is NoScript knowing from the start that it's running in the Tor Browser (I suggested by customizing the browser.runtime.getBrowserInfo() API to return something meaningful, but maybe there's an easier way) and, if that's the case, either repeating the "start" message every 100ms until it gets acknowledged or waiting for an "updateSettings" message to arrive.

Thanks for the explanation which makes sense to me. I agree we should develop an even more robust means of Tor Browser <-> NoScript communication. I fear this takes too long, though, to unblock our pending release. I wonder whether we can just disable that background scripts being in an own process on Windows for now... Is there a pref we can flip? Or potentially we can patch the source to do that, too...

comment:6 Changed 3 weeks ago by cypherpunks3

Is there a pref we can flip?

Fortunately yes: extensions.webextensions.remote :) https://bugzilla.mozilla.org/show_bug.cgi?id=1357486

nb: fix the privacy regression that is the UA pleeeeease

comment:7 Changed 3 weeks ago by gk

extensions.webextensions.remote is what we want to flip it seems. This "solves" our problem at least.

comment:8 in reply to:  6 ; Changed 2 weeks ago by ma1

Replying to cypherpunks3:

Is there a pref we can flip?

Fortunately yes: extensions.webextensions.remote :) https://bugzilla.mozilla.org/show_bug.cgi?id=1357486

Yep, sorry not having been fast enough to tell you :)

nb: fix the privacy regression that is the UA pleeeeease

Is this for me? Am I missing something?

comment:9 in reply to:  8 Changed 2 weeks ago by cypherpunks3

Replying to ma1:

Is this for me? Am I missing something?

No, it's for the tb devs, sorry for the confusion.

comment:10 in reply to:  5 ; Changed 2 weeks ago by arthuredelstein

Replying to ma1:

IMHO the only way to be sure we manage to get in sync is NoScript knowing from the start that it's running in the Tor Browser (I suggested by customizing the browser.runtime.getBrowserInfo() API to return something meaningful, but maybe there's an easier way) and, if that's the case, either repeating the "start" message every 100ms until it gets acknowledged or waiting for an "updateSettings" message to arrive.

Something that now occurrs to me, which doesn't require any further patching of NoScript, is for torbutton to keep sending its first updateSettings message (say every 100 ms) until NoScript responds.

comment:11 Changed 2 weeks ago by gk

Resolution: fixed
Status: newclosed

I pushed a commit to tor-browser-60.2.0esr-8.0-1 (commit 124fa904c4b2b24b86429ebc3448cd9114d5e4dc) that essentially sets extensions.webextensions.remote to false on all platforms to get the rebuild starting.

I opened #27413 for a better protocol.

comment:12 in reply to:  10 ; Changed 2 weeks ago by rustybird

Replying to arthuredelstein:

Replying to ma1:

IMHO the only way to be sure we manage to get in sync is NoScript knowing from the start that it's running in the Tor Browser (I suggested by customizing the browser.runtime.getBrowserInfo() API to return something meaningful, but maybe there's an easier way) and, if that's the case, either repeating the "start" message every 100ms until it gets acknowledged or waiting for an "updateSettings" message to arrive.

Something that now occurrs to me, which doesn't require any further patching of NoScript, is for torbutton to keep sending its first updateSettings message (say every 100 ms) until NoScript responds.

But without a further, Tor Browser specific patch for NoScript (to delay page loads until the updateSettings message has arrived), the first page load could still happen with the wrong settings.

comment:13 in reply to:  12 ; Changed 2 weeks ago by arthuredelstein

Replying to rustybird:

But without a further, Tor Browser specific patch for NoScript (to delay page loads until the updateSettings message has arrived), the first page load could still happen with the wrong settings.

That's an interesting point. But if NoScript is not ready when the first page load has happened, then doesn't that mean its settings won't be applied to that page anyway?

Edit: On further thought, I guess it is possible that when NoScript sends its "started" message, then reply will be too slow to catch it before NoScript's pre-adjusted settings are applied to the first page.

Last edited 2 weeks ago by arthuredelstein (previous) (diff)

comment:14 in reply to:  13 Changed 2 weeks ago by ma1

Replying to arthuredelstein:

Replying to rustybird:

But without a further, Tor Browser specific patch for NoScript (to delay page loads until the updateSettings message has arrived), the first page load could still happen with the wrong settings.

That's an interesting point. But if NoScript is not ready when the first page load has happened, then doesn't that mean its settings won't be applied to that page anyway?

First thing NoScript does, before any asynchronous initialization and hopefully before any page load (at least it seems to be working reliably even with session restore pages) is suspending any web loading activity until it's actually ready to enforce policies.

Edit: On further thought, I guess it is possible that when NoScript sends its "started" message, then reply will be too slow to catch it before NoScript's pre-adjusted settings are applied to the first page.

That should not be the case, because NoScript waits for the response before resuming web loading activity.

comment:15 Changed 2 weeks ago by gk

Keywords: TorBrowserTeam201809R added; TorBrowserTam201809 removed
Note: See TracTickets for help on using tickets.