[tor-bugs] #19210 [Applications/Tor Browser]: NoScript places WebM videos too late behind click-to-play in higher security levels

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Nov 22 17:43:22 UTC 2016


#19210: NoScript places WebM videos too late behind click-to-play in higher
security levels
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:
                                                 |  needs_information
 Priority:  High                                 |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Major                                |     Resolution:
 Keywords:  tbb-regression, tbb-security-        |  Actual Points:
  slider, tbb-6.0-issues, noscript               |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by ma1):

 Replying to [comment:14 i139]:

 > the holder still too behind

 How did you decide that?

 This is what NoScript 2.9.5.x is doing for top-level documents (the
 scenario you are presumably testing):
 1. As soon as the HTTP headers are available (well before the stream
 starts to be parsed), it checks for any content-type matching
 {{{/^(?:video|audio|application)\//}}}
 2. If the load matches, NoScript suspend the networking channel (no bytes
 are parsed anymore until resumed)
 3. At this point, based on the content type, Firefox creates the relevant
 media document (i.e. a document containing a full-page HTML 5 media
 element, either `<video>` or `<audio>`
 4. As soon as the page is created, NoScript enforces the current
 permissions and, if needed to honor them, aborts the channel (it could not
 be done earlier because otherwise there would be no container for the
 placeholder). Immediately after that it creates the placeholder which
 replaces the media element.

 Therefore you may indeed notice a little delay (the default player appears
 briefly, immediately replaced by the placeholder), but no (potentially
 harmful) stream reaches the (potentially exploitable) decoder.

 Are you noticing anything different? If so, how I can reproduce and verify
 what you're observing?

 Thanks!

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


More information about the tor-bugs mailing list