RFE: GUI for managing custom ABE rulesets

Post a reply

Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: RFE: GUI for managing custom ABE rulesets

Re: RFE: GUI for managing custom ABE rulesets

by barbaz » Sun Jan 12, 2014 3:34 am

forecehh wrote:this rule just harass me

Code: Select all

Site ALL
Accept from SELF++
Deny
Yeah, it would. Now I see why you want a toolbar button.
However, that sort of thing isn't really ABE's main purpose, and coupling that with handling arbitrary custom rulesets I doubt that Giorgio will actually implement your suggestion. That being said, given ABE's flexibility it's fairly easy to make an extra addon that provides a toolbar button to enable/disable a specific single ABE ruleset.

Re: RFE: GUI for managing custom ABE rulesets

by forecehh » Sun Jan 12, 2014 1:00 am

You already can create custom rulesets; it's just not exposed in the GUI. Thus this RFE.
Example use case (where the buttons in the ABE Options panel aren't good enough)?
I've used ABE fairly extensively and have *never* needed to disable a ruleset
i know that create noscript.ABE.rulesets.myrulesets
and when disabled put name on that noscript.ABE.disabledRulesetNames
but always faster way better:)
maybe you are more Experienced.

this rule just harass me

Code: Select all

Site ALL
Accept from SELF++
Deny
anyway this is just suggestion

Re: RFE: GUI for managing custom ABE rulesets

by barbaz » Sun Jan 12, 2014 12:16 am

forecehh wrote:if you not providing create custom rulesets
You already can create custom rulesets; it's just not exposed in the GUI. Thus this RFE.
forecehh wrote:toolbar button to enable and disable rulesets
that like "Revoke Temporarily permissions" and "Temporarily allow all this page" button are available when open customize... window
so that's save time
Example use case (where the buttons in the ABE Options panel aren't good enough)?
I've used ABE fairly extensively and have *never* needed to disable a ruleset...

Re: RFE: GUI for managing custom ABE rulesets

by forecehh » Sat Jan 11, 2014 10:59 pm

Hi,

i like that user able to create new rulesets and able to enable and disable that easily with button on toolbar
if you not providing create custom rulesets at least add toolbar button to enable and disable rulesets
that like "Revoke Temporarily permissions" and "Temporarily allow all this page" button are available when open customize... window
so that's save time

thank you

Re: RFE: GUI for managing custom ABE rulesets

by Thrawn » Thu Dec 12, 2013 10:24 am

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.

Re: RFE: GUI for managing custom ABE rulesets

by barbaz » Thu Dec 12, 2013 3:24 am

Thrawn wrote:Ensuring that rules will run (and potentially block requests) even after requests have matched other rules. Eg you probably don't want site-specific rules to override the protection of the default LOCAL rule.
This is what I'm using them for. 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.
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)?
Also, are you suggesting a method that could combine Anonymize and Sandbox?
Thrawn wrote:I would put the NAT pinning rule in SYSTEM, along with the simple blocks (are these for adblocking?), then put mixed-content blocking at the top of USER and site-specific rules at the bottom. Unless you want site-specific rules to override the mixed-content blocking.
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:
And wouldn't messing with SYSTEM mean that if Giorgio pushes an update to that ruleset, I wouldn't get it?

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.

Re: RFE: GUI for managing custom ABE rulesets

by Thrawn » Thu Dec 12, 2013 2:35 am

barbaz wrote:Well, I currently have 4 custom rulesets, 3 of which actually contain rules (the other one is reserved for testing). I've put the most restrictive rules, such as the NAT Pinning Rule and other things with only Deny or Anonymize, into USER, created another ruleset for global mixed content blocking, and each site-specific protection also gets its own ruleset. The idea is to let certain rules act independently from each other, so that ABE can prioritize based on the situation rather than by order in a ruleset. It's also easier to look at this way.

Is this really that much an edge case, or am I misunderstanding something about how ABE works?
I don't think that putting them in separate rulesets is really all that helpful...

As I see it, custom rulesets have two uses:
  • Ensuring that rules will run (and potentially block requests) even after requests have matched other rules. Eg you probably don't want site-specific rules to override the protection of the default LOCAL rule.
  • In the case of SABER, allowing a special set of rules to be automatically refreshed, overwritten, or deleted, by an automated process, without touching any other rules.
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).

I would put the NAT pinning rule in SYSTEM, along with the simple blocks (are these for adblocking?), then put mixed-content blocking at the top of USER and site-specific rules at the bottom. Unless you want site-specific rules to override the mixed-content blocking.

Re: RFE: GUI for managing custom ABE rulesets

by barbaz » Wed Dec 11, 2013 2:28 pm

Well, I currently have 4 custom rulesets, 3 of which actually contain rules (the other one is reserved for testing). I've put the most restrictive rules, such as the NAT Pinning Rule and other things with only Deny or Anonymize, into USER, created another ruleset for global mixed content blocking, and each site-specific protection also gets its own ruleset. The idea is to let certain rules act independently from each other, so that ABE can prioritize based on the situation rather than by order in a ruleset. It's also easier to look at this way.

Is this really that much an edge case, or am I misunderstanding something about how ABE works?

Re: RFE: GUI for managing custom ABE rulesets

by Thrawn » Wed Dec 11, 2013 5:07 am

Er...why do you need a custom ruleset? Ordinarily the USER ruleset should be enough.

SABER uses a custom ruleset, but it's in the unusual position of providing a non-standard interface to ABE, with rules that shouldn't really interact/interfere with the regular ones.

RFE: GUI for managing custom ABE rulesets

by barbaz » Wed Dec 11, 2013 2:20 am

I apologize if this should have gone in NoScript Development forum, feel free to move it if needed.

Currently, in order to create a new ruleset, one must go to about:config and create a named preference (guessing what would be a valid ruleset name), give it a dummy value (I usually use "#"), then open the NoScript GUI to input the desired rules. And deleting a custom ruleset, I presume, requires going to about:config, resetting the preference, and restarting the browser. Would it be possible to simplify this procedure by adding buttons for these actions in the ABE GUI? Maybe Mac OS X style, with a + for add ruleset and a - for delete ruleset, to minimize used screen real estate and lessen the localization problem?

Top