InformAction Forums

Posted: **Sun Nov 16, 2014 6:09 am**

Hi.
I'm trying to find the correct Preference NameS in about:config for blocking inline scripts,1st. party (i)frames,& "if?" possible inline (i)frames,& pictures.
Unfortunately,I just can't remember the correct ones.

YES,I'm aware that NS was not intended for blocking pics,but it's becoming a problem.
...And NO,I don't want to install any add-ons.

Posted: **Sun Nov 16, 2014 6:08 pm**

URL where you see the issue?

Are you looking for:

NoScript | Options | Embeddings -> Apply these restrictions to whitelisted sites too (uncheck)

Or leave it checked & uncheck Forbid <IFRAME> & <FRAME>

Posted: **Sun Nov 16, 2014 7:11 pm**

guest wrote:blocking inline scripts

Done by default.

guest wrote:1st. party (i)frames

noscript.forbidIFramesContext

guest wrote:"if?" possible inline (i)frames

Not possible AFAIK.

guest wrote:pictures.

This can be done with NoScript, but it's not an about:config pref. You will need to use ABE.

Posted: **Mon Nov 17, 2014 2:04 pm**

Hello Rube.
It's good to hear from you again.

I'm not going to waste your time with an example,because inline everything is everywhere.

I'm not a noob.I know about the Embeddings tab in options.

Anything you can tell me about blocking inline pics?

Hello Barbaz .
It's also good to hear from you again.

guest wrote:
blocking inline scripts

Done by default.

Please refresh my memory...Mozilla decided to stop blocking inline scripts in FX in one of the recent versions.
I think there was a discussion here about that 5 months ago?
So is blocking inline scripts a recent feature,& I just forgot the change log for the recent NS versions?
...or has it been like this pretty much from the start?
I think it's the 1st one.I'm sure there was some change/update about something like this?

noscript.forbidIFramesContext looks familiar when it comes to blocking 1st. party Iframes.
Thank you,but what value do I use?

What about blocking 1st. party Frames?

Also please refresh my memory about these:
noscript.forbidIFramesParentTrustCheck
noscript.forbidMixedFrames

I think there should be a similar page for NS like this one:http://kb.mozillazine.org/About:config_entries
Will any of you waste your time doing this?
It would save a lot of time answering questions like mine in the long run.

guest wrote:
"if?" possible inline (i)frames

Not possible AFAIK.

I thought so,because I don't remember reading anything about this here.
Please ask Giorgio for this feature request.
...And NO,I'm not going to waste my time signing up,& asking him directly.I know for a fact it hasn't worked out for the 99.99% of people in the past.

Since Mozilla got rid of Load Images in FX's Content tab in one of the recent versions.
I made an ABE rule like this:
# PICS BLOCK
Site *.*/*.jp* *.*/*.png* *.*/*.gif* *.*/*.bmp* *.*/*.svg*
.example.com/something.js
Deny

To undo it all I have to do is to put an # in front of *.*/*.jp*
It's better than doing it in about:config or using some add-on.

However,I'm sure there is no ABE rule to block inline pics?
Am I wrong?

Posted: **Mon Nov 17, 2014 5:14 pm**

guest wrote:Please refresh my memory...Mozilla decided to stop blocking inline scripts in FX in one of the recent versions.
I think there was a discussion here about that 5 months ago?
So is blocking inline scripts a recent feature,& I just forgot the change log for the recent NS versions?
...or has it been like this pretty much from the start?

... what?
NoScript has always been blocking inline scripts. If it's not, and you haven't (Temp)Allowed the site, you found a security-critical bug, please report it per these instructions.

guest wrote:I think it's the 1st one.I'm sure there was some change/update about something like this?

Oh, you mean the whole CAPS deal. NoScript uses a different method of blocking inline scripts in modern Gecko (>= 28). So you're safe.

guest wrote:noscript.forbidIFramesContext looks familiar when it comes to blocking 1st. party Iframes.
Thank you,but what value do I use?

0

guest wrote:What about blocking 1st. party Frames?

