InformAction Forums

nobody0 wrote: then,i allow example.com's js to run."I DON'T WANT THAT GA SURROGATE TO DO ANYTHING!!!"
ABSOLUTELY NOTHING!!! (OBVIOUSLY THIS SHOULD APPLY TO ALL OTHER SURROGATES!)
AM I MAKING MY SELF CLEAR?????

about:config > noscript.surrogate.enabled = false

On individual surrogate basis, just tamper either with the surrogate replacement or source preference values (set either to an empty string).

If you want to run a surrogate (of your own, of course: the built-in are meant as replacement) whenever a certain script actually run, either create a "before" or an "after" surrogate.

Quick Reference

I doubt Giorgio will implement a preference that makes surrogates work like they used to because it might be more work and more mess in the code than it looks from our point of view, and only very very few people would be interested in your use case.


So you need a satisfying workaround. Something worth trying:

- Add the prefix < to noscript.surrogate.ga.sources, this *should* make the Google Analytics NS surrogate run only if GA is script allowed

- Make sure it really does work this way. Note that GA will run as well because it is allowed to, something we'll deal with after we confirm < works.

- Add the following lines to your Windows hosts file: If you don't know how to do this, tons of guides can be found on the web. Note that you can use *.google-analytics.com in the hosts file, so if there are other google-analytics.com subdomains you have to enter them all. Your Firewall or router might give you a better control over the blocking process than the hosts file, but I only know you have Windows so I went with the simplest explanation.

- Make sure it still works as hoped: Now the GA surrogate should run only if GA is script allowed, and the real GA script should never be downloaded and thus should never run.

Oh, didn't notice Giorgio's post. Well it means at least the first part of the workaround should work as expected then

Just posting to correct a mistake in my previous post

Note that you can use *.google-analytics.com in the hosts file

I meant CAN'T

@nobody0: I realise you haven't registered, so I can't temporarily ban you, but if you use that kind of language again, expect your posts to be edited or removed.

finally,the man himself.
hello Giorgio.

1.)Giorgio,that's a very "interesting" way you had "altered" my last post!
yet,you did not sanitize this garbage of a thread,or changed that 1 word in my very 1st post like i had asked.
fine.

2.)yes,barbaz did mention this:in about:config:set noscript.surrogate.enabled to false,but that barely gets me half way there.
so,if you insist on this.then,how about putting:Turn OFF Surrogates somewhere in the ns menu with a checkbox in front of it!?
if the checkbox is unchecked,the value is set to true.(the way it is now by default.)
if the checkbox is checked.then,the value is set to false.

please,just bring the on/off "switch" for the surrogates to the surface instead of hiding it about:config. (i think it's a very reasonable feature request!wouldn't you say!?)

3.)for the record,like i said,"Giorgio you had done an excellent job with the surrogates!!!" (THANK YOU!!!)
so,altering any surrogates would serve no purpose.

again,for the gazillionth,& 11th time in a row:i have no problem with the way the surrogates work!!! I DO HOWEVER HAVE A PROBLEM WITH "WHEN" THE SURROGATES WORK/RUN!!!

which brings us back to my very 1st post...

4.)lets get something straight,"i'm NOT saying that:when you allow 1st party js to run the surrogates run automatically should be eliminated.

i'm saying,"PLEASE GIVE US THE ""CHOICE/OPTION"" TO HAVE THE SURROGATES RUN ""WHEN"" WE ALLOW 3RD. PARTY JS."

i don't think that giving us the choice "when" the surrogates run is an unreasonable feature request!wouldn't you say!?????

5.)Giorgio,please clarify:these couldn't possibly mean what i think they mean.could they???
+ UI support for cascadePermissions and restrictSubdocScripting
+ "NoScript Options|Advanced|Trusted|Cascade top document's permissions to 3rd party scripts" user-facing preference
+ "NoScript Options|Advanced|Untrusted|Block scripting in whitelisted subdocuments of non-whitelisted pages" user-facing preference

lol,rotfl...x [Surrogate] Fixed regression about a small change in sandbox principal management breaking some surrogates, including Google Analytics (does this mean the "automatic" surrogates are already breaking something?)


hello Pom.
yes,i had been using a full host list for the last 4,or 5 years.(which i had been updating monthly.)
...and NO! wildcards like (*) unfortunately do not work in host. (i think we all know that!?)
you must had been thinking of ABP.


hello Thrawn.
lets get something straight:
i did not curse at you,or anyone else!
i did however use the f word 100 times to express my frustration!
you can not blame me for that!now,can you!?

