Integrating ABE with RequestPolicy

Talk about internet security, computer security, personal security, your social security number...
User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Integrating ABE with RequestPolicy

Post by Thrawn » Mon Jan 23, 2012 10:53 pm

As discussed in the ABE forum, I'm interested in making an addon that takes RequestPolicy's interface and uses it to manage ABE rules. ABE provides great power & flexibility in controlling cross-site requests, but requires writing rules. RequestPolicy provides an interface that is quick & easy to use, and perhaps most importantly, gives feedback about which requests are being blocked/allowed on each page, but without the fine-grained permissions that ABE allows.

As an example: RequestPolicy causes many sites to lose their stylesheets. Using the ABE engine would mean that requests could be anonymised & sandboxed by default, instead of blocked, fixing this.

NoScript 3's site-specific permissions will overlap with RequestPolicy, and perhaps make it less necessary, but it still has a role in defeating web bugs, CSRF, new forms of XSS, etc.

All feedback on the pros and cons of this idea is welcome. I'll also use this topic to post ideas/progress.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; U; Linux x86_64; en-AU; rv:1.9.2.23) Gecko/20110921 Ubuntu/10.10 (maverick) Firefox/3.6.23

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Integrating ABE with RequestPolicy

Post by Thrawn » Tue Jan 24, 2012 12:29 am

Basic ideas thus far:

    Create a comment-bounded segment within the ABE rules. This would allow manual editing of regions outside the GUI's control if desired.
    Implementation would create one rule block for each specific Site, incorporating all rules that use that Site. Including multiple Sites in the same rule block is really only useful for manual editing, where it saves space & typing; it would be very complex for an automated system, and isn't essential.
    Put more specific Sites above more general ones. Sites with a path would come first (ideally placing more specific paths above their parents), followed by full domain names, followed by second-level domains, followed by TLDs, followed by *.
    Implementing Anonymize+Sandbox may require a workaround involving adding the site to both User and System rules.
    Copy & adapt interface from RequestPolicy.
    Drop 'Temporarily Allow' statusbar/context menu options (which ABE doesn't have), but add options to Anonymize, Sandbox, or both, as well as Allow, Deny, or no specific rule (ie inherit from more general rules).
    Menu options could be color-coded, eg Deny=red, Anon+Sandbox=orange, Anon=yellow, Sandbox=blue, Accept=green. Different colors might also be desirable for explicit rules vs inherited ones.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; U; Linux x86_64; en-AU; rv:1.9.2.23) Gecko/20110921 Ubuntu/10.10 (maverick) Firefox/3.6.23

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Integrating ABE with RequestPolicy

Post by Thrawn » Tue Apr 03, 2012 3:04 am

Does anyone have suggestions about whether to pull in RequestPolicy's other features, like blocking redirects and prefetches? Or should this be strictly about managing ABE rules?

The reason I ask is that there would obviously be a conflict between this and RequestPolicy, so those who want those other features might want to either include them or keep RequestPolicy. On the other hand, theoretically someone could use RequestPolicy in Allow Globally mode if they were that keen.

Have read through most of the RequestPolicy source code thus far, and will then go through NoScript (or at least the ABE-related parts). Identifying which parts of each to take will be the trickiest part.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; U; Linux x86_64; en-AU; rv:1.9.2.23) Gecko/20110921 Ubuntu/10.10 (maverick) Firefox/3.6.23

Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Integrating ABE with RequestPolicy

Post by Tom T. » Tue Apr 03, 2012 10:14 am

Thrawn wrote:Does anyone have suggestions about whether to pull in RequestPolicy's other features, like blocking redirects and prefetches? Or should this be strictly about managing ABE rules?

The reason I ask is that there would obviously be a conflict between this and RequestPolicy, so those who want those other features might want to either include them or keep RequestPolicy. On the other hand, theoretically someone could use RequestPolicy in Allow Globally mode if they were that keen..

Just a gut reaction:

IIUC the above posts, I would need three add-ons: NS, RP, and Thrawn. I like to keep the add-on list as short as possible.
When first mentioned, I thought that you were subsuming RP into your add-on, so that I need only NS + Thrawn. The latter (I thought) would do as you said for ABE rules, but also do the "more routine" functions of RP.

