[tor-bugs] #26847 [Applications/Tor Browser]: Tor Browser 8.0, noscript pops up a full-browser-size window to warn me about x-site scripting

[Tor Bug Tracker & Wiki]

#26847: Tor Browser 8.0, noscript pops up a full-browser-size window to warn me
about x-site scripting
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-8.0-issues, tbb-regression,      |  Actual Points:
  noscript, tbb-usability                        |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by ma1):

 Replying to [comment:7 mikeperry]:
 > Hrmm, this situation does not seem to have improved. Doubleclick is
 encoding URLs in like all of its ad query params (probably because of the
 referer field not being present for https fetches), and this is getting
 triggered multiple times all over the place.

 Could you please provide me with some URLs to test for false positives?
 I'd very much want to remove them, but  unfortuntaley, "regular" NoScript
 users (not on the Tor Browser at Medium security settings) are unlikely to
 see and report those because doubleclick is blocked by default (pre-XSS
 filter) and/or adblocked. Is there any reason for the Tor Browser not
 blocking the major tracking / advertising offenders across all its user
 base?

 Beside tackling false positives, a strategy I'm willing to experiment with
 is replacing XSS warning popups with something less obtrusive and
 workflow-interrupting: **what about an in-content placeholder, very much
 like the click-to-play one**?

 Regarding the performance issues, I've already made the filter
 asynchronous in the WebExtensions process, which shouldn't block the UI
 and content processes but unfortunately doesn't help much with mono-core
 processors (poor Intel Atom). I'm not sure WebAssembly would be useful
 either, since most of the CPU time is spent on regular expressions
 matching, but having real-world cases reported would help optimizing
 possibly inefficient ones.

 Thank you all for the cooperation.

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