ABE order of rules regarding SYSTEM, USER, and site specific

[diablodale]

Checked 0.5 syntax docs and queried forum here. Question is...

What is the order that NoScript uses to check against SYSTEM, USER and site-specific rulesets?

The 0.5 syntax docs say that within a ruleset it goes top to bottom. However, what is the order of evaluation when you have rulesets in SYSTEM, USER, and site-specific? For example, if you have a rule that would match in all three, which one is applied?

[therube]

(Not an answer, but related, Can ABE allow sub-objects, too?)

[Giorgio Maone]

Order is the following:

1. SYSTEM
2. USER
3. WEB SUBSCRIPTION (when implemented)
4. site specific

Notice also that while a matching "Deny" rule stops all the processing (obviously), more permissive actions (e.g. "Accept") exit current ruleset but continue processing with lower priority rulesets.
So if you've got to add an "Accept" exception for a certain "Deny" rule, you need to put it higher in the same ruleset.

[diablodale]

Thank you. That's clear.

I have a scenerio that affected me today that I'd like to offer. http://www.eye.fi produces a SDHC card which has a tiny WiFi transceiver in it. It allows people to use this SDHC card in a camera and it will upload the pictures in near real time to their computer. Its really fun. One part of this solution is the Eye-Fi software on the computer hosts a server on localhost 127.0.0.1 on a specific port.

When customer wants to use the admin interface, they go to http://manager.eye.fi which then has code that calls to 127.0.0.1. Using the default ABE SYSTEM ruleset causes this to fail. Given your instructions above, I added one line to the SYSTEM ruleset:

Code: Select all

Site LOCAL
Accept from LOCAL
Accept ALL from *.eye.fi
Deny

The solutions works. My only concern is that there could be frequent user driven exceptions to the ruleset like this. It tends to make me think that such exceptions would be in the USER ruleset rather than altering the SYSTEM ruleset. For me and my simple mind, the SYSTEM ruleset is a global default widesweeping protection that would be overridden by user exceptions; segmenting those rules into the SYSTEM and USER rulesets respectively.

My intention is not to rethink your architecture. Rather, how is the given architecture described in a way that allows users to naturally understand how it works and to configure it? For example, in the future when a simple UI similar to NoScripts "allow" tray icon creates these exceptions...should it put them in the USER ruleset or the SYSTEM ruleset. Given the current default SYSTEM rule, it must alter that rule. Which seems odd to me.