Need some help with ABE

[iDrugoy]

Did I get it right, that regular NoScript's rules (allow/block) are just simpler versions of ABE rules?
Who's priority higher - regular rules' or ABE ones'?

What is "SELF++" from the example in FAQ?

What's the difference between "SYSTEM" and "USER" rulesets? NoScript's rules get stored to a Firefox profile, how would it affect another one?

How does a feature "Allow sites to push their own rulesets" work? Does it mean that sites that may recognize NoScript - can use some NoScript's internal protocol to send their rulesets to users?
What's the use of such a feature? Sites would then permit everything they need, don't you think that's a security hole and that checkbox should be put away to about:config?

Could you add a non-text GUI to manage ABE rules?

[Thrawn]

Did I get it right, that regular NoScript's rules (allow/block) are just simpler versions of ABE rules?

No, the regular script-blocking is not in the form of ABE rules. Actually, it uses Content Security Policy. But it would probably be possible to write ABE rules that would simulate NoScript's regular behavior. With tremendous amounts of work.

Who's priority higher - regular rules' or ABE ones'?

Both. If either one blocks a request, then it will be blocked.

What is "SELF++" from the example in FAQ?

Please read ABE Rules .pdf.

What's the difference between "SYSTEM" and "USER" rulesets?

No difference; both rulesets are applied exactly the same way. The reason to have two of them is: once a request matches a rule, ABE stops processing the rest of that ruleset, BUT it will still process the other ruleset. So, you can write whatever you want in the USER ruleset without affecting the built-in SYSTEM rule.

NoScript's rules get stored to a Firefox profile, how would it affect another one?

It wouldn't affect another profile at all. ABE on a different profile would have whatever rules were defined on that profile (probably just the built-in SYSTEM rule).

How does a feature "Allow sites to push their own rulesets" work? Does it mean that sites that may recognize NoScript - can use some NoScript's internal protocol to send their rulesets to users?
What's the use of such a feature? Sites would then permit everything they need, don't you think that's a security hole and that checkbox should be put away to about:config?

Please see the documentation of this feature. No, it's not a security hole. It is, however, under the Advanced tab for good reason. Sadly, I haven't heard of any sites actually using it.

Could you add a non-text GUI to manage ABE rules?

Guardian and I have started to develop such a GUI, but it is a lot of work, and we haven't had time to get far. In the meantime, you can try the RequestPolicy addon, which is less powerful than ABE, but suffices for most jobs, and is very easy to use (interface inspired by NoScript, actually).

[iDrugoy]

No, the regular script-blocking is not in the form of ABE rules. Actually, it uses Content Security Policy. But it would probably be possible to write ABE rules that would simulate NoScript's regular behavior. With tremendous amounts of work.

What is CSP? And your 2nd statement contradicts the 1st one.

Both. If either one blocks a request, then it will be blocked.

And what if one blocks and the other one permits?

Please read ABE Rules .pdf.

Thanks, resolved.

No difference; both rulesets are applied exactly the same way. The reason to have two of them is: once a request matches a rule, ABE stops processing the rest of that ruleset, BUT it will still process the other ruleset. So, you can write whatever you want in the USER ruleset without affecting the built-in SYSTEM rule.

Don't you think it's lame? Why does it stop? What if a page has many scripts and I have ABE rules for each of them - then the first matching rule in each ruleset will stop NoScript completely?

Guardian and I have started to develop such a GUI, but it is a lot of work, and we haven't had time to get far.

Awesome, I didn't know that not only Giorgio develops NoScript.
Then maybe you could also add another feature I've requested years ago, please? Bring subscriptions support for all NoScript rules: whitelist, blacklist, ABE, XSS and HTTPS.
Giorgio's position was that it is kinda insecure to grant someone (a subscription moderator) so many rights. But he ignored my point:
1. no one gets forced to use subscriptions - it's their own choice to use or not to use them.
2. many Firefox users don't use NoScript at all, since it's too complicated to use. They would be the main target group for subscriptions.

