InformAction Forums

I've a site in the trusted list (let's call it www.mystrustedsite.com) recently it added to its page scripts something like on a mousehandler tag... that code runs, and data is sent to nottrustedsite.com since i cannot forbid javascript execution on www.mystrustedsite.com.

So i wrote a stupid ABE rule: And it works, but it relys on the fact that the domain of the not trusted site will never change so i wanted to write a rule that would forbid www.mytrustedsite.com scripts from getting data from outside.. but didn't get any result: The script loads and the GET to www.nottrustedsite.com runs. Anyone can help me?

There is a way to formulate such a policy with multiple rules:
________________________________________________

It might be useful to have rules keyed to origin in addition to destination, Giorgio?
This is more intuitive.

al_9x wrote:There is a way to formulate such a policy with multiple rules:

Code: Select all

Site .trusted.com {list of other domains trusted.com can load resource from}
Accept INC from .trusted.com

Site ALL
Deny INC from .trusted.com

Thank you i understand now how it works.

al_9x wrote: It might be useful to have rules keyed to origin in addition to destination, Giorgio?

Code: Select all

Origin .trusted.com
Accept INC to SELF++ {some other sites}
Deny INC

This is more intuitive.

Altough something like that would be much more intuitive to reaad and write

Yes, that would probably be more intuitive for this kind of usages which, although, are a bit of a stretch in the context of the original scope of ABE, i.e. anti-CSRF protection.
Even if I recognize the advantages in terms of readability in this "generic blocker" pattern usage, I'm against adding more complexity to the grammar (making prepositions like "from" and "to" significant) and, more in general, to multiply the ways the same thing can be accomplished (which would also exponentially increase the complexity of adding UIs or automate analysis tools on top of these rules, which are some of the things planned in the long term).

Giorgio Maone wrote:I'm against adding more complexity to the grammar.

Compare the two approaches above, to the user this reduces complexity.

Giorgio Maone wrote:(which would also exponentially increase the complexity of adding UIs or automate analysis tools on top of these rules, which are some of the things planned in the long term).

Per site (i.e. origin) configuration is a very logical and intuitive way to think of these types of permissions. It was requested numerous times for script blocking. If you were making a UI for ABE I would think it would be included. And if so, it would benefit from origin rules, which will express per site UI in a human readable manner. Otherwise, if you think of ABE more as a minimalist RISC instruction set for tools to use, it will become unreadable.

I think ABE should strive to be human friendly (CISC), and accommodate common human thought patterns, rather than merely the needs of a hypothetical "compiler." Obviously you can go overboard with "friendliness," but something that can turn multiple unintuitive rules into a single intuitive one, I think is worth it. It's quite likely that if origin rules existed and the OP saw some examples, he would have figured it out, without posting.