Integrating ABE with RequestPolicy

[barbaz]

With an Untrusted list that doesn't fit on a tooltip, I'm not sure how that would work out performance-wise. I think you could keep the original scope of the addon, but instead of dynamic menus, you could create an interface similar to Adblock Plus blockable items. You start with a list of requests made by the web page and their status, and in your addon you could right-click a request to "Set permissions." Then the user would be presented with a dialog containing a list of rule suggestions and the option to write their own rule. There could also be a section where specifics such as request type can be specified.

Also, I don't think your addon should modify SYSTEM/USER/whatever rulesets unless needed to enforce a rule created with it, but should instead create its own. Suggestion: Use the about:config preference

Code: Select all

noscript.ABE.rulesets.SABER

which would store your addon's rules under the ruleset named SABER.

[Thrawn]

With an Untrusted list that doesn't fit on a tooltip, I'm not sure how that would work out performance-wise.

I'm not sure either, but you could always choose not to write rules for your blacklist, and just let them be handled like other non-trusted sites, if it became an issue.

I think you could keep the original scope of the addon, but instead of dynamic menus, you could create an interface similar to Adblock Plus blockable items.

The idea is to simplify it to a point where something can be completed in a short time.

You start with a list of requests made by the web page and their status

That is more complicated than you might think.

Then the user would be presented with a dialog containing a list of rule suggestions and the option to write their own rule. There could also be a section where specifics such as request type can be specified.

This is basically the original plan, and it hasn't been entirely thrown away; it might well be possible to add that later.

Also, I don't think your addon should modify SYSTEM/USER/whatever rulesets unless needed to enforce a rule created with it, but should instead create its own. Suggestion: Use the about:config preference

Code: Select all

noscript.ABE.rulesets.SABER

which would store your addon's rules under the ruleset named SABER.

Oh, I know . I discovered that feature a month or two ago, and I certainly plan to use it. Saves having to distinguish between SABER rules and others, and makes uninstallation much cleaner, plus it means that you can easily write extra restrictions for specific sites in your USER ruleset without interfering. It does, of course, mean that you can't easily override SABER rules with less restrictive ones, so SABER would need to provide a way to exclude sites and let them be handled elsewhere.

[barbaz]

I think you could keep the original scope of the addon, but instead of dynamic menus, you could create an interface similar to Adblock Plus blockable items.

The idea is to simplify it to a point where something can be completed in a short time.

Oh, I thought you were just trying to make SABER easier to code. IMO an ABP-like interface would also be easier to use than dynamic menus. YMMV.

You start with a list of requests made by the web page and their status

That is more complicated than you might think.

I've seen (and tried to patch) the code for this in ABP. I think a simplified version of that could work for SABER (without the issues of ABP's code). But I agree with you it's not easy.


So for now, what about rules like

Code: Select all

Site <whitelist>
Sandbox from <Temp-allowed sites>

Site .*
Deny INCLUSION(PING)

# more compatible substitute for security.mixed_content.block_active_content
Site http:
Accept INCLUSION(OBJSUB)
Deny INCLUSION(SCRIPT, OBJ, SUBDOC, CSS, FONT, XHR) from https:

?

[Thrawn]

Oh, I thought you were just trying to make SABER easier to code. IMO an ABP-like interface would also be easier to use than dynamic menus. YMMV.

It probably would, but the starting idea here is to provide just an interface to write one rule to guard all permanently whitelisted sites, one rule to guard all temporarily whitelisted sites, etc. Which is simpler again, but will probably lean more toward ABP-style.

So for now, what about rules like

Code: Select all

Site <whitelist>
Sandbox from <Temp-allowed sites>

Should be possible.

Code: Select all

Site .*
Deny INCLUSION(PING)

Should really be 'Site ALL', but is already partly handled by Options-Advanced-Untrusted, and you can easily write it yourself; it doesn't need site-by-site control.

Controlling inclusions, let alone specific inclusion types, would not be in the first iteration of this, but later versions would certainly aim to let you write custom rules taking advantage of 'all whitelist', 'all blacklist', etc.

