Site must be allowed for ABE rules to work?

[GµårÐïåñ]

I like your idea and realize where you are coming from. If/when ABE reaches the point of separate product (which it nearly is right now already) then something like that in an exclusive interface for ABE could be doable and achievable, similar to the Adblock Plus and Element Hiding Tool that is technically separate but integrates to some extent with the main parent application, BUT the GUI for EHT is separate from ABP.

However, as it stands right now as part of the parent NS application, the complication, overhead, and additional interface complexity could make the product (I am pretty sure it will) burden the interface and complicate things for the users, especially the more novice ones who are barely comfortable with the current interface. However, I can see the benefit of and would recommend to Giorgio an experimental addition of an "optional" interface that can be invoked using a hidden about:config setting or a checkbox in the ABE panel of NS so that those who wish the added complexity, can have it invoked automatically when a decision is made, so that you can also create the ABE rules on the fly.

Giorgio, consider this as a RFE - This interface could take a lot of time and might not be high on his list but something that I have personally attempted to build as a separate "rule maker" and have first hand knowledge of the level of complexity that will factor into making an interface that walks people through. We had a deal that if I can make the interface work, especially in JS so that it can be more easily ported/integrated, that he would test and potentially put it into the application. I ran into some person obligations that kept me from finishing that, but have a working foundation for it. I can re-activate that and get busy on it. There are alot of fine grained control that can factor into a rule and its hard to make them available, even with an explanation, without confusing a huge group of people. Is it doable, well I like to believe anything is doable, but is it worth the time invested, only the developer can answer that.

[ilcercatorediinfo]

But can ABE allow a script for one site only and forbidding for all the others?
Maybe an example will make my question clearer.

Suppose you have apis.google.com (found clicking on the NoScript icon) and I want to have it enabled only on the "http://www.abcd.com" page.

If I write the rule:

# googleapis.com rule
Site .apis.google.com
Accept from .abcd.com
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)

what will NoScript behaviour be like?
Will it allow apis.google only on the abcd.com site or even on the others?
Is there a rule toallow it only for the abcd.com site?

Thank you

[GµårÐïåñ]

When you mention the SITE it limits the rule to those sites and when you mention the ACCEPT it will allow only from those sites. So by default the DENY would prevent or limit access by anyone else, but if you deny certain things, you may still allow regular access, just not the specific objects, inclusions and sub-documents that you have specified. If you want to categorically deny all else, then just do DENY at the end.

Looking at what you have specifically posted, you would allow abcd.com and apis.google.com in NoScript and the rule will make sure that only abcd.com and all its sub-domains have access to apis.google.com and all its sub-domains but otherwise any attempt by anyone else to access scripts, objects or sub-documents will be denied.

Does that help?

[ilcercatorediinfo]

But if a site, let's say "http://www.efgh.com" tries to access .apis.google.com, will it be successful with the ABE setting described? What I would like is that only abcd.com could access .apis.google.com not efgh.com.

[GµårÐïåñ]

But if a site, let's say "http://www.efgh.com" tries to access .apis.google.com, will it be successful with the ABE setting described?

No it would not, it would fail as it is not in the ACCEPT and is subject to the DENY.

What I would like is that only abcd.com could access .apis.google.com not efgh.com.

Correct, and that is exactly what would happen as it is explicitly stated as such. However, please NOTE and UNDERSTAND keeping it in mind that the "." at the beginning of the abcd.com will mean that ANY subdomain riding on it will be allowed too.

So for example, you might be ok with good.abcd.com but are you also ok with evil.abcd.com? If you are, then you are fine. If you are not, then make sure your accept says the actual trusted path such as good.abcd.com versus the wildcard for the domain. Ok?

Just a cautionary note to pay attention to, especially with public services such as google.com that could load ALL their services subdomains but you might only want mail.google.com and not the rest, check your wildcards.

[ilcercatorediinfo]

Thank you very much for your clear explanations Guardian. I've tried to configure some set of rules and now they work as I wish. A question more and I'm finished, I swear! The allow temporairly all the page option in NoScript (I have the italian version, so I hope you can guess what i mean) doesn't overrule ABE behaviour, does it? If ABE blocks something it's still blocked.

[GµårÐïåñ]

You are most welcome, not a problem. We are here to answer questions, so no worries. Simply put, NO (will not override ABE). Think of ABE as the final say on how the data is handled. If there is ever an apparent or seemingly conflicting state of things, NS will default to the more restrictive or secure one, in this case the ABE filter.

However, mind you, that ABE and in turn NS can only protect you based on what is core to their function, that's a given, and also what you ALLOW. So if you allow something that is NOT covered by the ABE rule(s) then you might open yourself up to something that NS might allow because you allowed it but generally speaking if you have a rule for xyz in ABE and you do something related to xyz on the NS permissions menu, you are covered on both sides and ABE as your failsafe.