Thrawn,i want you to know:while your misguided effort has infuriated me.i do value your help!!!THANK YOU!!!

you honestly think i want to cause trouble here!? lol.
if it gets to bad.don't bother to ban me.i will walk away on my own.(i think that's obvious!)

nobody0 wrote: 1.)Giorgio,that's a very "interesting" way you had "altered" my last post!

Actually, that was me.

please,just bring the on/off "switch" for the surrogates to the surface instead of hiding it about:config. (i think it's a very reasonable feature request!wouldn't you say!?)

I don't think it's reasonable for Joe Average user. Disabling surrogates is not a normal thing to do. Leaving it in about:config makes much more sense to me.

i'm saying,"PLEASE GIVE US THE ""CHOICE/OPTION"" TO HAVE THE SURROGATES RUN ""WHEN"" WE ALLOW 3RD. PARTY JS."

That has never been possible. And by requesting it, you demonstrate that you still don't understand surrogates.

Surrogates do not run when the real third-party script is allowed. And they never have. They run when the real script is blocked.

Please re-read the blog post that I linked you to.

hello Pom.
yes,i had been using a full host list for the last 4,or 5 years.(which i had been updating monthly.)
...and NO! wildcards like (*) unfortunately do not work in host. (i think we all know that!?)
you must had been thinking of ABP.

No it was just a typo corrected in following post. * indeed doesn't work, you need a Firewall rule or something similar to get that instead of hosts.

Anyway I did give you a work around, were you able to test it ? The idea is to force surrogates to run *only* when scripts are allowed for the URL that is "surrogated". (with the prefix <, i.e. you don't need to modify the surrogate code itself)
Then just prevent the real script, in my example Google Analytics, from being downloaded. You can try with ABE or another Firefox extension, but if that doesn't work give a try to something external to the browser such as the hosts file, your firewall or your router.

If you want to make sure a surrogate is running or not, you can temporarily replace its code with an alert box Try it with the URL it is meant to "surrogate" whitelisted and then forbidden. If it worked it should only run when whitelisted, and the real script won't be there at all so it won't run either way.

Not sure it will work since it depends on how NoScript checks that a script hasn't been loaded and whether it forces a surrogate to run in that case even when it is prefixed with <. (< : only run if real script is whitelisted, runs right before real script)
Worth testing.

nobody0 wrote: please,just bring the on/off "switch" for the surrogates to the surface instead of hiding it about:config. (i think it's a very reasonable feature request!wouldn't you say!?)

Sorry, I disagree.
Surrogates are a very advanced feature, which is incredibly helpful for the vast majority of users, making some page usable without forcing you to allow undesirable scripts such Google Analytics, but which very few geeks (some of the coders among them) could be able to fully understand and customize.
Hence, the about:config barrier is perfectly acceptable for the intended audience, and helps both reducing UI clutter (there are already too many user facing options, unfortunately) and prevent the occasional self-styled power user from shooting himself in the foot.

nobody0 wrote:"PLEASE GIVE US THE ""CHOICE/OPTION"" TO HAVE THE SURROGATES RUN ""WHEN"" WE ALLOW 3RD. PARTY JS."[/b]

You've got it.
If you minded reading the Surrogate Quick Reference guide I already linked in my previous post, you'd know you can fully customize when surrogates run: before page loads, on page load, before a script is executed, after a script is executed, or when a script is blocked. It's up to you.
Of course, a surrogate which has been designed to replace a certain script will do no good or even break stuff if you change it to run before or after the script itself runs.

nobody0 wrote: lol,rotfl...x [Surrogate] Fixed regression about a small change in sandbox principal management breaking some surrogates, including Google Analytics (does this mean the "automatic" surrogates are already breaking something?)

Nope, it means a specific recent NoScript version wasn't able to run some surrogates correctly, hence some page got broken because of the lack of surrogates.

hello Thrawn.

nobody0 wrote:1.)Giorgio,that's a very "interesting" way you had "altered" my last post!

Actually, that was me.

HA!
while i find it a little hard to believe.all i can say is:you should had done the same with the rest of this "garbage" of a thread like i had asked you repeatedly.


well,it looks like you are wright.Giorgio doesn't care about the convenience of either of the feature requests.
i'm "glad" you,& me had "spent" so much time on this.
if only Giorgio had said NO on page 1 like he was supposed to,or told you/another mod directly to say NO.this whole ugly mess could had been avoided!
something to think about next time someone else makes a feature request.