Different checkbox in Embeddings.. so if I were you I'd try a harmless example page to see whether the forbidIFramesContext pref applies to FRAMEs too.
(I don't know. I don't use the frame blocking. If you can't find a suitable test page let me know and I'll try it out with my local server and let you know the results.)

guest wrote:
guest wrote:
"if?" possible inline (i)frames

Not possible AFAIK.
I thought so,because I don't remember reading anything about this here.
Please ask Giorgio for this feature request.
...And NO,I'm not going to waste my time signing up,& asking him directly.I know for a fact it hasn't worked out for the 99.99% of people in the past.

Why would you want to block inline iframes? There is no security or privacy benefit to doing that.
I'm not going to ask for that feature, sorry.

guest wrote:Since Mozilla got rid of Load Images in FX's Content tab in one of the recent versions.
I made an ABE rule like this:
# PICS BLOCK
Site *.*/*.jp* *.*/*.png* *.*/*.gif* *.*/*.bmp* *.*/*.svg*
.example.com/something.js
Deny

To undo it all I have to do is to put an # in front of *.*/*.jp*
It's better than doing it in about:config or using some add-on.

However,I'm sure there is no ABE rule to block inline pics?
Am I wrong?

"Inline pics" meaning data URIs? Yeah, I don't think ABE filters those.. or at least, ABE is not designed to filter them...

Posted: **Mon Nov 17, 2014 5:45 pm**

guest wrote:I'm not going to waste your time with an example,because inline everything is everywhere.

@therube: inline images can be found on noscript.net if you are on Windows, and inline iframe is found, say, here (look for "srcdoc").

Posted: **Tue Nov 18, 2014 12:05 pm**

guest wrote:
Please refresh my memory...Mozilla decided to stop blocking inline scripts in FX in one of the recent versions.
I think there was a discussion here about that 5 months ago?
So is blocking inline scripts a recent feature,& I just forgot the change log for the recent NS versions?
...or has it been like this pretty much from the start?

... what?
NoScript has always been blocking inline scripts.

Good to know.Thanks for reminding me.

guest wrote:I think it's the 1st one.I'm sure there was some change/update about something like this?

Oh, you mean the whole CAPS deal. NoScript uses a different method of blocking inline scripts in modern Gecko (>= 28). So you're safe.

Yeah that sounds familiar.Thanks.
However,what is/are the Preference Name(s) that control this?

guest wrote:
noscript.forbidIFramesContext looks familiar when it comes to blocking 1st. party Iframes.
Thank you,but what value do I use?

0

Thank you,but what happens if I use 1,2,or leave it blank?
Seriously,there needs to be an About:config Entries page for NS.

guest wrote:
What about blocking 1st. party Frames?

Different checkbox in Embeddings.. so if I were you I'd try a harmless example page to see whether the forbidIFramesContext pref applies to FRAMEs too.
(I don't know. I don't use the frame blocking. If you can't find a suitable test page let me know and I'll try it out with my local server and let you know the results.)

I'll try to use the example you gave to Rube when I have more time.
In the mean time I "think?" this will help:http://www.imdb.com/title/tt2191671/

guest wrote:
"if?" possible inline (i)frames

Not possible AFAIK.

I thought so,because I don't remember reading anything about this here.
Please ask Giorgio for this feature request.
...And NO,I'm not going to waste my time signing up,& asking him directly.I know for a fact it hasn't worked out for the 99.99% of people in the past.

Why would you want to block inline iframes? There is no security or privacy benefit to doing that.
I'm not going to ask for that feature, sorry.

What's the difference if the Frames,or Iframes are done in a regular way,or as inline.They'll be there regardless of the delivery method.
Otherwise why bother blocking the Frames,or Iframes at all.
So please ask Giorgio for this feature request.

guest wrote:
Since Mozilla got rid of Load Images in FX's Content tab in one of the recent versions.
I made an ABE rule like this:
# PICS BLOCK
Site *.*/*.jp* *.*/*.png* *.*/*.gif* *.*/*.bmp* *.*/*.svg*
.example.com/something.js
Deny

To undo it all I have to do is to put an # in front of *.*/*.jp*
It's better than doing it in about:config or using some add-on.

