ABE user guide and NS possibly adding RP functions

[Tom T.]

[Split from Support issue of possible rogue script, as this thread became a more general discussion of how to prevent such things in the future, including NS possibly subsuming RequestPolicy-like functions, and making ABE more friendly to non-programmers. Was distracting from that original topic, which as of this split, has yet to be resolved -- Tom T.]

1. Legit site (yahoo, google, informaction, etc, etc) accepts to post ad code for client X

Gotcha.

2. Client X embeds a script inside its ad and when you allow legit site (the parent in this case) it will allow it to run the code

This is what surprises me. Yahoo, etc. allow a third-party ad to run scripts under Yahoo's permission? I hate to say this, but then how can NoScript possibly protect us if trusted sites will run third-party code in their own name? *Every* site we trust could do this, so... ??

The ultimate payload is not the parent, its the surrogate that got allowed by the parent by inheriting its permissions.

I don't understand how or why innoshot is allowed to inherit Yahoo's permissions. If true, then Yahoo is not at all trustworthy. And neither are Google or Ask. And apparently, either Bing, Lycos, etc. are more careful, or because their audience is smaller, innoshot did not attempt this technique on them.

And why would it spontaneously disappear from my machine and not from Montagar's?

So far I was happy to see that some of the thing Giorgio suggested were in line with what I presented as possibilities,

No one questions your technical knowledge and insights, Brother. I will try any investigation that you suggest, you know that. No, I'm not at all surprised that you and Giorgio considered the same possibilities. No one should be.

Yes, we're at risk from malicious programmers, but we count on NoScript and our other defenses to stop them. My question at the top was that apparently NoScript cannot stop them if the trusted sites are so foolish as to run their advertisers' code as their own and with their own (trusted) permissions.

[GµårÐïåñ]

This is what surprises me. Yahoo, etc. allow a third-party ad to run scripts under Yahoo's permission? I hate to say this, but then how can NoScript possibly protect us if trusted sites will run third-party code in their own name? *Every* site we trust could do this, so... ??

Exactly, this is why the site issued an apology because it was their job to vet the code as safe before putting up as their own code and serving it to trusting people. Unfortunately NoScript cannot do anything about this because when the parent is whitelisted, and the code is served by them, NS has no reason to doubt it and block anything. That is when having some good rules in ABE would protect you despite it all. Also having something like RequestPolicy would mitigate some of this because it blocks individual links to outside even within a trusted page, its an explicit 1->1 permission, otherwise???

I don't understand how or why innoshot is allowed to inherit Yahoo's permissions. If true, then Yahoo is not at all trustworthy. And neither are Google or Ask. And apparently, either Bing, Lycos, etc. are more careful, or because their audience is smaller, innoshot did not attempt this technique on them.

Bingo, this is why despite trusting any site, I ABE its components or RP them to make sure at no time they can suddenly grow a brain, be stupid and allow something that could hurt me just because I trusted them. I trust but take precaution, that's the best practice. The way I protect myself and it has yet (knock on wood) to get me any harm is to run my browser with the most restrictive permission, use NoScript in the most restrictive mode, run RP on top of it to further tighten the relationship, anything still left over, I use Adblock Plus to block them using direct or pattern blocking, I use JS view to keep an eye on any script that "might" get passed all that and I use custom GreaseMonkey scripts to strip those using patterns, I have a blacklist of the baddies in my host file, they are also explicitly blocked in JS/Image/Cache/Cookie areas and on top of that I have surrogate applications like Rapport checking for any screen capturing, keylogging, cookie hijacking, combination of all this, I am solid as it gets. I also run AV for good measure, regularly malware, usage cleanups, registry/startup tweaking, I use secure DNS that is not provided by my ISP, I manually configured my router for it. As I have said many times, security is proactive, trust everyone but trust no one, you know what the contradiction in that statement means.

And why would it spontaneously disappear from my machine and not from Montagar's?

it might have a life cycle expiration to keep it under the radar and unnoticed, like a hit and run type of metamorphic worm.

No one questions your technical knowledge and insights, Brother. I will try any investigation that you suggest, you know that. No, I'm not at all surprised that you and Giorgio considered the same possibilities. No one should be.

