[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #26520 [Applications/Tor Browser]: NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs