NoScript places WebM videos too late behind click-to-play in higher security levels
If setting the security slider to medium-low or a higher level WebM videos start to play but are stopped shortly thereafter by NoScript's click-to-play feature. Expected is that they don't start playing at all until the user has confirmed that. Reported in our blog: https://blog.torproject.org/blog/tor-browser-60-released#comment-183099.
As an example test with: http://ftp.acc.umu.se/pub/debian-meetings/2016/mini-debconf-vienna/webm/Debian_Installer_for_Novena.webm the video starts and a short time later NoScript kicks in.
https://blog.torproject.org/blog/tor-browser-60-released#comment-183106 suggests that this happened in earlier versions, too, although rarely.
Activity
Upon further inspection I realized click-to-play is partially working; When requested directly, audio and video resources make a get request for every 5 seconds of media. The first segment loads fine, the second is then blocked by click-to-play.
I'm not sure if splitting media into 5 second segments is new behavior, but that would explain the weirdness.
The noscript change that I referred to in the comment is this: https://github.com/avian2/noscript/commit/2b7bd12752f4d2e4dd0e38290820e707585d6385. I would expect for resources requested directly to load without being blocked. My guess is that the second segment doesn't originate from chrome.
If I'm correct then the severity for this ticket could be lowered, and the summary rewritten.
#19200 (moved) disable MSE close it.
Trac:
Username: rena
Replying to cypherpunks:
Upon further inspection I realized click-to-play is partially working; When requested directly, audio and video resources make a get request for every 5 seconds of media. The first segment loads fine, the second is then blocked by click-to-play.
I'm not sure if splitting media into 5 second segments is new behavior, but that would explain the weirdness.
The noscript change that I referred to in the comment is this: https://github.com/avian2/noscript/commit/2b7bd12752f4d2e4dd0e38290820e707585d6385. I would expect for resources requested directly to load without being blocked. My guess is that the second segment doesn't originate from chrome.
If I'm correct then the severity for this ticket could be lowered, and the summary rewritten.
Does going directly to http://gensho.acc.umu.se/pub/debian-meetings/2016/mini-debconf-vienna/webm/Debian_Installer_for_Novena.webm work for you? It seems on my machine the video is correctly placed behind Click-To-Play before loading. If that's the case I think what is happening is that NoScript is not catching the redirect and the first chunk of data can evade the nsIContentPolicy used to check whether Click-To-Play should get applied.
On a maybe related note this does not seem to be a 6.0 issue as on 5.5.5 (based on ESR38) e.g. the video is not blocked at all for some reason. Which makes me nervous.
Trac:
Status: new to needs_information-
#20255 (moved) is a duplicate.
Trac:
Cc: ma1 to ma1, test400 -
I confirm behavior for linked video (http://gensho.acc.umu.se/pub/debian-meetings/2016/mini-debconf-vienna/webm/Debian_Installer_for_Novena.webm)
and all other webm i request directly, also for mp4 files.
Video plays for 5 seconds, then stops. Although sometimes Shorter, only 2 seconds play (even if video is longer)
Behavior for Embedded video (webm and mp4) is correct though (blocked by default, confirm enables).
With noscript set to "temporarily allow all this page", behavior is same for first direct request. After requesting video directly a second time, video plays full without confirm need. (CLARIFY: of corse without confirm on first request) This is also not wanted behavior.
Trac:
Username: test400 -
I find more wierd behavior on other sites and some webm Sometime simple reloading direct link for webm play whole video without confirm, sometime reloading make play for 10 second instead of 5 and then blocked by click-to-play.
Something is clearly wrong here. If you need specific tests please write.
Trac:
Username: test400 
Replying to test400:
I find more wierd behavior on other sites and some webm [...] If you need specific tests please write.
Yes, please, the more the reproducible cases I can test against, the better. Thank you.
Replying to ma1:
Yes, please, the more the reproducible cases I can test against, the better. Thank you. Maybe, some fixes to test the current case which bugzilla reported in TBB's blog as on 5.5.5 (based on ESR38) e.g. the video is not blocked at all for some reason. Which makes me nervous.
Trac:
Keywords: N/A deleted, noscript added-
#20436 (moved) is a duplicate.
Trac:
Cc: ma1, test400 to ma1, test400, Dbryrtfbcbhgf -
Please check NoScript 2.9.5rc35 from https://noscript.net/getit Thank you.
-
don't worked
in TBB 6.5a4 and NoScript 2.9.5.1rc1 security setting at medium
the holder still too behind
Trac:
Username: i139 -
Replying to 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):
- 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)\// - If the load matches, NoScript suspend the networking channel (no bytes are parsed anymore until resumed)
- 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> - 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!
- As soon as the HTTP headers are available (well before the stream starts to be parsed), it checks for any content-type matching
-
Replying to ma1:
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.
Not sure what you mean but I hear the talk and see slides on the video for a while. So it seems to me there are things that reach the decoder.
Are you noticing anything different? If so, how I can reproduce and verify what you're observing?
I am using an alpha Tor Browser (6.5a4) on a Linux machine (Debian testing) with NoScript 2.9.5.1. I set the security slider to "medium" (click on the green onion -> Security Settings...) which should make things click-to-play. Then I am loading the video pointed to in the description in a new tab. The result is not different from a pre 2.9.5 NoScript being used.
-
Please check 2.9.5.2rc3 from https://noscript.net/getit#devel Thank you.
-
Replying to ma1:
Please check 2.9.5.2rc3 from https://noscript.net/getit#devel Thank you.
Same result as in comment:17 for me, alas.
-
OK, if "Forbid other plugins" was unchecked, "Forbid / " was less effective than it should have been. I've never noticed that because I couldn't conceive someone would want to block HTML 5 media elements while letting any random unknown plugin run, but the Security Slider doesn't share my POV :P It should be fixed in 2.9.5.2rc4, https://noscript.net/getit#devel
mentioned in issue #20255 (moved)
mentioned in issue #20436 (moved)