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
Code: Select all
noscript.ABE.rulesets.SABER
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.barbaz wrote:With an Untrusted list that doesn't fit on a tooltip, I'm not sure how that would work out performance-wise.
The idea is to simplify it to a point where something can be completed in a short time.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.
That is more complicated than you might think.You start with a list of requests made by the web page and their status
This is basically the original plan, and it hasn't been entirely thrown away; it might well be possible to add that later.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.
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.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 preferencewhich would store your addon's rules under the ruleset named SABER.Code: Select all
noscript.ABE.rulesets.SABER
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.Thrawn wrote:The idea is to simplify it to a point where something can be completed in a short time.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.
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.Thrawn wrote:That is more complicated than you might think.You start with a list of requests made by the web page and their status
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:
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.barbaz wrote: 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.
Should be possible.So for now, what about rules like
Code: Select all
Site <whitelist> Sandbox from <Temp-allowed sites>
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.Code: Select all
Site .* Deny INCLUSION(PING)
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.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:
You can already do that with regexp in ABE:forecehh wrote:create rule like this
mediafire.com to 199.*.*.*
so on site like mediafire there is no problem with downloading
Code: Select all
Site ^https?://199\.\d+\.\d+\.\d+[/:]
Accept from .mediafire.com
Deny
Not terminated, no, but still largely experimental.yes_noscript wrote: Uhm how works the deployment with your "Integrating ABE with RequestPolicy" addon? Did you terminated it?
Nope, at least not yet. WFMThrawn wrote:So Seamonkey is probably out of luck.
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.Thrawn wrote: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?