If all three are necessary, then if RP issues an update, there may be a conflict between it and yours, until your code is correspondingly updated. If you subsume RP, then our Thrawn add-on still works in its existing state, giving you time to make changes to match what Justin changed.

Since IDK the exact blueprint (probably you don't either, yet), this may not be on target. Just an idle thought to consider. If it applies, something to think about. If not, not.

I don't see much point in keeping RP, but putting it in Globally Allow mode, unless it's that link and DNS prefetching are still blocked -- much as NS still provides XSS and CC protection even with script globally allowed. In which case, definitely add those features to your tool. Again, two add-ons vs. three.

Am I mistaken in believing that the about:config preferences for extensions.requestpolicy.prefetch.dns.disableOnStartup and (Fx's) network.dns.disablePrefetch are redundant? -- other than that Fx defaults to false (allow DNS prefetch), and many users won't change it.

I don't remember the RP defaults -- I think it's to disable the prefetch -- but it is indeed a GUI vs. about:config thing.
In any case, yes, I'd support adding those, so that RP isn't necessary. IMHO. YMMV.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28

dhouwn
Bug Buster
Posts: 968
Joined: Thu Mar 19, 2009 12:51 pm

Re: Integrating ABE with RequestPolicy

Post by dhouwn » Tue Apr 03, 2012 10:18 am

Thrawn wrote:Does anyone have suggestions about whether to pull in RequestPolicy's other features, like blocking redirects and prefetches? Or should this be strictly about managing ABE rules?
IMHO you should keep it simple at first. And considering blocking prefetches, isn't RP just flipping two switches and checking whether they haven't been re-set?

Thrawn wrote:The reason I ask is that there would obviously be a conflict between this and RequestPolicy, so those who want those other features might want to either include them or keep RequestPolicy.
I wouldn't care so much about who's the target for now. In general, IMHO doing something iteratively is the better way to go (should it be possible, e.g. you can't build a cathedral iteratively).

Do you and if where do you plan on making the source code public? Bitbucket, github?
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0

Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Integrating ABE with RequestPolicy

Post by Tom T. » Tue Apr 03, 2012 10:45 am

dhouwn wrote:I wouldn't care so much about who's the target for now. In general, IMHO doing something iteratively is the better way to go (should it be possible, e.g. you can't build a cathedral iteratively).

Agree in general, although I think the target market should be kept in mind - for *any* product.

One must pour the foundation for the cathedral based on what the ultimate product is envisioned to be. This is better than creating a limited foundation (code base/infrastructure), then trying to add infrastructure later to support new features that weren't provided for at first.

If only I could think of an example.... -- oh, yeah -- Windows. :mrgreen:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Integrating ABE with RequestPolicy

Post by Thrawn » Mon Apr 09, 2012 2:02 am

Tom T. wrote:When first mentioned, I thought that you were subsuming RP into your add-on, so that I need only NS + Thrawn. The latter (I thought) would do as you said for ABE rules, but also do the "more routine" functions of RP.

If all three are necessary, then if RP issues an update, there may be a conflict between it and yours, until your code is correspondingly updated. If you subsume RP, then our Thrawn add-on still works in its existing state, giving you time to make changes to match what Justin changed.


Replacing RequestPolicy is the goal, yes. I agree with the desire to minimise addon lists, so having just NoScript + configuration helper sounds good to me. The question becomes: how thoroughly does it need to replace RP?

Technically there wouldn't be a conflict, any more than vanilla ABE conflicts with RP, but there would be massive overlap; your workload while browsing would be doubled if you ran both. ABE and RP do a similar job with different underlying engines, so eg RP can temporarily allow things (and I wish it could 'Make temporary permissions permanent'!) and gives a nice interface for controlling redirects, while ABE can Anonymize, Sandbox, and set fine-grained origin and destination rules. However, when the underlying engines provide slightly different sets of features, do I need to include both sets? Up until now, the plan was for my addon not to actually process requests itself, just detect them, show them to the user, and edit associated rules, thus delegating the work to ABE, so I probably wouldn't need to keep track of RP changes. But if it needs to do everything that RP can, then it will have to copy more code from RP and take a more active role, as well as yes, needing maintenance if that code changes. Could get messy.

On the bright side of things, I think it can be iterative easily enough. I'd start with just writing ABE rules, and maybe later copy more RP code and hook it in. Don't forget that ABE has a lot more flexibility than RP (does anyone else here block all .cn and .ru domains?), so I think there's a lot of scope for using it, in less restrictive modes, alongside RequestPolicy, until such time as it can take over. For those who prefer ABE's way of doing things, it could still be a replacement, just not like-for-like.

dhouwn wrote:
Thrawn wrote:Does anyone have suggestions about whether to pull in RequestPolicy's other features, like blocking redirects and prefetches? Or should this be strictly about managing ABE rules?
IMHO you should keep it simple at first. And considering blocking prefetches, isn't RP just flipping two switches and checking whether they haven't been re-set?


I think so. That part should be easy enough to include. It's things like the interface for managing redirects that couldn't easily be provided by ABE.

dhouwn wrote:Do you and if where do you plan on making the source code public? Bitbucket, github?


Interesting idea, and the code would certainly be GPL, but since most of it will be drawn directly from NoScript (ABE rules parser) and RequestPolicy (chrome), there might not be much to publish. I haven't given it much thought.

By the way, my idea for the name is something like Application Boundaries Configurator for NoScript :). ABC would be used to (more easily) configure the boundaries, ABE would enforce them. Or is that too confusing?
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0

Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Integrating ABE with RequestPolicy

Post by Tom T. » Mon Apr 09, 2012 6:06 am

Thrawn wrote:Technically there wouldn't be a conflict, any more than vanilla ABE conflicts with RP, but there would be massive overlap; your workload while browsing would be doubled if you ran both. ABE and RP do a similar job with different underlying engines, so eg RP can temporarily allow things (and I wish it could 'Make temporary permissions permanent'!)

Seems like an easy RFE to Justin while you work on yours ... One can always "revoke temp", then "allow" the desired request, so it's saving only a couple of clicks. Still, why not?
However, when the underlying engines provide slightly different sets of features, do I need to include both sets? <snip> But if it needs to do everything that RP can, then it will have to copy more code from RP and take a more active role, as well as yes, needing maintenance if that code changes. Could get messy.

Yes, as per above, I assumed that you would be including a lot of RP code, rather than reinvent that wheel.

So perhaps the choices are: Keep all three add-ons (overlap and more user work, as you said), or
Assume all of RP's functions, probably in your own way, in your own single integrated engine -- else you get that duplication and add'l maintenance.

I could be mistaken here; it's a gut reaction; but when you have the luxury of starting from scratch, and you're going to use ABE to detect and show all requests anyway, why not provide the same blocking as RP, in one integrated GUI? (Perhaps color-coded, to differentiate simpler RP functions from the more complex ABE rules? -- I think I'm getting away from my gut here. Will stick with the first thought.)
On the bright side of things, I think it can be iterative easily enough. I'd start with just writing ABE rules, and maybe later copy more RP code and hook it in. Don't forget that ABE has a lot more flexibility than RP (does anyone else here block all .cn and .ru domains?)

I don't. For one thing, we get legitimate support requests from users of Russian sites like Yandex, and may have to visit them to diagnose. Also, even if a link leads to a malicious .cn site, I want to see that destination (with proper armor worn, of course), so that I can report back to both the user and the community.
(I've reported a newly-discovered virus, found via user post here, to those who deal in such things and disseminate the word to the AV vendors etc.)

At another forum, strictly entertainment and not at all IT-related, where I'm just an ordinary member, not a Moderator, a number of members received spam PMs, and posted about it. I volunteered to follow the links all the way, so that I could report back that it was in fact malware, identifying the .cn site and *warning this non-tech crowd not to click anything*. Not trying to sound arrogant; just that detective work can require poking in some dark corners.

Plus the legitimate sites.

(iterative)
If you can do it on a step-by-step basis, then very well, of course. I'd just hate to see you "painted into a corner" a few years from now, if you know what I mean.
Perhaps at least sketch out a vision for the Ultimate -- just a list of functions that it would do -- and keep that forest in mind as you chop or grow each tree?
That also gives additional criteria for how to do each additional step -- how to fit it into the Big Picture. ... I seem to be rambling at the keyboard, sorry. :?

(publish source)
Interesting idea, and the code would certainly be GPL, but since most of it will be drawn directly from NoScript (ABE rules parser) and RequestPolicy (chrome), there might not be much to publish. I haven't given it much thought.

Instinct here is to keep it to yourself until you have a working prototype. Else others start throwing conflicting and confusing ideas at you. (meaning code snippets, not the general picture that we're all discussing here.) Get a publishable model first, *then* solicit feedback.

Also, someone will fork the ideas, muck them up, and perhaps tarnish your name and reputation when it comes out.
Look at the users deluded into thinking that YesScript or ScriptNo are "NoScript equivalents". Yes, and my riding lawnmower is the equivalent of a Ferrari, almost. :P ... just more gut instinct.
By the way, my idea for the name is something like Application Boundaries Configurator for NoScript :). ABC would be used to (more easily) configure the boundaries, ABE would enforce them. Or is that too confusing?

Cute acronym, but too long.

OMG.... I let the "parallel processor" of the mind (subconscious or preconscious; cf. how the chemical structure of the benzene molecule was discovered) run for a few seconds, and came up with this: (drum roll)

ABE Linkin'

Sometimes I scare myself... time to bow out graciously. 8-)
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/3.6.28

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Integrating ABE with RequestPolicy

Post by Thrawn » Thu May 03, 2012 6:55 am

Tom T. wrote:If you can do it on a step-by-step basis, then very well, of course. I'd just hate to see you "painted into a corner" a few years from now, if you know what I mean.
Perhaps at least sketch out a vision for the Ultimate -- just a list of functions that it would do -- and keep that forest in mind as you chop or grow each tree?
That also gives additional criteria for how to do each additional step -- how to fit it into the Big Picture. ... I seem to be rambling at the keyboard, sorry. :?


Vision at this point is:
  • Iteration 1: RP-style feedback of which ABE rules are active on the current page. This is something that would be useful to have, regardless of whether RP gets replaced. My earlier post in this thread suggested a possible color-coding. Not sure about handling different request types (GET, POST, INCLUSION), but any amount of feedback is a good start.
  • Iteration 2: Generating rules based on what's active on the current page. I'm thinking that this would have to pop up a dialog window, to handle the complexity of ABE's rule language; base-level domain vs full domain vs full URL etc (on source and destination), GET vs POST vs INCLUSION etc, Accept vs Anon vs Sandbox vs Deny vs Anon+Sandbox...
  • Iteration 3 (optional): Full replacement of RP behavior, including temporary permissions, user-friendly redirect handling, and prefetch control.

Tom T. wrote:(publish source)
Look at the users deluded into thinking that YesScript or ScriptNo are "NoScript equivalents". Yes, and my riding lawnmower is the equivalent of a Ferrari, almost. :P ... just more gut instinct.


Yeah...there's not much to say on that topic that hasn't been said. Perhaps 'NoScript wannabes' is more descriptive.

Tom T. wrote:
Thrawn wrote:By the way, my idea for the name is something like Application Boundaries Configurator for NoScript :). ABC would be used to (more easily) configure the boundaries, ABE would enforce them. Or is that too confusing?

Cute acronym, but too long.


OK, how about something like Simple ABE Rules?

That helps to choose the icon, too :). And it's about cutting through the text-editing to execute changes swiftly, right?
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0

Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Integrating ABE with RequestPolicy

Post by Tom T. » Thu May 03, 2012 9:35 am

Thrawn wrote:Vision at this point is:
Iteration 1: RP-style feedback of which ABE rules are active on the current page.

I must be misunderstanding. By default, there are *no* ABE rules "active" on any given page, other than the default SYSTEM rule to enforce WAN/LAN boundaries. Which was ABE's main raison d'etré, after which it was realized that it could be used to create the site-specific permissions that more and more users were wanting.

I had thought that one of the principal goals of your project was to help the lower-tech user, who cannot write ABE rules, by offering automated suggestions for rules. These users would have no rules beyond the default. Tech-savvy users would appreciate the convenience of your tool, but they *can* write their own.
Please explain to me where I'm not grasping the concept correctly, thanks.

Thrawn wrote:
Tom T. wrote:
Thrawn wrote:By the way, my idea for the name is something like Application Boundaries Configurator for NoScript :). ABC would be used to (more easily) configure the boundaries, ABE would enforce them. Or is that too confusing?

Cute acronym, but too long.

OK, how about something like Simple ABE Rules?

That helps to choose the icon, too :). And it's about cutting through the text-editing to execute changes swiftly, right?