Oh my friend, I have no ego and am not vane, its not how I meant it. I meant there is a consensus of mind and logic which suggests that we are considering everything that could possibly be, not that we are somehow better than anyone. Oh my, I would never be that much of a douche, ever, not in my personality. I truly follow the principle of all for one and one for all.

Yes, we're at risk from malicious programmers, but we count on NoScript and our other defenses to stop them. My question at the top was that apparently NoScript cannot stop them if the trusted sites are so foolish as to run their advertisers' code as their own and with their own (trusted) permissions.

In all fairness, NoScript more than likely would have protected you even IF the script managed to access something. Because most likely it will need scripting of some kind unless its a pure post function and NS would have crippled it. The only part that is unnerving is that it could even be there somehow, that's all. Its like a thief getting into your place but not being able to crack the safe. You didn't lose anything but it feels bad that someone even got that close.

[Tom T.]

This is what surprises me. Yahoo, etc. allow a third-party ad to run scripts under Yahoo's permission? I hate to say this, but then how can NoScript possibly protect us if trusted sites will run third-party code in their own name? *Every* site we trust could do this, so... ??

Exactly, this is why the site issued an apology because it was their job to vet the code as safe before putting up as their own code and serving it to trusting people. Unfortunately NoScript cannot do anything about this because when the parent is whitelisted, and the code is served by them, NS has no reason to doubt it and block anything.

If you'll pardon my saying so, that is idiotic behavior on the part of Yahoo et al. They are risking their good name on unknown code, often supplied by an advertising agency, perhaps not directly from the advertiser but furnished by the evil site, or directly from badsite.com, but either way, a site that large can't possibly vet everything. Yahoo currently has relationships with more than 50 advertising agencies, plus whatever companies work directly with Yahoo and not through an agency. I trusted Yahoo *alone* and trusted NoScript to block all other parties on that page.

That is when having some good rules in ABE would protect you despite it all.

I know Giorgio has much on his plate, but it would be beautiful if he, or you, or someone could write a generic guide to ABE rules that *all* reasonably-aware users can follow, even if they are not programmers, just telling them what to look for and how to write the corresponding rule. That would be a great addition to NoScript FAQ and a sticky on this forum.

Also having something like RequestPolicy would mitigate some of this because it blocks individual links to outside even within a trusted page, its an explicit 1->1 permission, otherwise???

Shortly after RequestPolicy appeared, I e-mailed Justin and asked if an F2-friendly version was in the works. He was non-committal, but now that F2 is deprecated, obviously that's not going to happen. So another reason I'll have to ditch my neat, clean functional browser for the crayon-and-coloring-book one.

But if RP is *required* to fill in gaps like the above, that NS can't block, shouldn't NS subsume RP's functions into its own? So many users trust NoScript, and don't know that they *also* need RP for these "trusted" sites that hand out their names and permissions so freely. Just asking.

I don't understand how or why innoshot is allowed to inherit Yahoo's permissions. If true, then Yahoo is not at all trustworthy. And neither are Google or Ask. And apparently, either Bing, Lycos, etc. are more careful, or because their audience is smaller, innoshot did not attempt this technique on them.

Bingo, this is why despite trusting any site, I ABE its components or RP them to make sure at no time they can suddenly grow a brain, be stupid and allow something that could hurt me just because I trusted them. I trust but take precaution, that's the best practice. <snip> trust everyone but trust no one, you know what the contradiction in that statement means.

AHA! One of my extra precautions is to run the browser 100% sandboxed. The *sole* exception is to get updates from the (presumably trustworty) MZ updates, as with NoScript updates. So *how could this infection have escaped the sandbox", which is emptied every time I close the browser, which is very frequently. IIRC, I closed and re-opened the browser several times while successfully reproducing the issue.

And why would it spontaneously disappear from my machine and not from Montagar's?

it might have a life cycle expiration to keep it under the radar and unnoticed, like a hit and run type of metamorphic worm.

Why would mine have a different expiration? ... well, I guess we don't know when each of us picked this up, if that is in fact what happened. But it seems that Montagar's would have run its course by now.

