Video codec versions must be allowed individually with MSE
Video codec versions must be allowed individually with MSE
Hi,
Since Noscript has been made E10S compatible and MSE aware, it has started to discriminate against video codecs and even different versions of the same codec, which is a pain.
If you forbid Video and Audio, NoScript will force you to activate both one at a time, after a reload. That's a UI problem that I saw mentioned in this thread, but functionality wise it's as expected.
What's not is that it's codecs and even CODEC VERSIONS that have to be allowed independently. On YouTube just now to get some data to write this post, I had to allow 3 different video/mp4 codec versions depending on the video displayed:
avc1.640028
avc1.4d4020
avc1.4d401e
So my question is, is there a security reason for this, or is it a side effect of implementing MSE blocking that needs to be fixed ? In either case, it is quite inconvenient especially given the UX with tons of reloads.
Since Noscript has been made E10S compatible and MSE aware, it has started to discriminate against video codecs and even different versions of the same codec, which is a pain.
If you forbid Video and Audio, NoScript will force you to activate both one at a time, after a reload. That's a UI problem that I saw mentioned in this thread, but functionality wise it's as expected.
What's not is that it's codecs and even CODEC VERSIONS that have to be allowed independently. On YouTube just now to get some data to write this post, I had to allow 3 different video/mp4 codec versions depending on the video displayed:
avc1.640028
avc1.4d4020
avc1.4d401e
So my question is, is there a security reason for this, or is it a side effect of implementing MSE blocking that needs to be fixed ? In either case, it is quite inconvenient especially given the UX with tons of reloads.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Re: Video codec versions must be allowed individually with M
Shouldn't something be done about this ? It doesn't seem to be intended.
Anyway, as a work around and since I don't want to allow Audio and Video on trusted sites by default, I tried to work around the issue with noscript.allowedMimeRegExp, but couldn't get the syntax right. (Note: I only want to auto allow if it's through HTTPS)
I tried the following all at once, separated by a space:
Tried a couple other things without success. Any idea ? 
Anyway, as a work around and since I don't want to allow Audio and Video on trusted sites by default, I tried to work around the issue with noscript.allowedMimeRegExp, but couldn't get the syntax right. (Note: I only want to auto allow if it's through HTTPS)
I tried the following all at once, separated by a space:
Code: Select all
MSE@https://www\.youtube\.com
video/mp4@https://www\.youtube\.com
audio/mp4@https://www\.youtube\.com
(MSE)@https://www\.youtube\.com

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Re: Video codec versions must be allowed individually with M
Try this -
Code: Select all
(?:audio|video)/.*@https://(?:[^/:]+\.)?youtube\.com
*Always* check the changelogs BEFORE updating that important software!
-
Re: Video codec versions must be allowed individually with M
Works! Thanks. If I understand correctly, any audio or video file will be played even if JS is not allowed, provided I enter their URL directly, right ? (ending in, say, .mp4).
What if I allow video through noscript.allowedMimeRegExp for another site that doesn't use MSE, but instead directly embeds an MP4 file inside the HTML page. Will it run even with JS disallowed ? Trying to understand at which points noscript.allowedMimeRegExp can be triggered exactly.
Secondary question, it's okay if you don't know: I notice the .* after the audio|video part. Do you know what kind of string goes there ? Unless I got it wrong with regular expressions, it doesn't seem to be odd things like
Is there a way to check the string as caught by NoScript, like a debug or verbose mode in NoScript, or maybe the Dev Tools ?
What if I allow video through noscript.allowedMimeRegExp for another site that doesn't use MSE, but instead directly embeds an MP4 file inside the HTML page. Will it run even with JS disallowed ? Trying to understand at which points noscript.allowedMimeRegExp can be triggered exactly.
Secondary question, it's okay if you don't know: I notice the .* after the audio|video part. Do you know what kind of string goes there ? Unless I got it wrong with regular expressions, it doesn't seem to be odd things like
Code: Select all
mp4; codec="avc1.640028"
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Re: Video codec versions must be allowed individually with M
You're welcome.Sep wrote:Works! Thanks.

Right.Sep wrote:If I understand correctly, any audio or video file will be played even if JS is not allowed,
What does this have to do with it? I don't think allowedMimeRegExp distinguishes top-level loads vs embeddings.Sep wrote: provided I enter their URL directly, right ? (ending in, say, .mp4).
It should, yes.Sep wrote:What if I allow video through noscript.allowedMimeRegExp for another site that doesn't use MSE, but instead directly embeds an MP4 file inside the HTML page. Will it run even with JS disallowed ?
This tutorial will help you understand regex.Sep wrote:Secondary question, it's okay if you don't know: I notice the .* after the audio|video part. Do you know what kind of string goes there ? Unless I got it wrong with regular expressions,
No idea. Personally I'd look at modifying the NoScript .xpi.Sep wrote:Is there a way to check the string as caught by NoScript, like a debug or verbose mode in NoScript, or maybe the Dev Tools ?
*Always* check the changelogs BEFORE updating that important software!
-
Re: Video codec versions must be allowed individually with M
Ok, so using that mime type pref is not trivial in the sense that a JS-less HTML page can embed invisible video elements for exploit. Though exploits that can leverage a vulnerability without JS must be rare, that's still good to know and I shouldn't abuse that pref.
I was hoping to use it as a "second line allow", so that instead of allowing JS, then Video, I just allow JS and video is granted right away for that site only.
I think that kind of problems would be entirely solved if NoScript's various protections could be configured per origin, but that's not for tomorrow

Thanks again for your help!
I was hoping to use it as a "second line allow", so that instead of allowing JS, then Video, I just allow JS and video is granted right away for that site only.
I think that kind of problems would be entirely solved if NoScript's various protections could be configured per origin, but that's not for tomorrow

Probably I'm not going to go that farPersonally I'd look at modifying the NoScript .xpi.

Thanks again for your help!
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Re: Video codec versions must be allowed individually with M
Would it? You trust the sites you add to that pref, don't you? FAQ 1.11Sep wrote:Ok, so using that mime type pref is not trivial in the sense that a JS-less HTML page can embed invisible video elements for exploit.
EDIT
Do note that, when dealing with "normal" (non-MSE) embeddings, the pref works based on the site hosting the video. Not the site containing the <video> tag.
/EDIT
I made a similar RFE a while back - viewtopic.php?f=10&t=20812Sep wrote:I was hoping to use it as a "second line allow", so that instead of allowing JS, then Video, I just allow JS and video is granted right away for that site only.
I wouldn't expect it to happen anytime soon, what with the whole WebExtensions deal.
*Always* check the changelogs BEFORE updating that important software!
-
Re: Video codec versions must be allowed individually with M
Yeah, I can get behind your 2nd request in particular. There are others to be made, but I think we may be asking for bloat because most of the issues I have with NoScript can be solved with just two things, and the port to WE seems to be the ideal moment to implement them because they involve some redesign.
Namely, give NoScript a mode where it does double keying, which if I'm using the term correctly (if not, refer to my definition) is the ability to, instead of allowing a domain, allowing by pairs such as "this third-party domain ON this first-party origin". I think making NoScript compatible with Firefox's first-party isolation upcoming feature might be exactly equivalent to that, though that remains to be checked.
And secondly of course, a UI redesign. I love uMatrix's way to handle double keying, and uBlock's concept where there is an UI for normal users and an UI for advanced users is probably a good way to go. NoScript's UI was very good when it came out, but it was a long time ago and people have built on that.
I'd love to see NoScript roadmaps or future plans and current advancement.
I tend to still keep that pref empty since there's no double keying either and I don't quite know how it works and in which conditions it could be abused. But that whole codec bug that seems to only happen with MSE is so annoying that I accept to make an exception. I'm pretty sure it's not as abusable as the regular whitelist anyway. (I mean relatively. I'm not saying it's easy to abuse a user's whitelist or that conditions necessary to even try are often met.)
Namely, give NoScript a mode where it does double keying, which if I'm using the term correctly (if not, refer to my definition) is the ability to, instead of allowing a domain, allowing by pairs such as "this third-party domain ON this first-party origin". I think making NoScript compatible with Firefox's first-party isolation upcoming feature might be exactly equivalent to that, though that remains to be checked.
And secondly of course, a UI redesign. I love uMatrix's way to handle double keying, and uBlock's concept where there is an UI for normal users and an UI for advanced users is probably a good way to go. NoScript's UI was very good when it came out, but it was a long time ago and people have built on that.
I'd love to see NoScript roadmaps or future plans and current advancement.
I have an empty whitelist because whitelisted sites can be used for fingerprinting or XSS or who knows what else, since there's no double keying. With uMatrix I'd have a permanent whitelist and I wouldn't worry, especially through HTTPS.Would it? You trust the sites you add to that pref, don't you?
I tend to still keep that pref empty since there's no double keying either and I don't quite know how it works and in which conditions it could be abused. But that whole codec bug that seems to only happen with MSE is so annoying that I accept to make an exception. I'm pretty sure it's not as abusable as the regular whitelist anyway. (I mean relatively. I'm not saying it's easy to abuse a user's whitelist or that conditions necessary to even try are often met.)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Re: Video codec versions must be allowed individually with M
already planned for NoScript 10Sep wrote:Namely, give NoScript [...] the ability to, instead of allowing a domain, allowing by pairs such as "this third-party domain ON this first-party origin".
also see FAQ 8.10
So use µMatrix and NoScript side-by-side, like I do. You can achieve "double keying" that way as well.Sep wrote:I love uMatrix's way to handle double keying,
BTW we call it "per-site permissions".
... which includes Temp-Allowed sites...Sep wrote:I have an empty whitelist because whitelisted sites
... which provides no protection against XSS, clickjacking, resource abuse, or who knows what else...Sep wrote:can be used for fingerprinting or XSS or who knows what else, since there's no double keying. With uMatrix
... of the same sites you wouldn't permanently allow in NoScript...Sep wrote: I'd have a permanent whitelist
Sep wrote:and I wouldn't worry, especially through HTTPS.

Either you'd have to mis-enter something or there would have to be a serious bug in NoScript.Sep wrote:I tend to still keep that pref empty since there's no double keying either and I don't quite know how it works and in which conditions it could be abused.
*Always* check the changelogs BEFORE updating that important software!
-
Re: Video codec versions must be allowed individually with M
Actually, it should protect against many of those. XSS, for example, doesn't work unless you've specifically permitted attacker.com to send requests to vulnerable.com. Clickjacking is not only blocked by default, but even if you do allow most traffic, there is a special exception for frames, which you must specifically allow if you want them.barbaz wrote:... which provides no protection against XSS, clickjacking, resource abuse, or who knows what else...Sep wrote:uMatrix
For those committed enough to use it, I'd rate uMatrix as a better protection against cross-site attacks. It just takes extra interaction to use.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.
True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.
True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Re: Video codec versions must be allowed individually with M
I think I missed 7 major versions straight.already planned for NoScript 10

Is there no blog post or forum thread regarding what's coming ? I may have missed it but I did look around the forums to no avail.
There was an incompatibility between uMatrix and NoScript a year or so ago, that made uMatrix not work at all while not reporting any abnormality. It's fixed now, but the more you have add-ons, especially with overlapping functionalities, the more this is likely to occur. I chose to use my already installed adblocker uBlock Origin to also block resources that NoScript doesn't care about like CSS and Images, and let NoScript control alone what it cares about.So use µMatrix and NoScript side-by-side, like I do. You can achieve "double keying" that way as well.
I have a less locked down profile with uMatrix but not NoScript. I contemplated installing NoScript in globally allowed mode, but since I don't know what this mode implies exactly for the myriad of security features, I didn't bother, considering I don't use that profile often. I don't see that much of a benefit in using both uMatrix and NoScript together when you also have to have uBlock anyway.
Very few at any one time, not an avenue for fingerprinting, and XSS would be incredibly unlucky.... which includes Temp-Allowed sites...I have an empty whitelist because whitelisted sites
Who said uMatrix was more secure ? It's just more convenient and has one notable security advantage, "per site permissions", that can be worked around by having no whitelist. Or using ABE, yeah, but so far I mostly don't use it due to UX.... which provides no protection against XSS, clickjacking, resource abuse, or who knows what else...can be used for fingerprinting or XSS or who knows what else, since there's no double keying. With uMatrix
Because whitelists can under certain circumstances be enumerated for fingerprinting, and under some more circumstances, XSSed. With per site permissions you can't enumerate and XSS is even less likely.... of the same sites you wouldn't permanently allow in NoScript...With uMatrix I'd have a permanent whitelist
[Pedant image]
HTTPS prevents MITM, a rare but growing threat with current governments. An active MITM can run scripts by abusing your whitelist, double keyed or not, if you go through HTTP, but not HTTPS. HTTPS is always a nice perk to have, though passive MITM is more of a "realistic" threat than active, relatively speaking.
Or MITM, which is why I allowed Youtube video and audio mime types through HTTPS only. The threat is minimal, but I am trying to be coherent.Either you'd have to mis-enter something or there would have to be a serious bug in NoScript.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Re: Video codec versions must be allowed individually with M
Assuming you don't drag&drop (or copy+paste) the malicious link.Thrawn wrote:XSS, for example, doesn't work unless you've specifically permitted attacker.com to send requests to vulnerable.com.
How so?Thrawn wrote:Clickjacking is not only blocked by default,
Not really. It's just a few scattered tidbits, some on this forum and some on Giorgio's blog.Sep wrote:Is there no blog post or forum thread regarding what's coming ?
Overlapping functionality has surprisingly little to do with whether extensions will conflict. In any case, µMatrix doesn't overlap with NoScript as much as you seem to think - viewtopic.php?f=8&t=22001Sep wrote:the more you have add-ons, especially with overlapping functionalities, the more this is likely to occur.
As for the rest of your post, that makes sense now, thanks. It sounds like you're looking for privacy more than security. NoScript is a security tool, not a privacy tool. So again, I think your best bet is to continue to use µMatrix.
*Always* check the changelogs BEFORE updating that important software!
-
Re: Video codec versions must be allowed individually with M
I pick NoScript over uMatrix any day. It's true that I'm looking for privacy, but there is no privacy if security has been compromised, so I am also looking for security first, if you think that way. NoScript beats uMatrix because it covers or can cover almost anything.
But per site permissions are also a notable security improvement against CSRF and XSS. NoScript currently filters but there is no origin isolation. Since first party isolation is coming to Firefox and I think that it either is or enables built in per site permission, NoScript should be able to implement such a feature with less work. So, NoScript 10 which I guess would be the first NoScript to be a 100% WebExtension
And considering that such a feature would also require a new UI, I can expect that the indispensable but terrible blocked object sub-menu will disappear in the process, replaced by convenience and user experience bliss! Yes, I'm hopeful.
But per site permissions are also a notable security improvement against CSRF and XSS. NoScript currently filters but there is no origin isolation. Since first party isolation is coming to Firefox and I think that it either is or enables built in per site permission, NoScript should be able to implement such a feature with less work. So, NoScript 10 which I guess would be the first NoScript to be a 100% WebExtension

And considering that such a feature would also require a new UI, I can expect that the indispensable but terrible blocked object sub-menu will disappear in the process, replaced by convenience and user experience bliss! Yes, I'm hopeful.
If I remember correctly, clickjacking involves a trick with IFrames, and uMatrix has a separate column for frames. So even if you allow scripts, XHR and media elements, you still didn't allowed frames and IFrames.How so?Thrawn wrote:
Clickjacking is not only blocked by default,
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Re: Video codec versions must be allowed individually with M
Regarding overlapping, I meant to say that uMatrix relies on Firefox code that NoScript deals with, as illustrated by the link you gave which talks about the bug I mentioned. In that case, Gorhill didn't know about a specificity of Firefox so he hooked in the wrong place, where NoScript intervened or something (I don't remember the details). And as a result uMatrix appeared to be working but did not.
The more add-ons one has, the more likely it is going to happen (a problem that should be solved or reduced with WebExtensions, I think). That's a recipe for counter-productiveness, i.e. add-ons that together, provide less protection than one of them alone. I'm sure this is quite rare with popular add-ons like NoScript, but in general I'll try to limit the amount of add-ons I install in one profile. I might do differently once WebExtensions arrive, I'll see.
I know tech-savvy people with more than 50 add-ons and they don't report problems, but as illustrated by uMatrix's bug, not all problems are obvious. I favor privacy and security over tiny features, customizability and convenience, for my main profile, but that's just me. (I still have Tree Style Tab because it's just that good, properly configured)
The more add-ons one has, the more likely it is going to happen (a problem that should be solved or reduced with WebExtensions, I think). That's a recipe for counter-productiveness, i.e. add-ons that together, provide less protection than one of them alone. I'm sure this is quite rare with popular add-ons like NoScript, but in general I'll try to limit the amount of add-ons I install in one profile. I might do differently once WebExtensions arrive, I'll see.
I know tech-savvy people with more than 50 add-ons and they don't report problems, but as illustrated by uMatrix's bug, not all problems are obvious. I favor privacy and security over tiny features, customizability and convenience, for my main profile, but that's just me. (I still have Tree Style Tab because it's just that good, properly configured)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Re: Video codec versions must be allowed individually with M
You mean this, right? - viewtopic.php?f=10&t=22486Sep wrote:Since first party isolation is coming to Firefox
Clickjacking certainly could involve a transparent iframe. More generally, as I understand it, it's any means to fool the user to click something other than the element they see they're clicking on.Sep wrote:If I remember correctly, clickjacking involves a trick with IFrames, and uMatrix has a separate column for frames. So even if you allow scripts, XHR and media elements, you still didn't allowed frames and IFrames.
I have µMatrix set to block 3rd-party frames and plugins by default. Thrawn, are you saying I've actually got better protection against clickjacking than ClearClick can deliver?
*Always* check the changelogs BEFORE updating that important software!
-