I should have realized that my idea wouldn't fly outside the US, even though Giorgio has a photo of former POTUS Abraham (Abe) Lincoln in the blog post in which he announced ABE.

Abe Lincoln presided over the Union during the bloody US Civil War (1861-1865), which was principally about the desire of agricultural Southern states to continue the institution of slavery that had been created by the colonizing British, Dutch, French, Portuguese, and Spanish, whereas the more industrialized Northern states sought abolition. Lincoln issued his famous Emancipation Proclamation during said War, and paid for it with his life, from a disgruntled assassin's bullet.

Hence the pun on "ABE Linkin'". .... ok, don't mix comedy and tech. :?

SABER is a cool acronym with a logical expansion. Fine with me.
Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Integrating ABE with RequestPolicy

Post by Thrawn » Sun May 06, 2012 11:41 am

Tom T. wrote:
Thrawn wrote:Vision at this point is:
Iteration 1: RP-style feedback of which ABE rules are active on the current page.

I must be misunderstanding. By default, there are *no* ABE rules "active" on any given page, other than the default SYSTEM rule to enforce WAN/LAN boundaries. Which was ABE's main raison d'etré, after which it was realized that it could be used to create the site-specific permissions that more and more users were wanting.

I had thought that one of the principal goals of your project was to help the lower-tech user, who cannot write ABE rules, by offering automated suggestions for rules. These users would have no rules beyond the default. Tech-savvy users would appreciate the convenience of your tool, but they *can* write their own.
Please explain to me where I'm not grasping the concept correctly, thanks.