In all fairness, NoScript more than likely would have protected you even IF the script managed to access something. Because most likely it will need scripting of some kind unless its a pure post function and NS would have crippled it. The only part that is unnerving is that it could even be there somehow, that's all. Its like a thief getting into your place but not being able to crack the safe. You didn't lose anything but it feels bad that someone even got that close.

Yes, I pretty much figured that, and have seen no signs of malware on the machine; no programs attempting to access the Internet, and I just did another thorough AV scan, with negative results.

[GµårÐïåñ]

Short response, I will do the guide and have Giorgio look over it and give his blessing and then I will give it to you to proof and edit and we can add it to the FAQ or sticky it here. As for taking over RP functionality, that is what my whole campaign towards having site-specific policy was for, this exact achievement of NS function and RP control (but keep in mind it would be far more unfriendly of a product at that point) but currently selectively trust with default deny is the best policy, RP just provides me a more granular control that I hope in time would come to NS. With introduction of ABE, we have that more than before and in the future it will become more domain specific and achieve what two or three tools are needed now to achieve.

[Tom T.]

Short response, I will do the guide and have Giorgio look over it and give his blessing and then I will give it to you to proof and edit and we can add it to the FAQ or sticky it here.

That is very generous of you to offer your time for that, my friend. I'll be happy to proofread. The more users who can fine-tune ABE, the better.

As for taking over RP functionality, that is what my whole campaign towards having site-specific policy was for, this exact achievement of NS function and RP control (but keep in mind it would be far more unfriendly of a product at that point)

Yes, I have just installed RP on my Fx 3.5.4. There is a learning curve just as with NS, but it shouldn't take long to become comfortable with it.

As for being a more unfriendly product, you are right, but one *possible* solution would be to make the RP-part of NS a user-configurable choice to enable. Default would be disable, with perhaps a first-run screen showing the choice to enable, either now or in the future. This way, newcomers to NS would not be even more overwhelmed; then down the road, as they become comfortable with "basic" NS, they could enable the RP-like portion of it for finer control. Just an idea, thinking out loud.

This also would be in line with the suggestions of several users to have "basic" and "advanced" versions of NS, although this way, they are all one version, which is much less work to maintain. Lower-tech users could stick with the present NS functions, while more advanced users gain the greater control that they would like. What do you think?

I see site-specific permissions as yet a separate aspect. RP does not control plugin or other executable content coming from the same page. The ability to fine-tune NS to allow Java only at sites A, B, C, and to allow Flash only at X, Y, Z, will further the goal of "configure each site once, and you're done there forever".

... RP just provides me a more granular control that I hope in time would come to NS. With introduction of ABE, we have that more than before and in the future it will become more domain specific and achieve what two or three tools are needed now to achieve.

That is the ideal. Fine-grained control per site, in one tool. Thank you for all you are doing to move towards that ideal, Brother.

If you feel that these posts should be split and moved to Development, feel free, as we have in fact gotten off the topic of the rogue script running as per OP.

[GµårÐïåñ]

I see site-specific permissions as yet a separate aspect. RP does not control plugin or other executable content coming from the same page. The ability to fine-tune NS to allow Java only at sites A, B, C, and to allow Flash only at X, Y, Z, will further the goal of "configure each site once, and you're done there forever".

No it does not, that's NS's function, hence why I use them all to some capacity but rarely to actually replace each other. What I like about RP is that no matter if the site is allowed, it will break down EVERY link to something outside for anything, image, flash, script, etc, and provides you a chance to explicitly allow. That gives more granular control in conjunction with NS's function.

[???]

Since the idea here is to get more granularity, if NS were to take on RP-type functions, one thing that would be an improvement would be to treat those functions in the same way NS treats other functions, i.e. with multiple domain levels possible per site. With RP one is stuck with whatever the global domain level is (base or full domain, or full address). So for the yahoo example, one can't allow requests from mail.yahoo.com, but only from yahoo.com or www.xx.xx*.mail.yahoo.com (or http://www.xx.xx*.mail.yahoo.com). So if there are multiple yahoo accounts being accessed from the same computer, you have to either allow what may well be too much or set the policy for every single yahoo account separately. And whatever you choose, every other site you visit must be set at the same level since it's a universal setting.