In the meantime, you can try the RequestPolicy addon, which is less powerful than ABE, but suffices for most jobs, and is very easy to use (interface inspired by NoScript, actually).

Yeah, I've used that add-on years ago, but it's author doesn't have time for further development, so for me it's an almost dead extension, not gonna use it.

[Giorgio Maone]

No, the regular script-blocking is not in the form of ABE rules. Actually, it uses Content Security Policy. But it would probably be possible to write ABE rules that would simulate NoScript's regular behavior. With tremendous amounts of work.

What is CSP? And your 2nd statement contradicts the 1st one.

The regular script blocking uses CAPS and nsIDocShell's API. CSP is different beast (a W3C standard, now). You can easily google both acronyms.
ABE intercepts HTTP requests instead: it doesn't affect script permissions (beside the Sandbox predicate) but can block any HTTP request, thus preventing stuff from loading at all.

And what if one blocks and the other one permits?

Blocked.

No difference; both rulesets are applied exactly the same way. The reason to have two of them is: once a request matches a rule, ABE stops processing the rest of that ruleset, BUT it will still process the other ruleset. So, you can write whatever you want in the USER ruleset without affecting the built-in SYSTEM rule.

Don't you think it's lame? Why does it stop? What if a page has many scripts and I have ABE rules for each of them - then the first matching rule in each ruleset will stop NoScript completely?

The first matching rule for any single request, i.e. all rules from all rulesets are applied to each request, and processing of each ruleset is stopped as soon as the first rule matches, but it's resumed from the beginning for the next request. In other words, "if a page has many scripts" all the rulesets will be iterated many times, one for each script.

[iDrugoy]

The regular script blocking uses CAPS and nsIDocShell's API. CSP is different beast (a W3C standard, now). You can easily google both acronyms.
ABE intercepts HTTP requests instead: it doesn't affect script permissions (beside the Sandbox predicate) but can block any HTTP request, thus preventing stuff from loading at all.

So, as far as I understood, ABE works for Fx pretty similar to how hosts file works for Windows, except ABE is smarter: it can differentiate post/get and content type (sub-documents and all the inclusions) + controls cross-site policies.
Now I want to learn how to use it, since this may completely replace regular NoScript rules.

The first matching rule for any single request, i.e. all rules from all rulesets are applied to each request, and processing of each ruleset is stopped as soon as the first rule matches, but it's resumed from the beginning for the next request. In other words, "if a page has many scripts" all the rulesets will be iterated many times, one for each script.

I seriously tried to understand this, but seems like I couldn't.

Now could someone, please, help me learn how to use ABE? I've read the pdf, but seems like it doesn't work fine for me:
I want to create a rule so all .google.com (btw, does NoScript and ABE in particular understand smth like google.tld [which should match google domain in any zone]?) sub-documents/inclusions will be blocked everywhere except on .google.com

None of these rules worked:

Code: Select all

# Google only on google
Site .google.com
Accept ALL from .google.com
Deny

Code: Select all

# Google only on google
Site .google.com
Accept ALL from .google.com

Code: Select all

# Google only on google
Site .google.com
Accept ALL from SELF++
Deny

Code: Select all

# Google only on google
Site .google.com
Accept ALL from SELF++

[iDrugoy]

Or do I still have to allow google's scripts in regular rules? [I still don't get whether ABE can fully replace regular rules, or it's just an addition to them]

[Giorgio Maone]

Or do I still have to allow google's scripts in regular rules? [I still don't get whether ABE can fully replace regular rules, or it's just an addition to them]

In facts, unless you use "Allow google.com" from NoScript's main menu, scripts won't work anyway.
ABE is orthogonal to script permissions: think of it as a stand-alone module which works independently from NoScript.
All the rules you listed in your previous post are roughly equivalent, and their shorter form is

Code: Select all

Site .google.com
Accept from SELF++ # "ALL" is optional
Deny

If you want to add a local TLD to the mix,

Code: Select all

Site .google.com .google.ru
Accept from .google.com .google.ru
Deny

