Add ability to temporarily allow JS for list of url's

[Sam71]

Is there any way to have NoScript temporarily allow JS for sites from a list and then have NS remove them when we're done with that site? The removal might be something like a site specific removal of temporarily allowed items for that site only.

Example in order to use MS OWA (Office 365 online account) we need to allow JS for 11 different url's. But we have no reason to want JS to be allowed for those url's except when we use the MS OWA account. It'd be a real pain to manually add them each time we have to check that calendar, email etc. So we're forced to allow them all the time.

It would be good to have a script that could be run to allow JS for these 11 url's and then to be able to reverse & remove them when we close OWA page. Alternately even better would be an more automated way to have JS allowed ONLY for the MS OWA url. So when one logged into the OWA account the list of urls would be allowed and could be revoked as a group when we finish with that site.

So is there a way to do this already? If not, can we persuade NS experts to look into this? It would seem that such an option would improve everybody's security & privacy. If it exists already, please point me to a link on how to do this.

Thanks,
Sam71

[therube]

You can approximate that (your use case) with ABE.

ABE - Application Boundaries Enforcer

[barbaz]

A workaround is to ONLY visit the one site, Temp-Allow what's needed, & revoke temp permissions or restart the browser before visiting other sites.

Or use different profile for the one site & the rest of your web surfing (use `-no-remote -new-instance` command line parameters when starting the browser with any single-site profile, if you want to run more than one profile simultaneously).

[barbaz]

Oh, and see viewtopic.php?f=7&t=18846 for a similar sounding request.

[Sam71]

The Rule,

Thanks. ABE does look like a way to accomplish this limited allowing of a list of JS authorizations. Though it doesn't look quite as flexible as just feeding an "OK" for this site list in. And it looks more permanent than we might need.

If I read the links right, it would seem that to handle the 11 JS allowed urls, I would need 11 rules. That could get a bit "log winded" rather quickly, since a lot of sites seem to be using more and more external JS resources every day.

Also how does this affect using the temporarily allow for other sites where where we might need to allow JS temporarily for just some of the sites for which I have made rules? Would I even still see the allow temporarily option for them?

regards,
Sam71

[Guest]

barbaz,

Thanks for your reply. Routine operation would preclude running the browser on only one site at a time. And btw one of the hiccups with the current "revoke temporary permissions" NS command/option is that it gets rid of all permissions instead of just the ones specific to one site.

The idea of using multiple profiles & multiple non-connected instances may be a way to go. Though that still means a bit more machine load than just using new windows. And I would have to set everyone up with each of the specific non-connected instances. That's a bit more cumbersome than just providing list(s) to each machine for NS to access which can be easily sent to each user machine and stored in an appropriate folder.

I'll look at the link which you said sounds similar.

regards,
Sam71

[Thrawn]

But we have no reason to want JS to be allowed for those url's except when we use the MS OWA account.

You're missing the point. If these domains are safe, which they presumably are since you trust them with your webmail, then why do you need to block them everywhere else?

[Guest]

Thrawn,

Well there is really no trust involved here. Client situation(s) make it necessary to use the MS calendar. OWA & Office365 is an App situation that we need to use for certain clients. And MS webmail is not used for our main emails; just for this set of clients & circumstances. We are stuck having to accept that maybe MS won't screw up its own scripts or if it does MS itself won't call the vulnerabilities it may have left in them. Which does not come close to "trusting" MS or their scripts.

And so just because we have to put up with the risks associated with MS JS for this does not mean that we have any reason to do so globally. imNSho any site that relies on external JS is just too cheap & inconsiderate of their clients/visitors safety to write their own JS script routines. And what I have seen in the last 2-3 months since we have had to allow MS scripts for this has been an ever increasing use of external scripts by MS. It changes without any warnings to their users, but the number being called never goes down. So is MS trying to "train" clients to allow JS globally. Which certainly doesn't seem to be in the client's interest.

But we have to use this OWA Office 365 and even switching to Linux wouldn't change that. So I'm trying to make using it & other sites less than desirable peculiarities the safest, least irritating, least dangerous that I can.

Didn't intend this to be a rant or anything like that. But the way many sites are being written today is not all that good. But on the good side Flash has finally started to be recognized as being undesirable. The disappointing surprise was that it has taken so long for a plugin/program that makes over 11 to 17 major vulnerabilities every year to finally fall out of favor.

regards,
Sam71

[Thrawn]

Which does not come close to "trusting" MS or their scripts.

Well, not to put too fine a point on it, but if you whitelist their scripts - anywhere - then that does constitute trusting them. I appreciate not liking it - I wouldn't like it either - but you're doing it.

The point I'm making is that you aren't really gaining security by trying to block them everywhere else. Privacy, maybe, or saving bandwidth; but those are not primary features of NoScript.

Besides ABE, you can try RequestPolicy, or Policeman, or uMatrix; it's a matter of trading off inconvenience vs the privacy/bandwidth benefit.

[therube]

I basically agree with everything Sam71 (guest) posted [2 posts up].

you aren't really gaining security by trying to block them everywhere else

Why not?

I go to http://slickdeals.net/.
I don't trust it, but I use it.
To use it - in a meaningful manner, I also need to "trust" (Allow) slickdealscdn.com.

Now what are the probabilities that whatever might come from slickdealscdn.com might also turn up on malwaresite.com? (IOW malwaresite.com calls slickdealscdn.com, & slickdealscdn.com happens to harbor malware.)

Very little, I would think.

Even so, if I'm going to Allow slickdealscdn.com, why not limit its scope (using ABE) to ONLY slickdeals.net?


Now suppose instead of slickdealscdn.com it was cdnjs.cloudflare.com?

So if I want to use slickdeals - meaningfully, I've got to allow cdnjs.cloudflare.com.
I certainly do not want to allow cdnjs.cloudflare.com anywhere else, so ABE can handle that for me, making me safer - no?

And why should these funky domains MS is using be thought of any differently?


(I don't use ABE, instead just do the extra clicks need to [temporarily] allow/revoke when/where needed, but it would make things "easier", & I would think safer too, if I did use ABE.)

[barbaz]

Isn't something like this coming in NoScript 3 anyway?

[Thrawn]

I go to http://slickdeals.net/.
I don't trust it, but I use it.
To use it - in a meaningful manner, I also need to "trust" (Allow) slickdealscdn.com.

So you do trust it.

If you thought that it would attack your computer, you wouldn't whitelist it at all.

if I'm going to Allow slickdealscdn.com, why not limit its scope (using ABE) to ONLY slickdeals.net?

Oh, I'm not saying that such a restriction is bad. I'm in favor of it. It's just not core to NoScript, because it doesn't really add security.

I certainly do not want to allow cdnjs.cloudflare.com anywhere else, so ABE can handle that for me, making me safer - no?

CDNs are a trickier case, true, since they serve whatever they're told to serve.