Why must I "Temporarily allow all this page" REPEATEDLY?

[Thrawn]

You know what would be awesome is if there was a "Temporary Allow All Scripts", which would be like "Allow Scripts Globally" except that you don't need to switch it back on. It does so automatically when you leave the site. There are many times we simply want *everything* to load for whatever site we're visiting, without the inconvenience of repeatedly allowing all on page all the way down the chain of scripts until the site starts working correctly, or having to turn Allow Scripts Globally on and off (and having to allow it for all other tabs isn't desired in this case).

Now you may say to blame this on the "trend" in websites or that the (hypothetical) risks are the same in both cases (site gets compromised or whatever), and that's true, but also irrelevant. The "Allow Scripts Globally (dangerous)" is there for a reason, no? Of course it's insecure. Of course it defeats the purpose of NoScript. But that is the end-users' prerogative.

I think that Allow Scripts Globally is useful for:

• Installing NoScript for non-tech-savvy users who just wouldn't be able to use it in a restrictive mode;
• diagnosing obscure errors such as the one at viewtopic.php?f=7&t=8966;
• using NoScript in click-to-play mode.

The fact that cascading 'allow all this site' would be as dangerous as Allow Scripts Globally is highly relevant. That feature already exists. The use case that you're describing is an adblocking use case, which ABP already supports, but it isn't appropriate for NoScript. Certainly not worth taking Giorgio's valuable time away from bugfixes, NoScript 3.x for the desktop, Android-native interface for NoScript Mobile, etc.

[Guest]

The fact that it's dangerous is not relevant in terms of criteria for the inclusion of a usability feature such as this, otherwise what is "Allow Scripts Globally' there for? Not safety, but convenience (and testing, I guess, but I'm talking about why users normally use it).

I know this isn't commercial software, and maybe you're just doing it as a hobby and don't care much about meeting the needs of your users, and that's cool, I'm not entitled to anything but opinion (which you can ignore), but if you are making this for others, and not just for a small group of like-minded individuals, then I think listening to your users and trying to meet their needs should be a priority, logically. It's possible this feature doesn't have enough demand or isn't worth spending time on, but that's a different argument than the one you're making.

My own personal use case has nothing to do with ad blocking or allowing (I use ABP anyway). Assuming use cases doesn't seem like a good software design practice either. Or maybe I'm wrong, I'm not a programmer. My personal case is about site functionality. As we all know, turning off javascript breaks tons of sites (that's kinda the point), and usually, temporarily allowing the top-level site is enough, but sometimes there's a chain of third party scripts and the desired functionality is multiple levels deep. Yes, it's terrible site design and not NoScript's fault. Who cares. Things like NoScript exist because of all the bad stuff out there. This is a feature request, not a bug report. You don't need to get defensive and your point of view, even if completely valid, doesn't make my NoScript experience any better. However, adding this one little extra option to the menu would.

Globally allow is not the same. That is a permanent switch that you must flip back off when you leave the site and it affects all tabs/windows in the meantime.

[Guest]

P.S. I'm aware you (Tom) are not Giorgio but based on your comments and tone it felt like I was talking to the developer, so excuse the use of "you" in there.

[Guest]

Damn, not Tom, I mean Thrawn. You both have the geek code stuff.. sorry.

[GµårÐïåñ]

Let me make this clear so that any idiot can understand. When you tell it to allow all on the page, at the time you say that, it allows ALL that is there. Now if upon doing so the site decided to add even more to the mix, then unless the application has ESP of some kind, it didn't know they existed until now, so you have to do it again for it to do the ones it sees on the list now. Now again if the greedy site that you ignorantly just allowing to do whatever on adds more to the list then you do it again. It makes perfect sense and if you used our brain for a second you would realize the function is performing as stated and per specs. Its the SITE that is adding more and more to the mix resulting in this. What do you suggest, you click once and the application just allows, refresh, allows, refresh and just go into an eternal automated loop until all is allowed when you can just as easily just use global, since you are not doing squat to protect anything, so you might as well and be done with it? Some sense of reasonability, common sense and non-optional use of a brain is required or don't use the tool.

[Thrawn]

I think Guardian's point can be summarised as follows:
The suggested approach - "I agree to everything, now just work!" - is a misuse of NoScript.

On a different note, those who want to allow/deny scripts based only on top-level site (which I can't recommend, but seems popular) may be interested in the Tab Permissions and Host Permissions addons.

ETA: Actually, after some more thought, I can see one scenario in which it might be reasonable to make trust decisions in NoScript based on the top-level site: when using RequestPolicy. That way, you could use NoScript to manage permissions for the top-level domain, but leave the management of third-party scripts to RP, instead of the current situation of having to first allow the cross-site request in RP, then allow the script execution in NS. But I suspect that to support such a mode in the NoScript engine would take a lot of rework, and RP users are likely to be willing to make an extra click anyway.

[Guest]

GµårÐïåñ, I understand that. Let me make this clear so that any moderately intelligent individual can understand. This is not a bug report. I am not saying NoScript does this when it should do that. I am suggesting an additional feature that would improve my NoScript experience. Not your experience. I don't know about that, and you don't know about mine.

What I am suggesting is simply allowing all scripts to run that are directly or indirectly called by the page you are currently viewing. In order words, temporarily allow all scripts BUT not globally. Restrict it only to the current webpage. Reloading in between would not be a real solution. There should be a way for NoScript to tell where a script is being called from.

I don't understand what's so hard to understand about this request. If it's not technically feasible, that's one thing, but it seems like you guys are more interested in ideology.

Anyway, I'll leave it at that. Thanks for listening.

[GµårÐïåñ]

This has been extensively discussed and it is YOU who seems to not understand why and what is being said, so let me just say that it is as-is and you need to make due with it or just run in globally allow. Simple as that.

[Thrawn]

This has been extensively discussed and it is YOU who seems to not understand why and what is being said, so let me just say that it is as-is and you need to make due with it or just run in globally allow. Simple as that.

Or try Tab Permissions. Seriously, it may be what you want: permissions based exclusively on top-level site.

[GµårÐïåñ]

Or try Tab Permissions. Seriously, it may be what you want: permissions based exclusively on top-level site.

Or that, there is plenty already there that its getting old people asking for some kind of magical behavior on their "lazy" or "non-grasping the concept" behalf.

[Guest]

NoScript has become overwrought and extremely burdensome. If I indicate that "allow all this page" it should not be necessary to hunt for elements that Noscript is still blocking and then allow them one by one--each time needing to wait for the page to reload . In the beginning it was a really good program. Now it is just too much to be bothered with. Too bad.

[Jim Too]

NoScript has become overwrought and extremely burdensome. If I indicate that "allow all this page" it should not be necessary to hunt for elements that Noscript is still blocking and then allow them one by one--each time needing to wait for the page to reload . In the beginning it was a really good program. Now it is just too much to be bothered with. Too bad.

"Eternal vigilance is the price of security"

You can allow scripts globally if you "know" no unexpected script will run.

[GµårÐïåñ]

NoScript has become overwrought and extremely burdensome. If I indicate that "allow all this page" it should not be necessary to hunt for elements that Noscript is still blocking and then allow them one by one--each time needing to wait for the page to reload . In the beginning it was a really good program. Now it is just too much to be bothered with. Too bad.

Security is proactive and you need to put in your effort, you want easy and lazy then go with our blessing and run without it. But when you get compromised, look in the mirror for someone to blame. Good riddance.

[Guest]

Guardian! Snap out of it! The purpose of a 'forum' is to exchange concerns and ideas. Noone should be berated & be-littled for doing so here.

[GµårÐïåñ]

Guardian! Snap out of it! The purpose of a 'forum' is to exchange concerns and ideas. Noone should be berated & be-littled for doing so here.

The people who think security should be easy and not complicated need to snap out of it, per your own position, I expressed my position and it can be taken or left. NO one is belittled or berated until they whine about why a tool protects their security so well that they need to take some action. People need to get realistic, either take the protection or go with something that is not as good and take your chances, simple as that. At least I don't post anonymously, I stand by what I say, can you say the same "Guest"? Anytime you want to come down from Burbank area to Pasadena for a cop of coffee so I can tell you in person, let me know, I'll buy.