Code: Select all

# more compatible substitute for security.mixed_content.block_active_content
Site http:
Accept INCLUSION(OBJSUB)
Deny INCLUSION(SCRIPT, OBJ, SUBDOC, CSS, FONT, XHR) from https:

As above, you can already do this easily in standard ABE. The value-add of the proposed SABER is that it lets you write rules that are automatically updated as you allow or forbid sites. One-off static rules, especially complex ones, are probably best handled via ABE's usual interface.

[Thrawn]

For those who are interested:

I've had some success in setting up a restartless addon that will monitor your NoScript whitelist/blacklist, and allow you to write ABE rules using special keywords for them (WHITELIST, TEMPWHITELIST, BLACKLIST). It's pre-alpha, however.

Once I've sorted out the filtering of internal URLs from the whitelist (eg about: and chrome: URLs), I'll work on making a graphical rule-entry interface.

Please PM me if you want a link to the XPI file on my Google Drive. Feedback is welcome, but bear in mind that it's still very unfinished.

[Thrawn]

Is anyone interested in helping to produce the logo image? I'm thinking of combining

http://noscript.net/abe/ABE128.png

with one of these:

https://www.google.com.au/search?q=lightsaber+png&tbm=isch

[forecehh]

one of thing that RP dont have and this one must have it is like below
allow create rule like this
mediafire.com to 199.*.*.*
so on site like mediafire there is no problem with downloading
in RP must write rule for each ip

[barbaz]

create rule like this
mediafire.com to 199.*.*.*
so on site like mediafire there is no problem with downloading

You can already do that with regexp in ABE:

Code: Select all

Site ^https?://199\.\d+\.\d+\.\d+[/:]
Accept from .mediafire.com
Deny

[Thrawn]

SABER now has a primitive GUI, allowing you to create up to 4 rules using drop-down boxes. The next version is intended to expand this to an arbitrary number.

It's still mostly a proof-of-concept, but it's getting there - and it does produce functional ABE rules.

If anyone wants the link, just PM me.

[yes_noscript]

How is the current state since the last post is from Jan 07.

[Thrawn]

It hasn't moved lately - I've been working on an unrelated project - but it's not forgotten. Once the other has stabilised, I'll probably work on SABER next.

[yes_noscript]

Hello Thrawn.
Okay well, we will see

Uhm how works the deployment with your "Integrating ABE with RequestPolicy" addon? Did you terminated it?

[Thrawn]

Uhm how works the deployment with your "Integrating ABE with RequestPolicy" addon? Did you terminated it?

Not terminated, no, but still largely experimental.

[barbaz]

Split off-topic discussion regarding various other extensions to Ragnarök.

[barbaz]

EDIT - the following 5 posts were split from the µMatrix thread (link given further on)
/EDIT

So Seamonkey is probably out of luck.

Nope, at least not yet. WFM
(Note that SeaMonkey does contain some backend parts of Australis, even though there's nothing user-facing that indicates it.)

Truthfully, it does cast a lot of doubt on the value proposition of SABER...ABE can still do things that uMatrix can't, but you probably want to write that kind of specialised stuff directly in text anyway. For the kind of day-to-day usage where you really want a GUI, I think uMatrix may have it covered, better than I could do without a whole lot more time than I think I'll have to invest in it.

Thoughts?

Well, I find myself going to the µMatrix dashboard nearly every time I want to change something. Its GUI has the expected effect only about half the time, but maybe I'm just not used to it.

Also, µMatrix doesn't have the ability to dynamically monitor the NoScript whitelist & tempwhitelist and construct rules based on that... IMO that sort of thing is better left up to a dedicated addon like SABER (or as a part of NS itself).

My opinion is that dropping SABER in favor of µMatrix is a bad idea and will result in lost functionality, but I think the scope of SABER maybe worth re-evaluated to be more focused on the NoScript integration side, rather than "general" rule-making.