InformAction Forums

Would it be possible to add an option in the Appearance tab to display an enable/disable toggle for ABE in NoScript icon menu?

Given how complex ABE rules can be, and how unpredictably may some websites may interact with them, I think that a quick toggle from Firefox main GUI (instead of opening NoScript preferences window and then navigate to the Advanced tab) may come handy here.

For a similar reason, would it be possible to add an "export ABE rules" option in the Advanced tab ?
I understand these can be exported along with all NoScript settings, and also found in pref.js, but in both cases are somehow scrambled, they are not ready to be copied/pasted as they are: what bout exporting them already formatted as they are visible in the GUI ?

-1 to having a toggle for ABE so easily accessible, for these reasons:
(from viewtopic.php?p=80178#p80178 where someone requested similar)

barbaz wrote:Please no. ABE is designed to prevent CSRF, having the option to allow something that you have defined as CSRF is a terrible idea. Many users will click that accidentally or without thinking and then later discover that their router has been taken over or their bank account has been drained into a huge deficit.
Editing the ABE rules to make specific request(s) not defined as CSRF is a MUCH better way, and it can't be done accidentally nor carelessly/thoughtlessly.

OTOH, +1 bigtime to adding plain-text export of only ABE rules, because it would make it much easier to distribute them - there would not be risk that in copying ABE rules would accidentally delete (or have done "Cut" instead of "Copy"), and have to know to hit Ctrl+Z to get it back (yes, I have lost ABE rules that way!).

What kind of complex rules do you have? ABE is meant to protect specific, sensitive sites.

If you're after general-purpose cross-site request control, then perhaps you would be better off with a specialised tool, with a more complete graphical interface, like RequestPolicy, Policeman, or uMatrix?

Thrawn wrote:Policeman

viewtopic.php?p=80681#p80681

Thrawn wrote:What kind of complex rules do you have? ABE is meant to protect specific, sensitive sites.

If you're after general purpose cross site request control, then perhaps you would be better off with a specialized tool, with a more complete graphical interface, like RequestPolicy, Policeman, or uMatrix?

Well, to be fair any ABE rule is complex for me... I should have written "if you have many rules".

Which brings us to your point above: I know about those (BTW, very interesting) extensions, but can they do *anything* ABE can?
When experimenting with some ABE rules, I see they can break some websites (or parts of websites) somehow differently from the extensions cited above.

So the question is, is ABE doing something different from them? Can it still do more than they do, at least in some particular cases?

------------------------------------------------------------------------------------------------------------------------------------------------------

barbaz wrote:-1 to having a toggle for ABE so easily accessible, for these reasons:
(from viewtopic.php?p=80178#p80178 where someone requested similar)

barbaz wrote:Please no. ABE is designed to prevent CSRF, having the option to allow something that you have defined as CSRF is a terrible idea. Many users will click that accidentally or without thinking and then later discover that their router has been taken over or their bank account has been drained into a huge deficit.
Editing the ABE rules to make specific request(s) not defined as CSRF is a MUCH better way, and it can't be done accidentally nor carelessly/thoughtlessly.

I respectfully disagree here: ABE is IMHO an advanced feature inside an advanced extension: it's therefore up to the user to figure out what he's doing.

Having a toggle for ABE rules exposed in the GUI would be in principle not so different from the currently available "Allow Scripts Globally" option in the Advanced tab, aptly labeled as "dangerous".

If the concern here is CSRF attacks (and rightly so) , this quick toggle could perhaps be limited to USER rules, leaving SYSTEM rules intact.

johnscript wrote:Which brings us to your point above: I know about those (BTW, very interesting) extensions, but can they do *anything* ABE can?
When experimenting with some ABE rules, I see they can break some websites (or parts of websites) somehow differently from the extensions cited above.

So the question is, is ABE doing something different from them? Can it still do more than they do, at least in some particular cases?

ABE has Anonymize and Sandbox actions that the other tools don't have, and ABE can filter by path (not just by domain), but otherwise the capabilities are mostly the same.

johnscript wrote:I respectfully disagree here: ABE is IMHO an advanced feature inside an advanced extension: it's therefore up to the user to figure out what he's doing.

I completely agree with the fact that it's up to the user to figure out what they're doing with ABE. I do not understand how offering a NS menu option to completely disable ABE, which even novice users who don't know what they're doing at all will find and click without any real reason, is in any way in line with that concept.

johnscript wrote:Having a toggle for ABE rules exposed in the GUI would be in principle not so different from the currently available "Allow Scripts Globally" option in the Advanced tab, aptly labeled as "dangerous".

In principle it's very much different.
First off, Allow Scripts Globally allows things you don't know whether they're good or bad, while disabling ABE allows things you have explicitly defined as bad. In this regard in order to be comparable Allow Scripts Globally would have to also Allow all scripts the user defined as Untrusted
Secondly, Allow Scripts Globally is useful for trubleshooting, because there's not necessarily an obvious indication when the fact a script needs Allowed is the problem. With ABE, when it takes action there is message in the Browser Console (Ctrl-Shift-J) and/or a notification bar, and either will tell you which ruleset is the problem - there is not need to completely disable ABE to find this out.
Thirdly,...

johnscript wrote:If the concern here is CSRF attacks (and rightly so) , this quick toggle could perhaps be limited to USER rules, leaving SYSTEM rules intact.

Because the USER ruleset "should" generally not be used for anti-CSRF defenses?

I was under the (wrong) impression that the most important ruleset to block CSRF attacks was the "System" rules.

System rules means "Giorgio has decided that it's in everyone's best interests to have these rules unless they explicitly decide otherwise." Thus, there is only one rule in it at present.