OK, so if all that you have enabled is the default rule, then iteration 1 won't do much for you. However, if you have added extra rules, like the NAT Pinning defence, or anything specific to your needs, then this will present a more readable and itemised summary than the usual ABE notification. Iteration 2 will then extend that interface, allowing you to modify the rules and/or add more.

Tom T. wrote:I should have realized that my idea wouldn't fly outside the US, even though Giorgio has a photo of former POTUS Abraham (Abe) Lincoln in the blog post in which he announced ABE.

Abe Lincoln presided over the Union during the bloody US Civil War (1861-1865), which was principally about the desire of agricultural Southern states to continue the institution of slavery that had been created by the colonizing British, Dutch, French, Portuguese, and Spanish, whereas the more industrialized Northern states sought abolition. Lincoln issued his famous Emancipation Proclamation during said War, and paid for it with his life, from a disgruntled assassin's bullet.

Hence the pun on "ABE Linkin'". .... ok, don't mix comedy and tech. :?


Well, I was familiar enough with Abraham Lincoln to recognise the reference and know that he was a US President. Not sure how the 'linkin' part ties in to this addon, unless you were referring to the fact that it will link ABE to what is basically RequestPolicy's interface?

'ABE Linkin' is clever, but I think it's over my head.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:11.0) Gecko/20100101 Firefox/11.0

Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Integrating ABE with RequestPolicy