again,you are off topic...
so,i'm going to ignore the rest of what you had said,because you obviously never understood 1 word i had said,or will understand.

anyway...Thrawn,despite your misguided effort.THANK YOU very much for your help,& GOOD BYE.


hello Pom.

...host,& (*)...

gotcha,that was just a typo.

...prefixes...

to be honest with you,i had completely forgot about the prefixes,because no one uses them.
i was going to test them on saturday,or sunday,& then say something.unfortunately i couldn't find the time.
however,since Giorgio gave that link.let's hope it works perfectly.
personally,i think it's a bad way of doing this/getting the desired effect!not to mention there's no easy way of testing this/seeing that the surrogates are running properly. (oh well.)
i will try the alert box:I ran! again,THANK YOU!!!


Pom,all i can say is:i wish you had mentioned the prefixes on page 1,& this "garbage" of a thread could had been avoided.
THANK YOU very much for your help,& GOOD BYE.


hello Giorgio.

nobody0 wrote:
please,just bring the on/off "switch" for the surrogates to the surface instead of hiding it about:config. (i think it's a very reasonable feature request!wouldn't you say!?)

Sorry, I disagree...

ofcourse i disagree with you with you,but NO MEANS NO!
so,that's the END of that.

nobody0 wrote:"PLEASE GIVE US THE ""CHOICE/OPTION"" TO HAVE THE SURROGATES RUN ""WHEN"" WE ALLOW 3RD. PARTY JS."

You've got it.
If you minded reading the Surrogate Quick Reference guide I already linked in my previous post, you'd know you can fully customize when surrogates run: before page loads, on page load, before a script is executed, after a script is executed, or when a script is blocked. It's up to you.

like i said to Pom:
i was going to test them on saturday,or sunday,& then say something.unfortunately i couldn't find the time.
personally,i think it's a bad way of doing this/getting the desired effect!

Of course, a surrogate which has been designed to replace a certain script will do no good or even break stuff if you change it to run before or after the script itself runs.

which makes the prefixes pretty much useless!!!
hence,the feature request.
oh well.again,NO MEANS NO!
so,that's the END of that.

like i said to Thrawn,"if only Giorgio(you) had said NO on page 1 like he(you) was supposed to,or told you/another mod directly to say NO.this whole ugly mess could had been avoided! something to think about next time someone else makes a feature request."


Giorgio,you really should update that article!
while i got it.(i'm an average user.) i don't think below average users will understand where "exactly" to put the prefixes!?
you need to give a clear example!
there's no mention that the surrogates now bypass ABE,or untrusted. (i still say,"the surrogates should never bypass ABE!!!nothing should bypass ABE!!!)
also,the 2nd comment on the bottom of the page/article is spam.

nobody0 wrote:
lol,rotfl...x [Surrogate] Fixed regression about a small change in sandbox principal management breaking some surrogates, including Google Analytics (does this mean the "automatic" surrogates are already breaking something?)

Nope, it means a specific recent NoScript version wasn't able to run some surrogates correctly, hence some page got broken because of the lack of surrogates.

wright,the surrogates are not running properly,& breaking something/pages. (you can see how that would be funny to me!?)


seriously,Giorgio,please explain what do these mean:
+ UI support for cascadePermissions and restrictSubdocScripting
+ "NoScript Options|Advanced|Trusted|Cascade top document's permissions to 3rd party scripts" user-facing preference
+ "NoScript Options|Advanced|Untrusted|Block scripting in whitelisted subdocuments of non-whitelisted pages" user-facing preference

i don't understand why when we go to noscript.net/getit,& read the Development version description.we can't just click directly on the words of the description in the change log.(like the ones above.)
then,a page on hackademix.net opens with a detailed description.(please,1st "quick description" must be in basic english/non geek.)
followed by the usual/necessary geek speech.

sigh...why do i bother!?you just going to say no to this one as well.


Giorgio,please explain the changes above.THANK YOU very much for your time,& help!
GOD BYE.

Pom,all i can say is:i wish you had mentioned the prefixes on page 1,& this "garbage" of a thread could had been avoided.

It's been mentioned pretty early

The whole point of the discussion was to figure out what it was exactly you wanted to give you a workaround. First getting away from the technicalities usually helps for this to give a bird view of the wants. Then we can zoom in and propose solutions we wouldn't have thought of otherwise.

I don't think there's anything more to say that hasn't been said.