However,I'm sure there is no ABE rule to block inline pics?
Am I wrong?

"Inline pics" meaning data URIs? Yeah, I don't think ABE filters those.. or at least, ABE is not designed to filter them...

Well,then there's definitely no such ABE rules Syntax.Otherwise I would had seen it here.

I'm not even going to talk about the data URIs/data:image/whatever;base64.
We all know it's a lost cause.

If you want an example:http://windows.microsoft.com/en-us/wind ... emes_files
The blue Windows 8 logo in the upper-left corner of the page.
Even if you get rid of it.There's an identical green one underneath it which is definitely inline.

Posted: **Tue Nov 18, 2014 5:49 pm**

guest wrote:
Oh, you mean the whole CAPS deal. NoScript uses a different method of blocking inline scripts in modern Gecko (>= 28). So you're safe.
Yeah that sounds familiar.Thanks.
However,what is/are the Preference Name(s) that control this?

Don't know what you're referring to, sorry..
The whitelist is capability.policy.maonoscript.sites

guest wrote:
guest wrote:
noscript.forbidIFramesContext looks familiar when it comes to blocking 1st. party Iframes.
Thank you,but what value do I use?

0
Thank you,but what happens if I use 1,2,or leave it blank?
Seriously,there needs to be an About:config Entries page for NS.

Yeah, I too wish the docs were less scattered.

Code: Select all

  0 -- block always
  1 -- block if parent is in a different site (default)
  2 -- block if parent is in a different domain
  3 -- block if parent is in a different 2nd level domain

guest wrote:
guest wrote:
What about blocking 1st. party Frames?

Different checkbox in Embeddings.. so if I were you I'd try a harmless example page to see whether the forbidIFramesContext pref applies to FRAMEs too.
(I don't know. I don't use the frame blocking. If you can't find a suitable test page let me know and I'll try it out with my local server and let you know the results.)
I'll try to use the example you gave to Rube when I have more time.

Don't think I gave an example of FRAMEs...
OK I'll go check it.
EDIT Yes it does also apply to FRAMEs.

guest wrote:What's the difference if the Frames,or Iframes are done in a regular way,or as inline.They'll be there regardless of the delivery method.
Otherwise why bother blocking the Frames,or Iframes at all.
So please ask Giorgio for this feature request.

Please see http://noscript.net/faq#qa4_8. This feature is in NoScript to help prevent *cross-site* attacks; blocking part of the page itself isn't going to do anything in that regard.
Sounds like what you want is an annoyance zapped, not a security feature.. and NS isn't an annoyance removal tool except coincidentally. So unless you can show by example that IFRAME srcdocs can be exploited just like "normal" IFRAMEs in a way that has security implications, this feature request has no use in NoScript.

guest wrote:
"Inline pics" meaning data URIs? Yeah, I don't think ABE filters those.. or at least, ABE is not designed to filter them...
Well,then there's definitely no such ABE rules Syntax.Otherwise I would had seen it here.
I'm not even going to talk about the data URIs/data:image/whatever;base64.
We all know it's a lost cause.

If you want an example:http://windows.microsoft.com/en-us/wind ... emes_files
The blue Windows 8 logo in the upper-left corner of the page.
Even if you get rid of it.There's an identical green one underneath it which is definitely inline.

