InformAction Forums

access2godzilla wrote: 1. You can deny a javascript file from loading using the ^$script suffix, but what happens when the script is embedded within the page?

2. Adblock Plus has considerably slower performancewith regexes (although I don't know why – regexes should be faster since it's parsed by the browser) and with longer lists.

Thrawn wrote: I'm not sure what relevance this has to ABE? It doesn't involve a HTTP request, so ABE isn't involved.

Have you done any benchmarks of ABP against ABE with regexes and long lists? If so, and if ABE is much faster, then please contact the ABP people and suggest that they review the ABE code to get some ideas.

access2godzilla wrote:

Thrawn wrote: I'm not sure what relevance this has to ABE? It doesn't involve a HTTP request, so ABE isn't involved.

Assuming scripts globally allowed:
So this is to say that I can't write an ABE rule to block an embedded script running on example.com (when I'm on example.com)?

Have you done any benchmarks of ABP against ABE with regexes and long lists? If so, and if ABE is much faster, then please contact the ABP people and suggest that they review the ABE code to get some ideas.

Logically regexes should be faster (it's being parsed by FF itself), but ABP people and filter list maintainers mention everywhere that regex is slow so don't use it . Requesting Wladimir & Co. is useless - I'll not go into the reasons, but happily state them if anyone asks.

I will repeat the statement I made in my previous post, though:
Making a blocklist is only one of the purposes that came to my mind. Obviously there could be other varied purposes - a company may want to push a ruleset for their company's computers for protection, someone may make a ruleset that helps enforce privacy - and that would require automatic updating.

Thrawn wrote: Well, I suppose you could try using the Sandbox keyword...but if you mistrust the site so much that you want to block scripts included inline in the page, then why are you whitelisting it? Is there a particular site where you want to do this? You might get further with surrogate scripts.

That, on the other hand, already exists (in a limited form)

• Busy - Giorgio doesn't have to do it immediately. He can take his own time to implement it.
• Breaks spec/standard - commented update command (e.g #__updateURI <url> , #__expires <time> etc.)
• Security issue - The user will have to be sufficiently warned in some dialog while installing the ruleset.

access2godzilla wrote: BTW, it is not a question of whitelisting. My intention is to help newer users to run in scripts globally allowed mode but without the risk of getting infected by a malicious webpage, and I want to build a blocklist that can be updated automatically.

BTW, I don't know why this idea is being refused,

Thrawn wrote:Adblock Plus has an anti-malware subscription list, which is probably the kind of thing you're after.

• ABP provide an equivalent of "Sandbox" of ABE due to limitations in ABP (but the limitation is practical since it's an ad blocker).
• The list is not optimised, with listing of all known malicious domains (with a large number of inactive ones) rather than a listing of URL patterns of exploit kits. (No use talking to the list maintainers about this.)
• Even optimising the whole list into a regex is useless, because ABP gives priority to wildcards rather than support only regexes. (And processing a regex should be much faster, since FF does it natively by using regex.h or similar)

It might happen eventually, but the key problem is trust. Who do you trust, who do you trust to make decisions about who to trust, who do you hold accountable if trust is broken, etc.

[Giorgio's] not keen - or available - to take full responsibility for vetting a whitelist, or blacklist, and without a central provider[.]

In the case of ABE rules, there are extra complications, because your rules have to match your usage of the site, and everyone's usage may be different[.]

So probably a list like the abovementioned thread, suggesting rules but allowing you to pick and choose, is the best compromise.

access2godzilla wrote: ABP provide an equivalent of "Sandbox" of ABE due to limitations in ABP (but the limitation is practical since it's an ad blocker).

The list is not optimised, with listing of all known malicious domains (with a large number of inactive ones) rather than a listing of URL patterns of exploit kits. (No use talking to the list maintainers about this.)

Even optimising the whole list into a regex is useless, because ABP gives priority to wildcards rather than support only regexes. (And processing a regex should be much faster, since FF does it natively by using regex.h or similar)

I'm asking for an update mechanism only. The issue of trust is a seperate one. If an user installs an ABE that does the wrong things, they are at fault. All NS can do is show a warning about bad things happening if the wrong ruleset is installed.

In comparison to browser extensions/software, though, the ABE cannot be used to facilitate something more malicious than what would have been possible without NS not being installed, so I don't see any support issues, nor any issues of "trust".

Why should Giorgio have to take any responsibility for an ABE? If I'm the one maintaining the list, I'll take the responsibilty, and I'll be the central provider.

Anyway, it would be quite nice to have the auto update. If you can ask Giorgio to consider the update mechanism (not the rulesets, I have never asked for a ruleset), I'll be grateful.

Thrawn wrote:I was under the impression that ABP is able to completely block cross-site requests. That's as much as ABE would do.

Well, I suppose you could try using the Sandbox keyword...

That would be one nasty regex...worse than Giorgio's tracking-script regex.

Yes, that would work, but since it would only affect a tiny percentage of NoScript users, it hasn't pushed this up the priority list. If you would really like to maintain a list for all NS users, feel free to talk to Giorgio about doing so.

I hope this doesn't bother you, but my personal leaning is that ABE rules are never going to be so universally applicable that a subscription is the right model for them. I think the best that can be done is to provide a good interface, like the one in RequestPolicy.

access2godzilla wrote:

Thrawn wrote:I was under the impression that ABP is able to completely block cross-site requests. That's as much as ABE would do.

You seem to have contradicted your own self. http://forums.informaction.com/viewtopi ... 607#p51255:

Well, I suppose you could try using the Sandbox keyword...

The maintainability of the rulesets is the maintainers' problem, and that isn't an excuse for not implementing the auto-update.

Yes, that would work, but since it would only affect a tiny percentage of NoScript users, it hasn't pushed this up the priority list. If you would really like to maintain a list for all NS users, feel free to talk to Giorgio about doing so.

I'd like to maintain one, but that requires the auto-update mechanism, which isn't there (and which I'm requesting in this thread)!

I hope this doesn't bother you, but my personal leaning is that ABE rules are never going to be so universally applicable that a subscription is the right model for them. I think the best that can be done is to provide a good interface, like the one in RequestPolicy.

If you are talking about my usage case (blocking malicious domains), then a subscription model is perfect. New users can have a very decent amount of protection this way: scripts are globally allowed, but malicious domains are blocked.

For other usage cases, it is often quite good to have a subscription model. Sure there might be some bloat, but it makes users comfortable.

Thrawn wrote:Oh, did you mean a Sandbox equivalent for inline content? I was talking about cross-site requests, where either ABE or ABP can completely block requests.
Actually element hiding is not really similar to Sandbox, it just makes things invisible. Sandbox actually disables scripts.

Site (.*(?:\/.*\/(?:([a-z]{2,}[_-])+.*|\.[a-z]+)|:8080\/forum\/links\/[a-z]+)\.php)
Sandbox

However, back on topic: the maintainability of the rulesets would, I think, make this feature less popular with potential maintainers, which makes it lower-priority.

If you're offering to maintain a list for all NoScript users, then you could send Giorgio a private message to see whether that would bump the priority of this feature.

But there are already hosts files, ABP anti-malware subscription, etc...ABE can do the same job, but was not really designed for it. Why not use the right tool for the job?

Yeah, but ABE is not really a tool to use without understanding what you're doing, especially without a graphical interface, so it can be hard to tell when something is being blocked, and what it is.