InformAction Forums

Guest wrote:I'm trying real hard to understand the order some addons are processed in Firefox, say the latest version. I'll give an example. And the rest of the initial letter is going to be below in case someone needs more details. Answers, links, anything that would shed some light. Or a better place to ask this.

NoScript has google-analytics on the Unsafe list. I've just read that Request Policy is working on version 1.0 which will have blacklists too. For the moment google-analytics is not allowed anyway by RP. But I also have AdBlock block what comes from that direction. How can I optimise this flow?

NoScript deliberately runs last, so that RequestPolicy and adblockers work the way people expect. This is configurable via the noscript.cp.last property in about:config; see http://forums.informaction.com/viewtopi ... 488#p36488.

NoScript is rather indiscriminate. I mean a site could have evil.js and menu.js on the same server. Either I enable both or I disable both.

That's because of Giorgio's definition of trusted. A trusted site is one that you can hold accountable. If that's the case, and they host evil.js, then sue them. If you can't hold them accountable, then either you go without menu.js, or you use another countermeasure for evil.js.

AdBlock seems more fine grained. I could just block evil*.* and my problems would fly away. Kidding. And Request Policy just blocks any other site I dislike.

Actually, if you really want fine-grained, then you want NoScript's ABE module. Full control over all requests; you can specify exactly which requests to allow, which ones should have authentication/cookies stripped, which ones should not be allowed to run active content on the target page, and which ones are just blocked, based on both the source and destination addresses. There's only one simple rule built in, aimed at protecting your LAN/router, but I'm trying to collect more, and I'm also seriously investigating making a RequestPolicy-style frontend for it (currently you have to write the rules using ABE's syntax - which is not so hard to learn, but is cumbersome for general-purpose blocking).

Thank you Thrawn. Your message was most helpful and brought some light in the mess over here.

NoScript deliberately runs last, so that RequestPolicy and adblockers work the way people expect. This is configurable via the noscript.cp.last property in about:config; see viewtopic.php?p=36488#p36488.

So it's up to the others how they handle the load order. I have noticed that I can get some sort of ordered list if I search in the about:config for the name of an installed extension. But what I have read changes the relevance of this order, because I might be back to just two extensions.

That's because of Giorgio's definition of trusted. A trusted site is one that you can hold accountable. If that's the case, and they host evil.js, then sue them. If you can't hold them accountable, then either you go without menu.js, or you use another countermeasure for evil.js.

And it does make a lot of sense. Because nothing, really nothing, can stop the host merge some of the evil.js into menu.js just as well. After all, website optimisation writings preach building up a large js file in the place of many smaller ones.

Actually, if you really want fine-grained, then you want NoScript's ABE module. Full control over all requests; you can specify exactly which requests to allow, which ones should have authentication/cookies stripped, which ones should not be allowed to run active content on the target page, and which ones are just blocked, based on both the source and destination addresses. There's only one simple rule built in, aimed at protecting your LAN/router, but I'm trying to collect more, and I'm also seriously investigating making a RequestPolicy-style frontend for it (currently you have to write the rules using ABE's syntax - which is not so hard to learn, but is cumbersome for general-purpose blocking).

Wow! I finished reading some more about ABE. And that would make RequestPolicy redundant. Only issue: you have to poke, guess than build up a list of rules. So much more powerful. So much more portable with NS config saved as a special bookmark. Yet so much tedious. RP makes things almost as simple as with the NS site allow/untrust. And the developers promise a 1.0 version at the same level of simplicity as NS with the introduction of blacklists.

Any chance on the horizon to have ABE just as easy? That would mean for those willing and able to train their own filter rules that Adblock Plus would be mostly redundant too.

From my experience with building sites: writing by hand is a sure way to break things, while using some (more or less complicated) menu system might lead to success from the first run. I already have a huge HOSTS file, all going to LOCALHOST. And I want it as clickable as posible: just block anything that relates to the likes of kissmetrics, quantserve, scorecard research, google analytics and so on. I would have liked to kill google*.com, but there are so many sites just binding information hosted on gstatic, google, googleusercontent and googleapis.

Most addons run as soon as they can hook their invoke and so they may not run in the same order every time. However, NoScript, as Thrawn said, by default always runs last to allow everyone to do their thing first and then take a look at the WHOLE picture and start doing its thing. This is allows any injections, modifications, resources and etc to load and let anything that is going to act on them to do it so it won't break and then takes the whole and compared with net results and makes its presence known and does the rest. Its the best way to ensure compatibility with others and playing nice as NS respects others but not all addon developers respect properly the work of their cohorts.

Guest wrote: Any chance on the horizon to have ABE just as easy? That would mean for those willing and able to train their own filter rules that Adblock Plus would be mostly redundant too.

As per my previous comment, I'm working on this using a modified version of the RequestPolicy interface. Still in design stages, but I'm keen to get it done.

As per my previous comment, I'm working on this using a modified version of the RequestPolicy interface. Still in design stages, but I'm keen to get it done.

That's wonderful! Any place where one can check for updates?

Guest wrote:

As per my previous comment, I'm working on this using a modified version of the RequestPolicy interface. Still in design stages, but I'm keen to get it done.

That's wonderful! Any place where one can check for updates?

Try http://forums.informaction.com/viewtopi ... =19&t=8059 - but be patient!