by Guest » Sun Jun 10, 2012 4:41 pm
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.
Thank you Thrawn. Your message was most helpful and brought some light in the mess over here.
[quote] 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.[/quote]
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.
[quote]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.[/quote]
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.
[quote] 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).[/quote]
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.