Post by Tom T. » Mon May 07, 2012 12:52 am

Thrawn wrote:
Tom T. wrote:
Thrawn wrote:Vision at this point is:
Iteration 1: RP-style feedback of which ABE rules are active on the current page.

I must be misunderstanding. By default, there are *no* ABE rules "active" on any given page, other than the default SYSTEM rule to enforce WAN/LAN boundaries. Which was ABE's main raison d'etré, after which it was realized that it could be used to create the site-specific permissions that more and more users were wanting.

I had thought that one of the principal goals of your project was to help the lower-tech user, who cannot write ABE rules, by offering automated suggestions for rules. These users would have no rules beyond the default. Tech-savvy users would appreciate the convenience of your tool, but they *can* write their own.
Please explain to me where I'm not grasping the concept correctly, thanks.

OK, so if all that you have enabled is the default rule, then iteration 1 won't do much for you. However, if you have added extra rules, like the NAT Pinning defence, or anything specific to your needs, then this will present a more readable and itemised summary than the usual ABE notification. Iteration 2 will then extend that interface, allowing you to modify the rules and/or add more.

Fair enough. v1.0 is for the techies, who should be the first to try it out anyway. v2.0 helps lower-tech uses to add ABE rules, correct?
Sounds good. :)

Thrawn wrote:
Tom T. wrote:I should have realized that my idea wouldn't fly outside the US, even though Giorgio has a photo of former POTUS Abraham (Abe) Lincoln in the blog post in which he announced ABE.