However, if you want to follow links to Google searches from other sites, you need to limit your denies to inclusions only, hence

Code: Select all

Site .google.com .google.ru
Accept from .google.com .google.ru
Deny INC

Again, don't forget to "Allow google.com" and "Allow google.ru" in NoScript's main whitelist.

[iDrugoy]

I've already figured out all you said.
I just didn't know, that ABE rules require regular rules to work. To me that seems pretty awkward, could you please add a hidden pref to make ABE rules work without requiring regular rules?

[Thrawn]

I've already figured out all you said.
I just didn't know, that ABE rules require regular rules to work. To me that seems pretty awkward, could you please add a hidden pref to make ABE rules work without requiring regular rules?

I can make a pretty good guess at answering for Giorgio and say "No." ABE is a completely separate feature from the regular script-blocking, and was primarily designed for preventing CSRF attacks.

What situations do you have where you want this? There may be a better way to achieve what you want.

[Thrawn]

Guardian and I have started to develop such a GUI, but it is a lot of work, and we haven't had time to get far.

Awesome, I didn't know that not only Giorgio develops NoScript.

Actually, he does. Guardian and I were working on a separate addon that would interact with NoScript. If Giorgio were to then choose to merge it in, he could. NoScript (and FlashGot) are exclusively his.

Then maybe you could also add another feature I've requested years ago, please? Bring subscriptions support for all NoScript rules: whitelist, blacklist, ABE, XSS and HTTPS.

ABE subscriptions have been talked about, but I actually don't like the idea. I think the best option is to collect rules that people have found useful, and pick & choose which ones you like. People have such different usage patterns for sites that it's not feasible to just sign up to a list.

Do you want to allow Facebook everywhere, just on its own site, or just block Facebook Connect?
Do you use Google at all? Just Google Maps? Gmail?
Similarly for Yahoo?

I can see some legitimate uses for a subscription list for bank-related sites, since their usage patterns are much more consistent, and you definitely want to restrict them to their own sites. But you probably only use a very small number of banks, so signing up to a list of rules for hundreds or thousands of them is overkill. As Giorgio mentioned, every single HTTP request you make will be filtered through every rule, which would be a big performance hit for huge ABE rulesets. Better to just have a list of potential rules, identify which ones apply to you, and copy those ones.

As for the other subscriptions - there are already predefined lists of untrusted sites (like hosts files), and HTTPS sites (HTTPS Everywhere), while XSS exceptions should only be used in rare cases where a site's normal (bad) behavior is to XSS itself. And subscription-based whitelisting is a minefield that I recommend everyone keep out of. Huge issues with who you choose to trust to set up such a list. If you want to set up a 'Subscription helper for NoScript' addon (with Giorgio's permission to use the name), which would edit the Content Security Policy settings, you may try it.

2. many Firefox users don't use NoScript at all, since it's too complicated to use. They would be the main target group for subscriptions.

Then they should a) put NoScript in 'Scripts Globally Allowed' mode, and/or b) use Adblock Plus, preferably with the Anti-Malware subscription list. Or ask a tech-savvy friend to set it up for them.

And by the way, I guarantee that an ABE subscription, if powerful enough to be significantly useful, would end up causing more problems, which would be harder for non-tech users to solve, than NoScript's regular script-blocking.

In the meantime, you can try the RequestPolicy addon, which is less powerful than ABE, but suffices for most jobs, and is very easy to use (interface inspired by NoScript, actually).

Yeah, I've used that add-on years ago, but it's author doesn't have time for further development, so for me it's an almost dead extension, not gonna use it.

?? Most of the moderators here use it, and it's not dead at all...plus it already works well.

[iDrugoy]

I can make a pretty good guess at answering for Giorgio and say "No." ABE is a completely separate feature from the regular script-blocking, and was primarily designed for preventing CSRF attacks.

That's lame. I want to have full control over scripts, both: site and cross-site scripts. Since the latter is more advanced than the former and since it is already implemented - I don't see any good reasons for "simple" rules to exist. Simple rules can be represented as ABE rules, so why not just write aliases for them so they get converted?

