[tbb-bugs] #27427 [Applications/Tor Browser]: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Sep 15 04:58:00 UTC 2018


#27427: [PATCH] Fix NoScript IPC for about:blank by whitelisting messages
-------------------------------------------------+-------------------------
 Reporter:  rustybird                            |          Owner:
                                                 |  arthuredelstein
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Very High                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  TorBrowserTeam201809R,               |  Actual Points:
  tbb-8.0.1-can                                  |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by cypherpunks3):

 Replying to [comment:18 ma1]:
 > I think you're wrong, indeed. The message handler gets enabled only
 after initialization is completed.
 Yep, I saw that. I conflated evidence of the message with evidence of the
 handling.
 > That approach is reliable, except on the very first load of a local
 (bypassing webRequest) page. I.e. if you set a file:, data: or about: URL
 as your home page (or, regrettably, if you're using session restore and
 that's the last active tab) NoScript won't be able to affect it on first
 load.
 Thanks for the explanation. This seems reasonable to me (but probably it
 should be documented).
 > A work-around would be detecting some in the static content scripts
 (which appear to run anyway) that the dynamic content scripts didn't (i.e.
 NoScript's background script has not been initialized yet), stopping the
 load and triggering a (delayed?) reload. Maybe this could be helped by
 waiting for a response to a dummy HTTP fetch() request, relying on the web
 traffic deferral, in order to prevent reload loops in case something
 fails.
 I don't understand it well, but it seems convoluted. Porbably webext
 should grow explicit API to cover these cases.

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


More information about the tbb-bugs mailing list