Site must be allowed for ABE rules to work?

[F-3000]

Code: Select all

# User-defined rules. Feel free to experiment here.
# facebook.com containment rule
# This rule allows Facebook scripts objects and frames to be included only
# from Facebook pages
Site .facebook.com .fbcdn.net
Accept from .facebook.com .fbcdn.net
Deny

If I don't have facebook on whitelist, JS on facebook doesn't work at all, regardless that I have abovementioned ruleset in place. Earlier it did work, although I was given a notify all the time on top of the browser when browsing FB, thus I whitelisted FB. I found out this behavior when I began to search a reason for why further added rules didn't allow a site to run JS. Is this by purpose?

[GµårÐïåñ]

Yes, in order for the ABE module and rules to execute and control what happens, the domains in question need to be allowed in the NoScript interface. So if you want some rule to control xyz.com xyzcdn.com etc, then you need to allow them and then control them through ABE. Hope that helps. Whether or not that will change in later incarnations, not sure, but as it stands now and has been for a while, it needs to be this way.

[al_9x]

ABE can already go beyond network request filtering with the Sandbox action, so it would not be unreasonable to augment the Accept action or introduce an Allow action to allow the request and scripting from ABE.

[F-3000]

Thanks for the clarify, Guardian. As I said, earlier it wasn't required for a site to be whitelisted for ABE to kick in, thus I was a bit confused about what's going on.

[al_9x]

earlier it wasn't required for a site to be whitelisted for ABE to kick in

ABE can block (and always could) any network request, irrespective of whether the domain of the request is white-listed for scripting.

What ABE can not do is script allow a domain for requests it explicitly accepts. And now that I've thought about it, it wouldn't make any sense to fiddle with the script whitelist from ABE rules.

[GµårÐïåñ]

Thanks for the clarify, Guardian. As I said, earlier it wasn't required for a site to be whitelisted for ABE to kick in, thus I was a bit confused about what's going on.

You are welcome. ABE doesn't require whitelisting in ALL situations, but if there are scripts and some other resources that are part of that rule for management, then yes, you need to whitelist it. If your rule is complete and all inclusive, then whitelisting it won't matter as the rule would control all aspect of it. But if for any reason your rule is not complete or tight enough, make sure you take a close look before you run with it.

[keving]

it used to be noscript was seemless the updates.

today, i found a majority of my sites cannot fully load.

there's no direction on the update how to make this work. so noscript is disabled now sadly. I trusted it for so long and now its not apparent how to make this work correctly.

NoScript 2.1.2.4rc6

[GµårÐïåñ]

it used to be noscript was seemless the updates.

today, i found a majority of my sites cannot fully load.

there's no direction on the update how to make this work. so noscript is disabled now sadly. I trusted it for so long and now its not apparent how to make this work correctly.

NoScript 2.1.2.4rc6

This is not the right topic for this issue and you should open a new topic for it under "NoScript Development" or "NoScript Support" forums. However, just quickly and without getting off topic too much, I am not sure what you mean by update. If you mean update as in when the new version is available, then it does do it unless you have done something under your about:config to affect how addons are updated, then its not a NS issue. If you want to install the latest build without waiting for the AMO/Fx automatic update, then you have to do it manually from the NoScript.net website, and that's normal. If you mean update as in the page loading, then you need to check your settings and other addons that might be interfering. You can save your settings and then use "Reset" to try again and see if it fixes it. If not then you can begin by testing those sites inside a clean profile with just NoScript and see if the issue occurs. Chances are it won't and in that case you need to do Standard Diagnostic to figure out what else is causing your issue, again not a NS issue. If you have something more specific or detailed as to where, what, how, then post it in the proper forum as a new topic and we will take a further look as to the why.

[F-3000]

You are welcome. ABE doesn't require whitelisting in ALL situations, but if there are scripts and some other resources that are part of that rule for management, then yes, you need to whitelist it. If your rule is complete and all inclusive, then whitelisting it won't matter as the rule would control all aspect of it. But if for any reason your rule is not complete or tight enough, make sure you take a close look before you run with it.

If put simple, with example which I gave, whitelisting is required. Which was my point. My bad for expressing the whitelisting requirement too inclusive.

[GµårÐïåñ]

If put simple, with example which I gave, whitelisting is required. Which was my point. My bad for expressing the whitelisting requirement too inclusive.

Correct, simply put, the one you posted, you would have to whitelist

[F-3000]

Now, only if there was an option to have such a rule automatically added to ABE when whitelisting a site...

[GµårÐïåñ]

Now, only if there was an option to have such a rule automatically added to ABE when whitelisting a site...

Nothing concrete, so don't quote me on this, but for a while now there has been discussion on some incarnation of that behavior. So you never know, future infrastructure might resolve that on its own, it might become part of it, or some logic thereof, but its not in the cards right this minute, so be patient

[F-3000]

Not the easiest task as overall, I'd guess. Noscript.net works as nice example, with css-file that is loaded from informaction.com. I had to check source code for the page to ensure that.

[GµårÐïåñ]

Not the easiest task as overall, I'd guess. Noscript.net works as nice example, with css-file that is loaded from informaction.com. I had to check source code for the page to ensure that.

The difficultly that most people don't realize is that adding a rule to ABE automatically is not always advisable. I don't think I have seen two people who can agree on what is safe and what is not and what they like to see and don't see every time. This means that a rule that might work fine for one person won't do the trick for another and it creates a lot of confusion. So as for the rules themselves, I believe learning how to make them and doing them on your own is the BEST proactive approach rather than having them included by default. The reason is that one person might block facebook everywhere but allow access to it on the site itself. Ok, not that complicated, in fact a rule exists for that. However, consider this: USER_A plays 2 games, USER_B plays or uses 4 apps, and etc. Each one of those users would need a slight adjustment to their rule to allow access by those particular games/apps. Imagine how many millions of combinations would exist for just these two users given how many apps there are, try to adapt it for everyone? you think any logic will ever make that work?

So while creating general broad rules may be doable and consistently effective, once you factor in the users' behavior and individual needs, it becomes an unmanageable monster that only each user can handle for their own needs. There is no one size fits all rule that will give access to everything on facebook you would possibly need/want to do (just an example here, it could be any website) while protecting you from every single outside access to it as well without knowing individual habits, usage, needs, intervention and input. So at some point Giorgio has to balance convenience and automation versus the actual effectiveness and security provided by the tool and that means there will always be aspects of the security you will need to manage yourself, however tedious or painful it might be. Just some things to consider.

[F-3000]

How about this way:

There could be an option to have automatic ABE rule created each time when user whitelists a site, and included to that option is a field where user can edit the default rule that is used with the automation. Something like this...



This way, there would be the current way of behavior, and a possibility for further "complexity". And if a site has more sources for content than one, the user can always go and edit the rule manually. Yet, something like this would greatly simplify the restricted whitelisting.

Plus further "automation" could be by having one option more while whitelisting:
Allow [site] on [main site] only
Which would add [site] onto "Allow from" rule where "Site" contains [main site].