What situations do you have where you want this? There may be a better way to achieve what you want.

I don't have to be in any situation to want to have full control over scripts. Currently, NoScript makes me double my rules: instead of having just ABE I have to create regular whitelist rules. That's lame.

[iDrugoy]

Actually, he does. Guardian and I were working on a separate addon that would interact with NoScript. If Giorgio were to then choose to merge it in, he could. NoScript (and FlashGot) are exclusively his.

That's acceptable for me: if Giorgio ignores my feature requests & bug reports - I'd be glad to see them released as a separate add-on.

ABE subscriptions have been talked about, but I actually don't like the idea. I think the best option is to collect rules that people have found useful, and pick & choose which ones you like. People have such different usage patterns for sites that it's not feasible to just sign up to a list.

How do you imagine that? Ask every user to share his rules? That's slow and lame. It's way easier to sign-up for a subscription and disable some of it's rules if you don't like them.

Do you want to allow Facebook everywhere, just on its own site, or just block Facebook Connect?
Do you use Google at all? Just Google Maps? Gmail?
Similarly for Yahoo?

As far as I understand - you don't actually expect me to answer these questions, but just brought them as prove to your point about different users having different patterns. I've answered that above.

I can see some legitimate uses for a subscription list for bank-related sites, since their usage patterns are much more consistent, and you definitely want to restrict them to their own sites. But you probably only use a very small number of banks, so signing up to a list of rules for hundreds or thousands of them is overkill. As Giorgio mentioned, every single HTTP request you make will be filtered through every rule, which would be a big performance hit for huge ABE rulesets. Better to just have a list of potential rules, identify which ones apply to you, and copy those ones.

The golden words! Of course it would be way more awesome to just have a list you can pick good rules from, to fit your own needs. But that's what a subscription is!
I think you misinterpret what subscription is. It's not necessarily adblock-like huge list of lotsa rules for tons of sites most of which you'll never visit.
Take a look at Wind Li's AutoPager add-on and how it's subscriptions work: the author hosts a site that contains a database, so when a user visits any site, he may click to send the query to Wind Li's database to search for rules for that site. And the user selects the one he likes more (sometimes there are different rules by different authors for the same site).
Thus, the user has only the rules for the sites he visits. Thus, no overkill/performance hit.

As for the other subscriptions - there are already predefined lists of untrusted sites (like hosts files), and HTTPS sites (HTTPS Everywhere), while XSS exceptions should only be used in rare cases where a site's normal (bad) behavior is to XSS itself. And subscription-based whitelisting is a minefield that I recommend everyone keep out of. Huge issues with who you choose to trust to set up such a list.

I don't know what you are talking about. Predefined lists? Thanks, no. I've even removed most of "whitelisted" rules that NoScript has by default.

If you want to set up a 'Subscription helper for NoScript' addon (with Giorgio's permission to use the name), which would edit the Content Security Policy settings, you may try it.

URL, please?
Or you suggest me to write that add-on? If so - then it'd be easier just to patch NoScript the way I like (without anyone's permissions).

Then they should a) put NoScript in 'Scripts Globally Allowed' mode,

that's almost equal to not install NoScript.
All those "CSRF/XSS/WUTEVAELSE" attacks are so rare, that plain users mostly never get affected. But what they get affected by - is the tracking by evilCorps (mostly, scroogle). And if all scripts are globally allowed - it's way easier to delete NoScript and have a slight performance boost.

and/or b) use Adblock Plus, preferably with the Anti-Malware subscription list. Or ask a tech-savvy friend to set it up for them.

Hmm, I forgot that ABP can block scripts. Thanks for reminding, now I'll consider removing NoScript in favor of anti-script rules for AdBlock. The only thing I'll miss then is NoScript's surrogate system.

[thunderscript]

Then they should a) put NoScript in 'Scripts Globally Allowed' mode,

that's almost equal to not install NoScript.

No, it is not.

