[tor-bugs] #26520 [Applications/Tor Browser]: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Aug 28 18:35:58 UTC 2018


#26520: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:
                                                 |  pospeselr
     Type:  defect                               |         Status:  new
 Priority:  High                                 |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  ff60-esr, TorBrowserTeam201808,      |  Actual Points:
  noscript                                       |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by rustybird):

 Replying to [comment:39 ma1]:
 > Well, IMHO the most reliable way to do it, no matter how long
 initialization takes on both sides, could be this:
 >
 > 1) NoScript needs a way to know very early (at the beginning of its
 execution) that it's running in the Tor Browser.
 > Ideally, the [https://developer.mozilla.org/en-US/docs/Mozilla/Add-
 ons/WebExtensions/API/runtime/getBrowserInfo
 browser.runtime.getBrowserInfo()] API should return something unique, like
 {name: "Tor Browser", vendor: "The Tor Project"} (not sure if this
 requires a patch to the WebExtensions API or just setting some
 preference).
 >
 > 2) If it knows it's hosted by TB, NoScript will run its initialization
 code, including the part where it defers all the content network activity
 until ready, but won't unblock  until a specific "updateSettings" message
 is received from the Tor Browser.

 I don't understand the Firefox/Torbutton/NoScript innards enough to say if
 that's the way to go, though it sounds like the most solid solution.
 Hopefully someone will weigh in. But with the Tor Browser 8.0 final
 release just around the corner, fingers crossed that the interim solution
 can hold the line. :)

 > Anyway, if all the Tor Button initialization happens synchronously in a
 [https://developer.mozilla.org/en-
 US/docs/Mozilla/Tech/XPCOM/Guide/Receiving_startup_notifications profile-
 after-change observer], like it was usually done in XUL extensions, it
 will definitely finish before NoScript starts.
 >
 > Therefore, if this is the case, NoScript waiting for the "start" message
 to be answered (like in the original patch) should suffice, provided that
 this happens **before** we resolve the init() promise and give the green
 light to ''deferWebTraffic'': hence my just released
 [https://github.com/hackademix/noscript/releases/tag/10.1.9rc3 10.1.9rc3]
 which reorders NoScript's startup sequence to guarantee this. Please test
 it.

 Tor Browser 8.0a10 + NoScript 10.1.9.rc3 + the Torbutton .xpi from gk's
 comment:36 seem to work well in my Fedora 28 test VM. Thank you! Might be
 worth testing in Tails again too, given the previous weird timing
 differences.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26520#comment:40>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list