Oh.. that's something else entirely. It's inline SVG, and I have no idea how to "block" it (ABE sure can't), but I suppose something like this surrogate script could zap it after the fact:

Code: Select all

noscript.surrogate.byeinlinesvg.replacement : window.addEventListener('load', function() {for (let e of document.getElementsByTagName('svg')){e.parentNode.removeChild(e);} }, false);
noscript.surrogate.byeinlinesvg.sources : !@^https?://

Posted: **Sat Nov 22, 2014 4:39 pm**

@ Barbaz.
I'm very sorry for such a late reply.I had been very busy.

Okay,I'll rephrase the question in the most basic way possible.

1.How does NS blocks inline scripts?
1.1.How does NS blocks inline scripts with CAPS in Fx28,& newer Fx versions?
2.In about:config what Preference name(s) controls this?
3.What are the values?

A bit more...
4.If an inline Iframe,or an inline Frame has an inline script inside of it.Is the inline script blocked by default? (I think so.)
If not.See #3 above.
5.If an inline script is 3rd. party.
For example:inside the inline script.the inline script also calls on a 3rd. party JS:http://thirdparty.com/blah/bad.js
Is the 3rd. party script blocked,or goes undetected? (I think it's blocked like always.)

Something else to consider...
6.If an inline Iframe,or an inline Frame also calls on a 3rd. party Iframe,or a 3rd. party Frame:http://thirdparty.com/blah/bad.html (Yes,frames inside frames.)
Then,the original inline Iframe,or the original inline Frame also has an inline script inside of it.That also calls on a 3rd. party JS...WTF happens then?
Yes,I had seen this,& if I could remember an example.I would give it to you.

Even worse...
7.What if the 3rd. party Iframe,or the 3rd. party Frame have their own inline scripts,that also call on a 4th. party JS?...Wait,my eyes are bleeding...

What happens then?

Yes,this answers my questions,but it does not apply to inline Iframes,or an inline Frames:https://noscript.net/faq#qa4_8

guest wrote:
What's the difference if the Frames,or Iframes are done in a regular way,or as inline.They'll be there regardless of the delivery method.
Otherwise why bother blocking the Frames,or Iframes at all.
So please ask Giorgio for this feature request.

Please see http://noscript.net/faq#qa4_8. This feature is in NoScript to help prevent *cross-site* attacks; blocking part of the page itself isn't going to do anything in that regard.
Sounds like what you want is an annoyance zapped, not a security feature.. and NS isn't an annoyance removal tool except coincidentally. So unless you can show by example that IFRAME srcdocs can be exploited just like "normal" IFRAMEs in a way that has security implications, this feature request has no use in NoScript.

I think we all know that NS is a security tool.The fact that NS blocks ads,or annoyances are just beneficial side effects.

Look at it this way:
1.Pretty much every website uses inline Iframes,or inline Frames.They are only annoyances because they were designed that way.They could just as easily had been designed to be malicious.With no way to stop them.WHAT WILL YOU DO THEN???

If you want to wait until you,or someone else gets attacked,& hopefully not suffer the consequences.That's fine,but I would take preventative measures now.

2.Reasons/Questions 4-7 above.
3.Inline pics.

At this point everybody uses them,& with no "reqular" ways to block any of these.It's just a matter of time before disaster strikes.

If you still refuse...how about a surrogate to block inline Iframes,& inline Frames?
While surrogates are mostly for JS.Will it work for inline Iframes,& inline Frames?

Finally...Like you guys always say:It can't hurt to ask.
PLEASE ask Giorgio to block inline Iframes,& inline Frames in NS just like blocking regular Iframes,& Frames.

Code: Select all

noscript.surrogate.byeinlinesvg.replacement : window.addEventListener('load', function() {for (let e of document.getElementsByTagName('svg')){e.parentNode.removeChild(e);} }, false);
noscript.surrogate.byeinlinesvg.sources : !@^https?://

Wow thanks.
I was going to ask for a surrogate in my last reply,but you beat me to it.Glad you're 1 step ahead of me.
I'll test it when I have more time.

Since we are on the subject of pics...
Barbaz,I would like to know your personal opinion on this.

We all know that Giorgio for some unknown reason thinks that blocking pics has something to do with ads instead of security. (Which is not true.)Not to mention that a million people had failed to convince him otherwise. (Privacy=Security.)

Lets use scorecardresearch.com as an example.
You can black list it/untrusted it,& then go to Options-Embeddings-"Check" Block every object from a site marked as untrusted.
However,you still get that invisible 1x1 pixel web bug/beacon.
Wouldn't it be nice if you could block that pic without a host list,ABP/something similar,or an ABE rule?
BTW,this should also apply to inline pics.
What do you think?

Speaking of which,please remind me.
If you select Block every object from a site marked as untrusted.Are CSS,& XML blocked?

Posted: **Sat Nov 22, 2014 7:40 pm**

guest wrote:1.How does NS blocks inline scripts?
1.1.How does NS blocks inline scripts with CAPS in Fx28,& newer Fx versions?

Fx 28+ introduced a new API for script blocking, NoScript uses that when available.

guest wrote:2.In about:config what Preference name(s) controls this?
3.What are the values?

Oh, that's what you're asking about inline scripts. There is no preference to block or not block inline scripts specifically (it's useless and dangerous to have that configurable).

guest wrote:A bit more...
4.If an inline Iframe,or an inline Frame has an inline script inside of it.Is the inline script blocked by default? (I think so.)

Yes.
(I'm fairly sure you can't get inline FRAMEs without data URIs, which would be hard to find an example.)

guest wrote:5.If an inline script is 3rd. party.
For example:inside the inline script.the inline script also calls on a 3rd. party JS:http://thirdparty.com/blah/bad.js
Is the 3rd. party script blocked,or goes undetected? (I think it's blocked like always.)

Yep, blocked.

guest wrote:Something else to consider...
6.If an inline Iframe,or an inline Frame also calls on a 3rd. party Iframe,or a 3rd. party Frame:http://thirdparty.com/blah/bad.html (Yes,frames inside frames.)
Then,the original inline Iframe,or the original inline Frame also has an inline script inside of it.That also calls on a 3rd. party JS...WTF happens then?
Yes,I had seen this,& if I could remember an example.I would give it to you.

Even worse...
7.What if the 3rd. party Iframe,or the 3rd. party Frame have their own inline scripts,that also call on a 4th. party JS?...Wait,my eyes are bleeding... What happens then?

Yes,this answers my questions,but it does not apply to inline Iframes,or an inline Frames:https://noscript.net/faq#qa4_8

Scripts will be blocked if the site they're served from is not (Temp)Allowed, regardless if their 3rd-party or 3rd-3rd-3rd-3rd-3rd-3rd-...party.
~~About (I)FRAMEs, I'll construct an example of this on my local server and get back to you.~~
3rd-party IFRAME inside inline IFRAME is blocked (as expected).

guest wrote:I think we all know that NS is a security tool.The fact that NS blocks ads,or annoyances are just beneficial side effects.

Look at it this way:
1.Pretty much every website uses inline Iframes,or inline Frames.They are only annoyances because they were designed that way.They could just as easily had been designed to be malicious.With no way to stop them.WHAT WILL YOU DO THEN???

If you want to wait until you,or someone else gets attacked,& hopefully not suffer the consequences.That's fine,but I would take preventative measures now.

2.Reasons/Questions 4-7 above.
3.Inline pics.

At this point everybody uses them,& with no "reqular" ways to block any of these.It's just a matter of time before disaster strikes.

If you still refuse...how about a surrogate to block inline Iframes,& inline Frames?
While surrogates are mostly for JS.Will it work for inline Iframes,& inline Frames?

Finally...Like you guys always say:It can't hurt to ask.
PLEASE ask Giorgio to block inline Iframes,& inline Frames in NS just like blocking regular Iframes,& Frames.

*I* am not going to ask because IMO that is pointless. It's just like asking to block all DIVs in a page. It's not going to help you in terms of security or privacy.
If you're fine with a surrogate, this one should zap inline (I)FRAMES after the fact:

Code: Select all

noscript.surrogate.noinlineframe.replacement : window.addEventListener("load", function(){for(let j of document.querySelectorAll('iframe[srcdoc],iframe[src^="data:"],frame[src^="data:"]')){j.parentNode.removeChild(j);}}, false);
noscript.surrogate.noinlineframe.sources : !@^https?://

guest wrote:Wow thanks.
I was going to ask for a surrogate in my last reply,but you beat me to it.Glad you're 1 step ahead of me.
I'll test it when I have more time.

You're welcome.

guest wrote:Since we are on the subject of pics...
Barbaz,I would like to know your personal opinion on this.

We all know that Giorgio for some unknown reason thinks that blocking pics has something to do with ads instead of security. (Which is not true.)Not to mention that a million people had failed to convince him otherwise. (Privacy=Security.)

No, Privacy != Security. That's why TOR Browser has NoScript installed with cascading permissions mode enabled by default, so that users can't be fingerprinted by what they Allow (yes, that's possible). It's not smart for security because a malicious attacker could attach a malware script to the site, which when the site is allowed, that script's site is allowed so the script gets executed in TOR Browser but not in normal default NoScript where the malware hosting site stays default-denied.

guest wrote:Lets use scorecardresearch.com as an example.
You can black list it/untrusted it,& then go to Options-Embeddings-"Check" Block every object from a site marked as untrusted.
However,you still get that invisible 1x1 pixel web bug/beacon.
Wouldn't it be nice if you could block that pic without a host list,ABP/something similar,or an ABE rule?
BTW,this should also apply to inline pics.
What do you think?

Old versions of NoScript used to offer exactly the sort of thing you're talking about, but Fx 4+ made it impossible to implement, so it was removed.

guest wrote:Speaking of which,please remind me.
If you select Block every object from a site marked as untrusted.Are CSS,& XML blocked?

CSS are not. I don't know about XML or how I'd construct an example of that to check, sorry.

Posted: **Sun Nov 23, 2014 1:09 pm**

guest wrote:
2.In about:config what Preference name(s) controls this?
3.What are the values?

Oh, that's what you're asking about inline scripts. There is no preference to block or not block inline scripts specifically (it's useless and dangerous to have that configurable).

Shame there's no way to block reqular inline scripts,or inline scripts with CAPS in about:config.
I wouldn't say it's dangerous.If anything,it could be good.
If you (Temporary) Allow JS to run.Then,inline scripts run as well.You can't even block them with ABE.
Wouldn't it be nice to have the fine grain control to (Temporary) Allow JS to run,but still be able to block any/all inline scripts?
Would yet another surrogate be in order?

As far as everything else...THANK YOU very much for confirming everything gets blocked like I thought it would be.

*I* am not going to ask because IMO that is pointless. It's just like asking to block all DIVs in a page. It's not going to help you in terms of security or privacy.
If you're fine with a surrogate, this one should zap inline (I)FRAMES after the fact:
Code: Select all
Code: Select all
noscript.surrogate.noinlineframe.replacement : window.addEventListener("load", function(){for(let j of document.querySelectorAll('iframe[srcdoc],iframe[src^="data:"],frame[src^="data:"]')){j.parentNode.removeChild(j);}}, false);
noscript.surrogate.noinlineframe.sources : !@^https?://

Thanks for the surrogate.I'll test it when I have more time.
No,I don't want to block all/most DIVs.That would leave the page pretty much empty.

guest wrote:
Since we are on the subject of pics...
Barbaz,I would like to know your personal opinion on this.

We all know that Giorgio for some unknown reason thinks that blocking pics has something to do with ads instead of security. (Which is not true.)Not to mention that a million people had failed to convince him otherwise. (Privacy=Security.)

No, Privacy != Security. That's why TOR Browser has NoScript installed with cascading permissions mode enabled by default...

1.You mean disabled!?
2.I think we all know that If you (Temporary) Allow 1st. party JS to run.It will trigger/run it's sub domain(s) JS.Which will trigger/run 3rd. party JS.At this point,sub domain(s),or 3rd. party JS can trigger/run all kinds of malicious crap.
Clearly no one should ever allow that!
Cascading is only good on respectable/white listed sites.
3.That's not what I was asking. (Keep reading.)

guest wrote:
Lets use scorecardresearch.com as an example.
You can black list it/untrusted it,& then go to Options-Embeddings-"Check" Block every object from a site marked as untrusted.
However,you still get that invisible 1x1 pixel web bug/beacon.
Wouldn't it be nice if you could block that pic without a host list,ABP/something similar,or an ABE rule?
BTW,this should also apply to inline pics.
What do you think?

Old versions of NoScript used to offer exactly the sort of thing you're talking about, but Fx 4+ made it impossible to implement, so it was removed.

1.Yes,I remember when NS used to block web bugs/beacons.
Yes,I know that:Unfortunately the Fx's code was changed,& Fx doesn't know the dimensions of pics until Fx opens them.That's why NS couldn't block web bugs/beacons anymore.
2.That's not what I was asking either.

I will rephrase these last two,& CSS/XML. (Btw,thanks for confirming that CSS,& XML are not blocked just like I thought.)

Wouldn't it be nice if you blocked/untrusted scorecardresearch.com.Then,went to Options-Embeddings-"Checked" Block every object from a site marked as untrusted.
Everything coming from scorecardresearch.com would get blocked.Including:regular Objects,CSS,XML,& pics.As well as:inline scripts,inline (I)Frames,& inline pics.Everything
Just as if you 127,255,or 0 scorecardresearch.com in hosts.

I would ask for this feature request,but I had learned my lesson the last time.
You all lied to us.I asked,it hurt,I'm bleeding,& limping away.

Posted: **Sun Nov 23, 2014 5:41 pm**

guest wrote:Wouldn't it be nice to have the fine grain control to (Temporary) Allow JS to run,but still be able to block any/all inline scripts?
Would yet another surrogate be in order?

You can do this as it is, but you need surrogates, and it's a real pain:
download external JS files you want to run
go to about:config
create a surrogate where replacement is a file: URL pointing to the downloaded script, sources is only the exact URL of the script you downloaded; do this for each downloaded script
now Forbid the site

I doubt this will be added as an easy-to-use feature in NoScript, because NS is designed with the idea that either you trust the management of a site enough to run arbitrary scripts from them or not, so per-script-tag blocking would be seen as pointless.

guest wrote:
No, Privacy != Security. That's why TOR Browser has NoScript installed with cascading permissions mode enabled by default...
1.You mean disabled!?
2.I think we all know that If you (Temporary) Allow 1st. party JS to run.It will trigger/run it's sub domain(s) JS.Which will trigger/run 3rd. party JS.At this point,sub domain(s),or 3rd. party JS can trigger/run all kinds of malicious crap.
Clearly no one should ever allow that!
Cascading is only good on respectable/white listed sites.
3.That's not what I was asking. (Keep reading.)

No, I really mean enabled - that's kind of my whole point there. I agree with you that it's too scary to ever allow.

guest wrote:I will rephrase these last two,& CSS/XML. (Btw,thanks for confirming that CSS,& XML are not blocked just like I thought.)

Wouldn't it be nice if you blocked/untrusted scorecardresearch.com.Then,went to Options-Embeddings-"Checked" Block every object from a site marked as untrusted.
Everything coming from scorecardresearch.com would get blocked.Including:regular Objects,CSS,XML,& pics.As well as:inline scripts,inline (I)Frames,& inline pics.Everything
Just as if you 127,255,or 0 scorecardresearch.com in hosts.

I would ask for this feature request,but I had learned my lesson the last time.
You all lied to us.I asked,it hurt,I'm bleeding,& limping away.

This one is very reasonable actually (+1 from me although I wouldn't use it myself), and you will eventually have it if you're willing to install another addon - Thrawn is working on it. (What you want here shouldn't be too hard to get working. If Thrawn drops that capability from his addon I'm willing to ask Giorgio for this one and maybe provide a working example or patch.)

InformAction Forums

Inline Problems

Inline Problems

Re: Inline Problems

Re: Inline Problems

Re: Inline Problems

Re: Inline Problems

Re: Inline Problems

Re: Inline Problems

Re: Inline Problems

Re: Inline Problems

Re: Inline Problems

Re: Inline Problems

Re: Inline Problems