[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