Allowing a script to run only on certain sites?

[Acleacius]

Thanks for all your hard work, NoScript Team!


In an effort to be more secure I was wondering if it's possible to only let, google-analytics.com only run on certain sites? From what little I understand this script is responsible for allowing websites to Track and Get Credit for Visits, so only sites I Trust and Support do I want to let this script run.

Since I'm a n00b at this, Is there any way to make this automatic and are there any/many downsides to helping the sites you support like this?


Thanks for any tips or help.

[Tom T.]

This capability will become much easier in the next-generation NoScript, 3.x.

In the meantime, this FAQ tells you how to use the ABE feature in NoScript to do just that, and even specifically mentions google-analytics. If you cannot make it work for you, please post back, and someone will help.

Here is some general information about what G-A collects and reports on you, including some privacy issues, so that you can decide for yourself how many sites you wish to allow this at.

I hope this helps. And thank you for your kind words.

[Acleacius]

Thanks for your reply Tom T.

Should I see google_analytics.com allowed once I write the rule? Since I'm a n00b if we just take approval for one site att for, friends.com would this be correct? Currently with this setup, I do not see google_analytics.com allowed in the drop down menu on friend.com.
# google-analytics.com rule
Site google-analytics.com *.google-analytics.com
Accept from friend.com *.friend.com
Deny

If the site name is actually http:/www.friend.com do I need the www. like so?
# google-analytics.com rule
Site google-analytics.com *.google-analytics.com
Accept from http:/www.friend.com *.friend.com
Deny


Thanks for any tips.

[Tom T.]

Note: I broke the syntax on all the http links, because it seems there's actually a site at friend.com, and it looks to be a spammy kind of site, undoubtedly catching a lot of people who use it as an example. No reason for us to raise their search-engine rankings. (There is an approved site of http://www.example.com, set aside by the Internet Assigned Numbers Authority, or IANA, for exactly that purpose. If you go there, it will try to redirect you to the IANA page explaining exactly that, which is safe, if you're curious:

... we maintain a number of domains such as EXAMPLE.COM and EXAMPLE.ORG for documentation purposes. These domains may be used as illustrative examples in documents without prior coordination with us.

But friend.com and foe.com are more descriptive here, so no problem -- I just took out one front-slash.

Should I see goggle_analytics.com allowed once I write the rule?

From the linked FAQ:

Notice that since ABE's rule work independently from NoScript's permissions, you need to "Allow google-analytics.com" in NoScript's menu for the above to work.

That means, "yes". -- Clarify: You won't *see* it allowed in NS merely by writing the ABE rule; you must allow it yourself, else NS would block it regardless of ABE.

Since I'm a n00b if we just take approval for one site att for, friends.com would this be correct? Currently with this setup, I do not see goggle_analytics.com allowed in the drop down menu on friend.com.
# google-analytics.com rule
Site google-analytics.com *.google-analytics.com
Accept from friend.com *.friend.com
Deny

You followed the template perfectly. As for the menu, see above: G-A must be added to your whitelist. Else, you'd need to temp-allow it at friend.com, which you could certainly do, but that's defeating the purpose of automating this. Make sense?

If the site name is actually http:/www.friend.com do I need the www. like so?
# google-analytics.com rule
Site google-analytics.com *.google-analytics.com
Accept from http:/www.friend.com *.friend.com
Deny

No. The first part of that, http:/www.friend.com, will allow only script sources whose origin matches that exactly. But the second part of that (*.friend.com) negates that, and allows anything ending in friend.com. So it depends on your goal.

Real World example, although it's the opposite of yours, and is about NoScript, but you'll see the principle:

I use Yahoo Mail. Its minimum scripting requirements for basic features are mail.yahoo.com and mail.yimg.com.

I *could* allow yahoo.com and yimg.com, which are actually default-allowed, along with yahooapis.com, so that non-tech users can access most Yahoo services "out of the box", with no configuration. But then, there is an annoying redirect to Yahoo's home page every time I log out of e-mail.

By restricting NoScript's whitelisting to mail.yahoo.com, it prevents all scripting from http:/www.yahoo.com (the parent site) and all other Yahoo sub-domains, such as finance.yahoo.com, news.yahoo.com, etc., because they don't match the allowed pattern. If I visit those, I don't want their scripting, or if I need it for something specific, I'll T-A it.

Therefore, in Yahoo mail, I see in NS menu that scripting is blocked (the choice to allow or temp-allow appears) from yahoo.com, yahooapis.com, updates.yahoo.com, and others -- none of which I want, except on rare occasions.

Similarly, at finance.yahoo.com, I see that script source blocked in the menu. Etc.

So:

If you wish to allow G-A at friend.com and all sub-domains of friend.com, use your first rule. That's also a reason why the * (wildcard) is there -- so that all URLs that end in friend.com will be allowed. Weather.friend.com, sports.friend.com, etc.

If you wish to allow it at only the parent site, then http:/www.friend.com would restrict the permission to that exact URL.
If you wish to allow it at only one or more sub-domains, then do as I did with NS: specify the sub-domain(s).

Code: Select all

Accept from sports.friend.com *sports.friend.com

This allows all G-A scripting at sports.friend and its own sub-domains (4th level by now), such as tennis.sports.friend.com, but denies http:/www.friend.com.

How's that?
Give it a shot and see how it works. You can always delete any ABE rule if there's an error.

Thanks for any tips.

You're very welcome.
Please let us know if you encounter any problems -- and also let us know if you're successful, so that we can mark the topic as Resolved.