barbaz wrote:For example, I don't want my mixed content rule whitelisting via its (unfortunately necessary) Accept INCLUSION(OBJSUB) clause, something that site-specific protections would catch. The only way to close that gap is a custom ruleset.
Perhaps it should go in SYSTEM, then?
Thrawn wrote:You'll actually get a performance hit by using multiple rulesets, because even if a request gets filtered in one ruleset, it must still pass through all the others (unless it was simply blocked).
My rulesets are all pretty short. How bad is this performance hit (as in, how much slower are multiple rulesets at allowing a request than one long ruleset)?
[/quote]
Not a lot. Most requests (the ones that don't match anything) will pass through every rule anyway. I was just pointing it out.
Also, are you suggesting a method that could combine Anonymize and Sandbox?
I believe that that is possible, yes, by putting the same rule in two rulesets, with one anonymizing and one sandboxing.
These are mainly to filter entire protocols, like:
Code: Select all
# Do not let local files fetch remote objects
Site ^https?:
Deny INCLUSION(OBJ) from file:
Then they're good candidates for SYSTEM.
And wouldn't messing with SYSTEM mean that if Giorgio pushes an update to that ruleset, I wouldn't get it?
Technically yes, but that happens almost never. And it wouldn't happen without clear notice, discussion, etc.
Maybe I can merge my site-specific rules to the bottom of USER, since they don't match anything else there... I'll have to think about that one, but I don't think there is any way I can avoid custom rulesets altogether.
Well, it's up to you - and I'm glad that someone is finding so much use for ABE!
In most cases, I think you'll find that the two rulesets are enough. Anything designed to protect one site - eg blocking cross-site requests to your bank - belongs in USER, while more general protections - like the built-in rule, or denying inclusions from local files - goes in SYSTEM.
But if you really find that custom rulesets work better for you, then by all means use them. I think, however, that for the general NoScript populace, having a GUI for them would bring more confusion than benefits.
[quote="barbaz"]For example, I don't want my mixed content rule whitelisting via its (unfortunately necessary) Accept INCLUSION(OBJSUB) clause, something that site-specific protections would catch. The only way to close that gap is a custom ruleset.[/quote]
Perhaps it should go in SYSTEM, then?
[quote="Thrawn"]You'll actually get a performance hit by using multiple rulesets, because even if a request gets filtered in one ruleset, it must still pass through all the others (unless it was simply blocked).[/quote]
My rulesets are all pretty short. How bad is this performance hit (as in, how much slower are multiple rulesets at allowing a request than one long ruleset)?
[/quote]
Not a lot. Most requests (the ones that don't match anything) will pass through every rule anyway. I was just pointing it out.
[quote]
Also, are you suggesting a method that could combine Anonymize and Sandbox?
[/quote]
I believe that that is possible, yes, by putting the same rule in two rulesets, with one anonymizing and one sandboxing.
[quote]
These are mainly to filter entire protocols, like:
[code]# Do not let local files fetch remote objects
Site ^https?:
Deny INCLUSION(OBJ) from file:[/code]
[/quote]
Then they're good candidates for SYSTEM.
[quote]And wouldn't messing with SYSTEM mean that if Giorgio pushes an update to that ruleset, I wouldn't get it?[/quote]
Technically yes, but that happens almost never. And it wouldn't happen without clear notice, discussion, etc.
[quote]
Maybe I can merge my site-specific rules to the bottom of USER, since they don't match anything else there... I'll have to think about that one, but I don't think there is any way I can avoid custom rulesets altogether.[/quote]
Well, it's up to you - and I'm glad that someone is finding so much use for ABE!
In most cases, I think you'll find that the two rulesets are enough. Anything designed to protect one site - eg blocking cross-site requests to your bank - belongs in USER, while more general protections - like the built-in rule, or denying inclusions from local files - goes in SYSTEM.
But if you really find that custom rulesets work better for you, then by all means use them. I think, however, that for the general NoScript populace, having a GUI for them would bring more confusion than benefits.