Opened 3 years ago

Closed 3 years ago

#19210 closed defect (fixed)

NoScript places WebM videos too late behind click-to-play in higher security levels

Reported by: gk Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-regression, tbb-security-slider, tbb-6.0-issues, noscript
Cc: ma1, test400, Dbryrtfbcbhgf Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (23)

comment:1 Changed 3 years ago by 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.

Last edited 3 years ago by cypherpunks (previous) (diff)

comment:2 Changed 3 years ago by gk

Keywords: tbb-6.0-issues added

comment:3 Changed 3 years ago by rena

#19200 disable MSE close it.

comment:4 Changed 3 years ago by mamama

wrong tick, sorry

Last edited 3 years ago by mamama (previous) (diff)

comment:5 Changed 3 years ago by mamama

wrong tick, sorry

Last edited 3 years ago by mamama (previous) (diff)

comment:6 in reply to:  1 Changed 3 years ago by gk

Status: newneeds_information

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.

Last edited 3 years ago by gk (previous) (diff)

comment:7 Changed 3 years ago by gk

Cc: test400 added

#20255 is a duplicate.

comment:8 Changed 3 years ago by 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.

Last edited 3 years ago by test400 (previous) (diff)

comment:9 Changed 3 years ago by 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.

comment:10 in reply to:  9 ; Changed 3 years ago by ma1

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.

comment:11 in reply to:  10 Changed 3 years ago by bugzilla

Keywords: noscript added

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.

comment:12 Changed 3 years ago by gk

Cc: Dbryrtfbcbhgf added

#20436 is a duplicate.

comment:13 Changed 3 years ago by ma1

Please check NoScript 2.9.5rc35 from https://noscript.net/getit
Thank you.

comment:14 Changed 3 years ago by i139

don't worked

tested at http://ftp.acc.umu.se/pub/debian-meetings/2016/mini-debconf-vienna/webm/Debian_Installer_for_Novena.webm

in TBB 6.5a4 and NoScript 2.9.5.1rc1
security setting at medium

the holder still too behind

comment:15 in reply to:  14 ; Changed 3 years ago by ma1

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):

  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!

comment:16 in reply to:  15 Changed 3 years ago by i139

Replying to ma1:

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):

yes, it is

Thanks!

you're welcome.

comment:17 in reply to:  15 Changed 3 years ago by gk

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.

comment:18 Changed 3 years ago by ma1

Please check 2.9.5.2rc3 from https://noscript.net/getit#devel
Thank you.

comment:19 in reply to:  18 Changed 3 years ago by gk

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.

comment:20 Changed 3 years ago by ma1

This looks Security Slider-specific: I can reproduce with Tor Browser 6.5a4 and "Medium", indeed, but not on Firefox ESR 45.5 in default NoScript configuration.
Checking the differences...

comment:21 Changed 3 years ago by ma1

OK, if "Forbid other plugins" was unchecked, "Forbid <AUDIO> / <VIDEO>" 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

Last edited 3 years ago by ma1 (previous) (diff)

comment:22 Changed 3 years ago by i139

tested;
TBB 6.5a4
NoScript 2.9.5.2rc4
secure setting in high
MSE enabled

now all is working proper

Thanks!!

can close the ticket now

comment:23 Changed 3 years ago by gk

Resolution: fixed
Status: needs_informationclosed

Fixed with 2.9.5.2, thanks.

Note: See TracTickets for help on using tickets.