Abe Lincoln presided over the Union during the bloody US Civil War (1861-1865), which was principally about the desire of agricultural Southern states to continue the institution of slavery that had been created by the colonizing British, Dutch, French, Portuguese, and Spanish, whereas the more industrialized Northern states sought abolition. Lincoln issued his famous Emancipation Proclamation during said War, and paid for it with his life, from a disgruntled assassin's bullet.

Hence the pun on "ABE Linkin'". .... ok, don't mix comedy and tech. :?

Well, I was familiar enough with Abraham Lincoln to recognise the reference and know that he was a US President. Not sure how the 'linkin' part ties in to this addon, unless you were referring to the fact that it will link ABE to what is basically RequestPolicy's interface?

Yes, exactly. ... and that sites (links, URLs) will present an easy UI for the user to add rules.

Sometimes we comedians will stretch rather far to make a pun... I had best not quit my day job. :lol:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/12.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Integrating ABE with RequestPolicy

Post by Thrawn » Wed May 16, 2012 1:49 am

Just a note: Giorgio's recent reminder about the primary purpose of ABE, ie CSRF protection, makes me think that in addition to RequestPolicy-style lists of blocked destinations, the SABER menu should display and allow editing of the protections around the current site. So, you go to your bank, you look at the SABER menu, and it tells you that this site is only accepting requests from itself, or only itself and other subdomains, etc.
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0

Tom T.
Field Marshal
Posts: 3620
Joined: Fri Mar 20, 2009 6:58 am

Re: Integrating ABE with RequestPolicy

Post by Tom T. » Wed May 16, 2012 9:07 am

Sounds good!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.28) Gecko/20120306 Firefox/12.0

User avatar
Thrawn
Senior Member
Posts: 3106
Joined: Mon Jan 16, 2012 3:46 am
Location: Australia
Contact:

Re: Integrating ABE with RequestPolicy

Post by Thrawn » Tue Aug 13, 2013 3:59 am

In case anyone is interested: due to lack of development time thus far, a different scope has been proposed. Instead of providing a full RP-style interface (at least initially), SABER would instead aim to provide a simple interface for writing rules that would apply to all whitelisted sites, all blacklisted sites, etc.

So, for example, you could produce rules such as:

Code: Select all

Site <all permanently whitelisted sites>
Accept from <all permanently whitelisted sites>
Anon from <all temporarily whitelisted sites>
Deny

Site <all temporarily whitelisted sites>
Accept from <all permanently or temporarily whitelisted sites>
Anon

Site ALL
Deny from <all blacklisted sites>
Anon from <all non-whitelisted sites>

This should be much simpler to code, since it will not require the complex dynamic menus of NoScript or RequestPolicy. It will merely need to provide a dialog for the user to choose what kind of rules they want, then watch the NoScript preferences and update ABE rules whenever the whitelist or blacklist changes.

Anyone's thoughts?
======
Thrawn
------------
Religion is not the opium of the masses. Daily life is the opium of the masses.

True religion, which dares to acknowledge death and challenge the way we live, is an attempt to wake up.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0

Post Reply