and/or b) use Adblock Plus, preferably with the Anti-Malware subscription list. Or ask a tech-savvy friend to set it up for them.

Hmm, I forgot that ABP can block scripts. Thanks for reminding, now I'll consider removing NoScript in favor of anti-script rules for AdBlock. The only thing I'll miss then is NoScript's surrogate system.

OK. Good luck with inline scripts and otherwise embedded content!

[Thrawn]

That's acceptable for me: if Giorgio ignores my feature requests & bug reports - I'd be glad to see them released as a separate add-on.

But it is a lot of work, which is entirely voluntary, and we have families that keep us busy. Unfortunately you may be waiting a while

Take a look at Wind Li's AutoPager add-on and how it's subscriptions work: the author hosts a site that contains a database, so when a user visits any site, he may click to send the query to Wind Li's database to search for rules for that site. And the user selects the one he likes more (sometimes there are different rules by different authors for the same site).
Thus, the user has only the rules for the sites he visits. Thus, no overkill/performance hit.

Loading only rules for the current site is an interesting idea. I would view it as an extension to the existing 'Allow sites to push their own rulesets' functionality, but managed locally, since website owners don't seem inclined to use it.

The implementation might get complex, though. And you'd still have to pick and choose which rules you wanted to locally import and apply.

If you want Giorgio to do this, how about sending him a large donation and a private message asking to discuss it?

As for the other subscriptions - there are already predefined lists of untrusted sites (like hosts files), and HTTPS sites (HTTPS Everywhere), while XSS exceptions should only be used in rare cases where a site's normal (bad) behavior is to XSS itself. And subscription-based whitelisting is a minefield that I recommend everyone keep out of. Huge issues with who you choose to trust to set up such a list.

I don't know what you are talking about. Predefined lists? Thanks, no. I've even removed most of "whitelisted" rules that NoScript has by default.

I was referring to your request for whitelist, blacklist, XSS, and HTTPS subscriptions. There has already been so much work done on blocking hosts files and HTTPS Everywhere that it would not be worth trying to duplicate it. XSS exceptions should be rare, and you should always know exactly why you are adding one, so subscriptions would be inappropriate. And whitelist subscriptions - no thanks. Since you've even deleted NoScript's small built-in whitelist, clearly you agree that no-one else should be in charge of what you trust.

If you want to set up a 'Subscription helper for NoScript' addon (with Giorgio's permission to use the name), which would edit the Content Security Policy settings, you may try it.

URL, please?
Or you suggest me to write that add-on? If so - then it'd be easier just to patch NoScript the way I like (without anyone's permissions).

Go right ahead! But to show appreciation for the tool that you're building on top of, it would be nice for you to make those patches publicly available.

And if you choose to share your changes with your friends, please bear in mind that the code is GPL-licensed, and the trademarks still belong to Giorgio.

Then they should a) put NoScript in 'Scripts Globally Allowed' mode,

that's almost equal to not install NoScript.
All those "CSRF/XSS/WUTEVAELSE" attacks are so rare, that plain users mostly never get affected. But what they get affected by - is the tracking by evilCorps (mostly, scroogle). And if all scripts are globally allowed - it's way easier to delete NoScript and have a slight performance boost.

Well, I won't argue with you, but if someone isn't willing to use NoScript's menu interface, which is really very easy, then hardly any protection is what they will get...

and/or b) use Adblock Plus, preferably with the Anti-Malware subscription list. Or ask a tech-savvy friend to set it up for them.

Hmm, I forgot that ABP can block scripts. Thanks for reminding, now I'll consider removing NoScript in favor of anti-script rules for AdBlock. The only thing I'll miss then is NoScript's surrogate system.

I really do recommend trying RequestPolicy. AFAIK, it's actively maintained, and it does most of what you seem to what.

[iDrugoy]

I really do recommend trying RequestPolicy. AFAIK, it's actively maintained, and it does most of what you seem to what.

https://github.com/jsamuel - just take a look at his activity. If that's what you call "being actively maintained" - well, I have nothing to say.