InformAction Forums

Posted: **Sun Jun 01, 2014 9:27 pm**

hello Giorgio.
this is in regard to:v 2.6.8.27rc2
[Surrogate] External script surrogates are now triggered whenever a matching script fails to load,no matter the reason,e.g. NoScript permissions,ABE,ABP or RequestPolicy.

i hope i'm wrong,but does this mean:bad js will run(on some level) even if it's blocked by ABE!?
please tell me i'm wrong!

i would ask for you to add some kind of ns option in about:config(that will toggle this on,& off) ,but that's a bad idea.
'Cause it will eventually get lost in the ocean of posts/threads in this forum.(and no one will remember it.)

so,please add:DON'T Force Surrogates(with a checkbox in front of it) somewhere in the noscript's menu.
that will toggle this on,& off in about:config.

thank you.

Posted: **Sun Jun 01, 2014 9:40 pm**

nobody0 wrote:[Surrogate] External script surrogates are now triggered whenever a matching script fails to load,no matter the reason,e.g. NoScript permissions,ABE,ABP or RequestPolicy.

i hope i'm wrong,but does this mean:bad js will run(on some level) even if it's blocked by ABE!?
please tell me i'm wrong!

you're wrong

it means that if noscript would run a surrogate script in place of a blocked "bad" script, it's no longer required that the original "bad" script be blocked *specifically* by noscript's normal script blocking permissions in order for the surrogate to run

why would you want surrogates but not want that??

all surrogates (i.e. all the javascript that could run due to this new feature) can be viewed in about:config -> noscript.surrogate.*.replacement

Posted: **Sun Jun 01, 2014 10:33 pm**

hello barbaz.

if noscript would run a surrogate script in place of a blocked "bad" script, it's no longer required that the original "bad" script be blocked *specifically* by noscript's normal script blocking permissions in order for the surrogate to run

see this is where it gets confusing...now that the surrogates are being forced.
what will happen when the bad js is changed/updated?(SORRY,i forgot to mention this part.)
1.)wouldn't ns now cause problems???
2.)would the bad js start working???
3.)in general,when the surrogates are forced.does nothing happen,or can/will they make whatever bad js was supposed to make work/appear with in the page active???
4.)does this effect only the js,or other stuff???

that's why i want Giorgio to answer.

yes,yes i had seen all gazillion noscript.surrogate(s) in about:config.
nothing new there that i wasn't aware of.

Posted: **Sun Jun 01, 2014 11:10 pm**

Guest wrote:what will happen when the bad js is changed/updated?

Then Giorgio might need to update the surrogate in NoScript to properly fake the changed functionality. But that's not any different from before.

Guest wrote:1.)wouldn't ns now cause problems???

no

Guest wrote:2.)would the bad js start working???

no

Guest wrote:3.)in general,when the surrogates are forced.does nothing happen,or can/will they make whatever bad js was supposed to make work/appear with in the page active???

Sorry, but I'm not understanding this question.

Guest wrote:4.)does this effect only the js,or other stuff???

only the js

FWIW the discussion that led to this change you're concerned about is http://forums.informaction.com/viewtopi ... 10&t=19598

Posted: **Mon Jun 02, 2014 2:24 am**

I think the OP does not understand the concept of surrogate scripts.

The scenario where they work is:

NoScript blocks a script you don't want, like Google Analytics;
The page is poorly (or deliberately) designed to rely on the blocked script, so that the page's own scripts break;
NoScript provides blank/empty/default values (via a surrogate script) to avoid JavaScript errors and make the page work.

So questions about 'will the bad script now run' don't actually make sense. There is no question of the bad script running. It never even gets downloaded. All that happens is that NoScript (following rules you can specify) will make an attempt to patch up the broken page so it keeps working.

And the content of this change is: previously, if something other than NoScript (eg RequestPolicy) blocked a bad script, then NoScript would not detect it, and would not run the surrogate. So the page would stay broken.

Posted: **Mon Jun 02, 2014 3:59 am**

hi barbaz.

Guest(ME) wrote:what will happen when the bad js is changed/updated?

Then Giorgio might need to update the surrogate in NoScript to properly fake the changed functionality. But that's not any different from before.

exactly!!! so,you don't know what's going on in the background before it's noticed,or fixed.(it's not like everybody auto updates.)
which means:you still have to block bad domains/js,& other stuff through ABE.(not blocking it through ABE is dangerous!) this makes forcing surrogates pointless!