I really value RP. This is my one irk with it. I'm just waiting for it to offer more granular control (which is a tad ironic since it itself offers more granular control over the security offered by NS).

Note re: edits: can't seem to get the above to post correctly, the first Yahoo full address should be the full domain...
...and now it is working.

[Tom T.]

Since the idea here is to get more granularity, if NS were to take on RP-type functions, one thing that would be an improvement would be to treat those functions in the same way NS treats other functions, i.e. with multiple domain levels possible per site. With RP one is stuck with whatever the global domain level is (base or full domain, or full address). So for the yahoo example, one can't allow requests from mail.yahoo.com, but only from yahoo.com or http://www.xx.xx*.mail.yahoo.com (or http://www.xx.xx*.mail.yahoo.com).

Yes, I very much like the fact that with NS, I can forbid http://www.yahoo.com but allow mail.yahoo.com

So if there are multiple yahoo accounts being accessed from the same computer, you have to either allow what may well be too much or set the policy for every single yahoo account separately.

I'm assuming that you're referring to one user with multiple accounts, because if there were multiple users on the machine, presumably each would set up their own profile, which would include their own NS preferences.

If it is one user on several accounts, I'm not sure quite why you (I) would need different permission levels at different Yahoo accounts. I keep one for work, one for personal, and one for spam-magnet (buying things from merchants who might sell/rent/trade email addresses, etc.), but the permissions are the same at each: Namely, the minimum required for site functionality.

And whatever you choose, every other site you visit must be set at the same level since it's a universal setting.

I'm sorry, you lost me there. Not sure whether we're talking about Yahoo only or the entire web ("universal setting"), but both NS and RP allow you to apply their respective individual permissions at each different site (scripting in the case of NS; cross-site requests in the case of RP).

[???]

Sorry if my post was not exactly clear...

If it is one user on several accounts, I'm not sure quite why you (I) would need different permission levels at different Yahoo accounts.

It's not that one needs different permission levels; it's that at the more strict RP levels one has to duplicate permissions when the different accounts are at different sub-domains e.g., xx.xx.123.mail.yahoo.com, xx.xx.234.mail.yahoo.com, xx.xx.345.mail.yahoo.com, etc. If it was possible to create permissions for mail.yahoo.com in RP this somewhat ridiculous duplication would not be necessary. The alternative to duplication is to just create permissions for the most liberal level (yahoo.com) instead and be done with it, but that could allow in way more than "the minimum required for site functionality."

And whatever you choose, every other site you visit must be set at the same level since it's a universal setting.

I'm sorry, you lost me there.

i mean RP's strictness levels are all or nothing. If you choose base domain (say, if you're lazy about Yahoo in the above example!) then all sites' permissions must be done at that level, unlike NoScript where site A permissions could be set for the base 2nd level domain while site B permissions could be set for the full address and site C could be the full domain.

[Tom T.]

Thanks for the clarification. I think I understand you correctly now: Your complaint is not with NS, but with RP. And if NS assumes RP's functions, you'd like NS not to have that same glitch. Correct?

Since we don't know *if* NS will assume those functions, much less when, you might make a feature request (request for enhancement) to RequestPolicy allowing, for example, wild-carding. xx.xx. ***.mail.yahoo.com.

Also, for RP to follow NS's model of choosing selected levels of sub-domain for permissions. It might be a bit of work for Mr. Samuel, but I concur that it would be a valuable enhancement to RP. (Of course, we can't control or affect decisions about RP.)

[???]

YES! (On all counts)

[Tom T.]

Glad we got that straightened out.

I would fully expect that *if* NS assumes RP-like functions, there would be *at least* a level of granularity equal to the current NS choices. However, one of the major enhancements in the long-awaited NS 2.0 will be even further increases in fine-grained control of individual sites and permissions. Of course, we're all very eager to see this happen.

In the meantime, why not go ahead with your feature request to RP? You can link this thread. Please feel free to post any results here. Many NS users and most of the support team use RP anyway (they complement each other nicely), so I don't think it's off-topic to see whether RPs level of discrimination increases. Good luck!