[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #27411 [Applications/Tor Browser]: Security slider is broken in second RC for Tor Browser 8 on Windows
#27411: Security slider is broken in second RC for Tor Browser 8 on Windows
--------------------------------------+--------------------------
Reporter: gk | Owner: tbb-team
Type: defect | Status: new
Priority: Immediate | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: TorBrowserTam201809 | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
--------------------------------------+--------------------------
Comment (by gk):
Replying to [comment:4 ma1]:
> Replying to [comment:3 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 [https://dxr.mozilla.org/mozilla-
central/rev/c2e3be6a1dd352b969a45f0b85e87674e24ad284/toolkit/components/extensions/parent
/ext-runtime.js#117 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...
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27411#comment:5>
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