do you really not see this???

i don't want people to start relying on surrogates.they had caused problems in the past.
bad domains must be,must be,must be blocked through host,& when certain js is necessary the fine grain control of ABE is a must!!!

how sure are you that it won't cause problems,or work on some level???(you know bad js can trigger an endless chain of garbage,& other stuff.)especially if someone "temporary and/or allows," bad domains,or whitelists them.

btw,when the surrogates are forced.does it make a difference if the bad domains are blacklisted???
doesn't look like it will.

Guest(ME) wrote:3.)in general,when the surrogates are forced.does nothing happen,or can/will they make whatever bad js was supposed to make work/appear with in the page active???

Sorry, but I'm not understanding this question.

pretty much a detailed extension of #2.
which you confirmed my fears by answering #4.

this is pretty much what i thought,& it's a horrible idea.i hope Giorgio won't force this!

lol.yeah,i read that thread.

hey,hey Thrawn.
it's very good to hear from you again!!!

no,no.i know/understand how surrogates work.(it's just hard to tell the extend of each surrogate,because they do several things.)
i typically don't like getting into this mess,& try to forget it.

like i said to barbaz,"if the bad js is changed/updated.especially,if there are no ABE rules to block bad domains/js,(not to mention other stuff) & the bad domains/js are whitelisted/(temporary) allowed."
then,what???what exactly happens when the surrogate is outdated?(can any js work on any level then.)
do/will the "forced surrogates" override the bad domains/js if the bad domains are blacklisted???

this is "basically" what i'm trying to find out.(i'm very sorry i wasn't more clear/specific from the start.)
i was hoping Giorgio will explain this in detail like he usually does.

if the bad js is changed/updated.it would break the page,& there's no way to turn it off because it's forced.
well,maybe by destroying noscript.surrogate.name value(s)
see the problem???

not forcing the surrogates is better!
let things be the way they are,or give us an easy way(what i had proposed) to turn it off.

Posted: **Mon Jun 02, 2014 4:22 am**

seems I'm missing something here, so I'll leave this thread alone now, but last thing I'll say is you can completely disable surrogate scripts by going
about:config -> set noscript.surrogate.enabled to false

Posted: **Mon Jun 02, 2014 10:42 am**

@nobody0: Sorry, but you are still missing the point. Surrogates are not overriding the replacement scripts; they are filling in the gaps left behind by those scripts being blocked. You block a domain, eg google-analytics.com, and it is blocked. No scripts get downloaded from there. Period. It is forbidden, and it will show up on your NoScript menu that way.

Now, if you have defined a surrogate script for google-analytics.com (there is also a built-in one), then when a site tries to download scripts from there, NoScript will jump in and provide a fake script, to try to keep the page happy. But if you don't define a surrogate, or the pattern used to apply it is out-of-date, that doesn't mean that the site gets the real script. The domain is forbidden; scripts are blocked. The page will get a JavaScript error and possibly be non-functional.

Surrogates do not, in any way, interfere with script-blocking. They simply try to fix pages that get broken by the script-blocking. The worst-case scenario is that the page fails to load the JavaScript it needs and consequently does not work.

Posted: **Mon Jun 02, 2014 10:44 pm**

@ barbaz.

...you can completely disable surrogate scripts by going about:config -> set noscript.surrogate.enabled to false.

yes,exactly!
however,like i said,"if someone forgets,can't find it here in the forum,or (re)installs ff.they will not be able to turn off the forced surrogates."
that's why i said."there absolutely needs to be a a way not to force surrogates."
OR
Surrogates ON.(with a checkbox in front of it somewhere in the noscript's menu.)
which is what you seem to be leaning towards!?

now that i think about it,it couldn't hurt to have Temporary Allow Surrogates,or Forbid Surrogates in noscript's pull down menu.

anyway,barbaz THANK YOU VERY MUCH for your help,& time.
good bye.

@ Thrawn.

...Surrogates are not overriding the replacement scripts; they are filling in the gaps left behind by those scripts being blocked. You block a domain, eg google-analytics.com, and it is blocked. No scripts get downloaded from there. Period. It is forbidden, and it will show up on your NoScript menu that way.

you could just had said,"the surrogates are not always on.(which Giorgio clearly never confirmed.)the surrogates only
work when you (temporary)allow ex:google-analytics.com,(temporary)allow all this page,or (i "personally" think/can't remember) allow scripts globally.however,now, surrogates will override ABE rules like:
# GOOGLE ANALYTICS
Site .google-analytics.com
Deny"

Now, if you have defined a surrogate script for google-analytics.com (there is also a built-in one), then when a site tries to download scripts from there, NoScript will jump in and provide a fake script, to try to keep the page happy. But if you don't define a surrogate, or the pattern used to apply it is out-of-date, that doesn't mean that the site gets the real script.

just so we are clear.you are "more" talking about:example.com/ga.js instead of just google-analytics.com embedded into example.com!?

in that case i use an ABE rules like this:
# ANNOYANCES BLOCK
Site .*/*ga.js*
Deny

my ABE rule would stop them both.
unfortunately now,surrogates will override ABE rules,& allow example.com/ga.js to run.
or WILL IT???

will something like:google-analytics.com/morebad.js now work???(doesn't matter if it's inside google-analytics.com/ga.js,
or example.com/ga.js)
where does "each surrogate end"???

what if example.com/ga.js is not the "real" Google Analytics,or it has inline script like:
<script>
function badstuff(p,A){var r;try{r=(top!=self&&typeof(top.document.location.toString())==="string")?top:self}catch(v) blah,
blah,blah...</script>
will the badstuff now work???(after all,it's not the same as badsite.com/blah/badstuff.js which would had been detected by ns like always.)
hell,it's not even example.com/badstuff.js

what if example.com/ga.js "is a real," copy of Google Analytics,but has inline script like:
<script>
function badstuff(p,A){var r;try{r=(top!=self&&typeof(top.document.location.toString())==="string")?top:self}catch(v) blah,
blah,blah...</script>
will the badstuff now work,because the surrogates will now override my ABE rule???

damn,all this garbage gives me a headache!!!
WHY WOULD GIORGIO OVERRIDE ABE???NOTHING SHOULD OVERRIDE ABE BUT HOST!

Posted: **Tue Jun 03, 2014 4:03 am**

nobody0 wrote:the surrogates only work when you (temporary)allow ex:google-analytics.com,(temporary)allow all this page,or (i "personally" think/can't remember) allow scripts globally.

No, surrogates are not used when you allow the site. They are used when you block the site. The whole point of them is so that you can leave GA (and others) blocked - and sites will still work anyway.

however,now, surrogates will override ABE rules like:
# GOOGLE ANALYTICS
Site .google-analytics.com
Deny"

Why are you blocking GA using ABE? Just block it using the regular script-blocking.

But if you do block it with ABE, then the surrogate looks like this:

Code: Select all

(function(){var _0=function()_0,_u=function(){};_0.__noSuchMethod__=_0;('ga'in window)||(ga=_u);with(window)urchinTracker=_u,_gaq={__noSuchMethod__:_0,push:function(f){if(typeof f=='function')f();else if(f&&f.shift&&f[0]in this)this[f.shift()].apply(this,f)},_link:function(h){if(h)location.href=h},_linkByPost:function(f){if(f&&f.submit)f.submit();return true},_getLinkerUrl:function(u){return u},_trackEvent:_0},_gat={__noSuchMethod__:function(){return _gaq}}})()

which does nothing except give the page a blank, empty object. All it can possibly achieve is to prevent JavaScript errors. Why are you worried about it running?

just so we are clear.you are "more" talking about:example.com/ga.js instead of just google-analytics.com embedded into example.com!?

I was just using Google Analytics as an example. However, the surrogate is defined for *.google-analytics.com, not */ga.js

unfortunately now,surrogates will override ABE rules,& allow example.com/ga.js to run.
or WILL IT???

No. There is no surrogate for */ga.js.

But if there were, then it would look similar to what I posted above. It would do nothing except try to prevent JavaScript errors. It would certainly not download anything blocked by ABE.

will something like:google-analytics.com/morebad.js now work???(doesn't matter if it's inside google-analytics.com/ga.js,
or example.com/ga.js)

No, if google-analytics.com is blocked, either by the regular script blocking or by ABE, then it is blocked. (If it's not blocked, then surrogates aren't relevant, are they?)

where does "each surrogate end"???

I don't understand this question.

what if example.com/ga.js is not the "real" Google Analytics,or it has inline script

Totally irrelevant. Your ABE rule will mean it never even gets downloaded.

WHY WOULD GIORGIO OVERRIDE ABE???NOTHING SHOULD OVERRIDE ABE BUT HOST!

It's not an override. ABE is still working perfectly. He is generously providing a fake script that can *sometimes* fix broken pages. Without any side effects. That's all.

Posted: **Tue Jun 03, 2014 4:13 am**

I'm having trouble finding a suitable analogy, but perhaps this one can help.

Imagine that the sun is going to explode and consume the world, so we launch a spaceship containing some carefully-selected men and women to colonise a distant planet.

Now, it's possible that they'll get melancholy, homesick, etc. So we decide to provide the spaceship with a holographic model of the world, so that they can remember what it was like and teach their children about it.

Now, if it turns out that this model missed out some important details - maybe it made North America too big, and swapped the islands of Japan around - does that mean that the spaceship is going to be sucked back home and tossed into the sun?

Of course not. The spaceship is away, and Earth is gone. Nothing has changed in that department. The hologram is just to keep the colonists happy. If it doesn't work, the worst-case scenario is unhappy colonists, not flaming death.

Surrogates are like that. The evil/undesirable site is blocked. It's been tossed into the bit-bucket. Nothing is downloaded from it. Surrogates are an illusion to keep the page happy, but if the illusion doesn't work, the worst you get is unhappy page.

Posted: **Mon Jun 09, 2014 1:59 pm**

hello Thrawn.
i am very,very sorry for such a late reply! i had been extremely busy.
this is my 6th attempt trying to finish my replies.

nobody0 wrote:the surrogates only work when you (temporary)allow ex:google-analytics.com,(temporary)allow all this page,or (i "personally" think/can't remember) allow scripts globally.

No, surrogates are not used when you allow the site. They are used when you block the site. The whole point of them is so that you can leave GA (and others) blocked - and sites will still work anyway.

that's a contradiction in it self.if i block google-analytics.com.(through untrusted,or ABE.)
then,i intentionally want the page to be broken.
do you see my point!???

however,now, surrogates will override ABE rules like:
# GOOGLE ANALYTICS
Site .google-analytics.com
Deny"

Why are you blocking GA using ABE? Just block it using the regular script-blocking.

actually,i don't have an ABE rule like that.it was just an example.

But if you do block it with ABE, then the surrogate looks like this:
Code: Select all
(function(){var _0=function()_0,_u=function(){};_0.__noSuchMethod__=_0;('ga'in window)||(ga=_u);with(window)urchinTracker=_u,_gaq={__noSuchMethod__:_0,push:function(f){if(typeof f=='function')f();else if(f&&f.shift&&f[0]in this)this[f.shift()].apply(this,f)},_link:function(h){if(h)location.href=h},_linkByPost:function(f){if(f&&f.submit)f.submit();return true},_getLinkerUrl:function(u){return u},_trackEvent:_0},_gat={__noSuchMethod__:function(){return _gaq}}})()

which does nothing except give the page a blank, empty object. All it can possibly achieve is to prevent JavaScript errors. Why are you worried about it running?

see,this is where you contradict yourself again.it gets very vague.

lets get this straight once,& for all:
example1:with js off by default,i go to example.com.which has google-analytics.com(untrusted.)
the GA surrogate does nothing.(it only fixes js errors.)correct:YES,or NO???

example2:with js off by default,i go to example.com.which has google-analytics.com(blocked through ABE.)
# GOOGLE ANALYTICS
Site .google-analytics.com
Deny
the GA surrogate does nothing.(it only fixes js errors.)correct:YES,or NO???

example3:i go to example.com,& allow it's js to run.with google-analytics.com(untrusted.)
the GA surrogate does nothing.(it only fixes js errors.)correct:YES,or NO???

example4:i go to example.com,& allow it's js to run.with google-analytics.com(blocked through ABE.)
# GOOGLE ANALYTICS
Site .google-analytics.com
Deny
the GA surrogate does nothing.(it only fixes js errors.)correct:YES,or NO???

example5:i go to example.com,& allow it's js to run.now,i (temporary)allow google-analytics.com to run.
the GA surrogate stops the google-analytics.com from running. as if google-analytics.com was never there.
then,GA surrogate sanitizes GA's data collection.after that,the GA surrogate activates for example:example.com's log in box,report a bug box,a game,or a video that the actual google-analytics.com was supposed to activate.
...AND if necessary,the GA surrogate fixes js errors.
correct:YES,or NO???

just so we are clear.you are "more" talking about:example.com/ga.js instead of just google-analytics.com embedded into example.com!?

I was just using Google Analytics as an example. However, the surrogate is defined for *.google-analytics.com, not */ga.js

like i said,"i intentionally didn't want to know what "exactly" the surrogates do."
now that i'm forced to know...siiigghhh,thank you for clarifying.

unfortunately now,surrogates will override ABE rules,& allow example.com/ga.js to run.
or WILL IT???

No. There is no surrogate for */ga.js.

But if there were, then it would look similar to what I posted above. It would do nothing except try to prevent JavaScript errors. It would certainly not download anything blocked by ABE.

i knew there was no "specific" surrogate for example.com/ga.js.
the question was:does the GA surrogate recognizes the example.com/ga.js exactly the same as google-analytics.com/ga.js,& then,overrides it!?
as you said above,"NO!"
good to know that the GA surrogate ignores the example.com/ga.js!

will something like:google-analytics.com/morebad.js now work???(doesn't matter if it's inside google-analytics.com/ga.js,or example.com/ga.js)

No, if google-analytics.com is blocked, either by the regular script blocking or by ABE, then it is blocked. (If it's not blocked, then surrogates aren't relevant, are they?)

i'm okay with the 1st part,but as far as 2nd...huh,what?
just so we are clear:you are referring to example.com/ga.js!?so,then the GA surrogate does nothing,because the GA surrogate doesn't recognize the example.com/ga.js exactly the same as google-analytics.com/ga.js.(as you said above.)
so,the surrogates aren't relevant then!???
correct:YES,or NO???

where does "each surrogate end"???

I don't understand this question.

that was a question/comment about the "detailed" abilities of different surrogates.(which i didn't want to know,but was forced to find out.)
such as:can the surrogate recognize example.com/ga.js.(it can't.) activate google-analytics.com/morebad.js,because the google-analytics.com/ga.js was supposed to.(it can't.)
i wasn't sure about these.
however,i knew that the surrogates can activate different modules inside the websites.(such as:log in/report a bug boxes,
games,videos,sanitize data collection,& give data-less results to google when you search for something.)

what if example.com/ga.js is not the "real" Google Analytics,or it has inline script

Totally irrelevant. Your ABE rule will mean it never even gets downloaded.

irrelevant...uummmn NO!
how many people do you know that got an ABE rule like this???
# ANNOYANCES BLOCK
Site .*/*ga.js*
Deny

if i didn't have it,i would be exposed to the bad stuff inside example.com/ga.js.
then again,you take a risk like that everytime you allow js from any website.(lets hope ClearClick catches something if applicable.)
so,business as usual.

WHY WOULD GIORGIO OVERRIDE ABE???NOTHING SHOULD OVERRIDE ABE BUT HOST!

It's not an override. ABE is still working perfectly. He is generously providing a fake script that can *sometimes* fix broken pages. Without any side effects. That's all.

like i said,"if Giorgio said:the surrogates "only,only,only fix js errors," & don't activate anything until the user for example:(temporary)allows google-analytics.com." (pretty much business as usual.)
that would be great,but he never clearly said that!?did he???
see the problem!?

as far as your second reply...lol,its an interesting/good analogy,but not really necessary.
i knew 98% of this before my first post.like i said,"it's just the way Giorgio phrased things sounded like the surrogates will work no matter what."
it just threw me for a loop,that's all.

after all,surrogates=replacement/substitute.
pure,& simple.(i knew that.)

Posted: **Mon Jun 09, 2014 3:36 pm**

How can you be so concerned on security and still be running on Firefox 11 ? :p
This thing is completely compromised, albeit less so thanks to NoScript.

Posted: **Mon Jun 09, 2014 11:30 pm**

nobody0 wrote:if i block google-analytics.com.(through untrusted,or ABE.)
then,i intentionally want the page to be broken.
do you see my point!???

No. I have no idea why you actually *want* the page to be broken? And by 'broken' I mean "ordinary page functions, like clicking buttons, do not work". If surrogates can safely fix that, why do you want it broken?

lets get this straight once,& for all:
example1:with js off by default,i go to example.com.which has google-analytics.com(untrusted.)
the GA surrogate does nothing.(it only fixes js errors.)correct:YES,or NO???

Yes - assuming that by 'js off by default' you mean "JavaScript globally switched off, external to NoScript".

example2:with js off by default,i go to example.com.which has google-analytics.com(blocked through ABE.)
# GOOGLE ANALYTICS
Site .google-analytics.com
Deny
the GA surrogate does nothing.(it only fixes js errors.)correct:YES,or NO???

As above.

example3:i go to example.com,& allow it's js to run.with google-analytics.com(untrusted.)
the GA surrogate does nothing.(it only fixes js errors.)correct:YES,or NO???

The surrogate will run, which (we hope) will fix JS errors by providing blank objects to the page, and that's all.

example4:i go to example.com,& allow it's js to run.with google-analytics.com(blocked through ABE.)
# GOOGLE ANALYTICS
Site .google-analytics.com
Deny
the GA surrogate does nothing.(it only fixes js errors.)correct:YES,or NO???

As above.

example5:i go to example.com,& allow it's js to run.now,i (temporary)allow google-analytics.com to run.
the GA surrogate stops the google-analytics.com from running. as if google-analytics.com was never there.
then,GA surrogate sanitizes GA's data collection.after that,the GA surrogate activates for example:example.com's log in box,report a bug box,a game,or a video that the actual google-analytics.com was supposed to activate.
...AND if necessary,the GA surrogate fixes js errors.
correct:YES,or NO???

Absolutely NO. If you allow GA, then the surrogate does not run, the real script does. The surrogate is not about sanitising, overriding, interfering, or anything of the kind. It only operates when the real script was blocked.

good to know that the GA surrogate ignores the example.com/ga.js!

All that achieves is to break example.com - and I don't understand why you want to do that.

just so we are clear:you are referring to example.com/ga.js!?so,then the GA surrogate does nothing,because the GA surrogate doesn't recognize the example.com/ga.js exactly the same as google-analytics.com/ga.js.(as you said above.)
so,the surrogates aren't relevant then!???
correct:YES,or NO???

If there is no surrogate defined for example.com/ga.js, then surrogates have no relevance.

however,i knew that the surrogates can activate different modules inside the websites.(such as:log in/report a bug boxes,
games,videos,sanitize data collection,& give data-less results to google when you search for something.)

I think you still misunderstand. Surrogates do not 'activate' things. They do not call external scripts.

if i didn't have it,i would be exposed to the bad stuff inside example.com/ga.js.
then again,you take a risk like that everytime you allow js from any website.(lets hope ClearClick catches something if applicable.)
so,business as usual.

Yep. Business as usual.

like i said,"if Giorgio said:the surrogates "only,only,only fix js errors," & don't activate anything until the user for example:(temporary)allows google-analytics.com." (pretty much business as usual.)
that would be great,but he never clearly said that!?did he???
see the problem!?

If you want to use the surrogate, then DO NOT ALLOW GOOGLE-ANALYTICS.COM. The surrogate should make it unnecessary.

Is that clearer?

as far as your second reply...lol,its an interesting/good analogy,but not really necessary.
i knew 98% of this before my first post.like i said,"it's just the way Giorgio phrased things sounded like the surrogates will work no matter what."
it just threw me for a loop,that's all.

after all,surrogates=replacement/substitute.
pure,& simple.(i knew that.)

But I think you misunderstand the mechanism.

The surrogate is not jumping in and sanitising the real script.
It is filling the void left behind by the real script being blocked.

Posted: **Tue Jun 10, 2014 12:08 am**

I don't think he really wants the site to be broken, otherwise he wouldn't allow Javascript on that site. (in a scenario where the surrogate is an untrusted third party such as GA)

Another way to put it:

example.com requires javascript to function correctly. Unfortunately, the developers made it so that to work properly, their code requires the existence of functions or return values that belong to the Google Analytics script.

If GA is forbidden, there will be no such functions and return values, so example.com, which you allowed to use Javascript, will not be able to use said javascript as expected. A surrogate will just fake the existence of those functions, and return fake values, to make example.com happy and able to go on with its Javascript.

A surrogate poses absolutely no security or privacy risk whatsoever. You allowed JS on example.com, and it tries to ensure that this JavaScript will run as expected by providing it empty, meaningless shells.

Surrogates are pretty cool.

If you want to actually do something that will benefit your security, how about updating Firefox ?

InformAction Forums

Forced Surrogates

Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates

Re: Forced Surrogates