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

[Tom T.]

DON'T THANK ME FOR ANY OF THE FOLLOWING, AND DON'T FEEL COMPELLED TO REPLY!

(seriously: We Are Not Alone. Hundreds of users have viewed this thread, and surely have had the same questions, and have benefited from the many issues raised and resolved. And (one hopes) will continue to do so for a long time.)

Also wouldn't have to deal with these CAPTCHAs every time I post.

I get headaches from those things, usually need 2-3 tries, and one day, will scream ... (con't)

But I keep thinking each message is about the last one I have reason to post, so why bother setting up yet another login?

Password Safe. Free, open-source, one master pw, auto-browse to URL, auto-enter creds and auto-login; can run from a Flash drive without leaving traces on the host (friend, etc.) machine; backup the database with a single file copy, about 16 Kb in my case, with 60+ user/pass combos + PINs + "challenge questions" + auto-specify which browser and with command line choices (e. g., to run the browser sandboxed); total disk space about 2 MB; quick install w/ no restart, on hard drive or Flash drive; encryption by world-class cryptographer Bruce Schneier. Waay too easy to create and use new logins, *and no need ever to contact a third-party site, or to store your creds on someone else's server*. If PWS goes out of business tomorrow, that doesn't affect you. If your hard drive dies, no worries. Reinstall from the installer that you saved to flash or CD or whatever, copy your backup copy of the pw database, and in five minutes, you're good to go. Every time I add an entry or modify mine, I copy the db to the flash backup with two clicks of a little batch script; details on request. (all copy/paste; no tech knowledge required.)

MY LAWYER SAYS: I don't control the product or your use of it; hence, not responsible for any consequences; and this forum can't endorse, support, or be responsible for, products of other parties. I say: Has worked for me for years; wouldn't live without it; wouldn't ever change. IMHO. YMMV.

I went to The Onion. ....Yes. I thought maybe denying through ABE would show some indicator. I've had the bar pop up to let me know the rule had blocked a script a few times.

User-configurable: NS Options > Notifications > check or uncheck ABE.
Blocked third-party scripts won't trigger the ABE notification, but a blocked page request (GET request, etc.) will.

I see. That's good to know. And the rest, which I'll snip to save space.

Must add: Easy to confuse with *NoScript* notifications (NS Options > Notifications > "Show message about blocked scripts"), also user-configurable. Can do either, both, or neither.

Alright, alright. Enough with the thanking. This will become an endless cycle, you know.

There are worse endless cycles ... and we have a few rude users, and I have been ruded out at other forums when I've needed assistance for their product.
But OK, no more thanks.

... Okay, fine. One last one. Can't leave it at that. You have been very kind, helpful, and pleasant, and you've made sure to explain things simply and clearly for laymen like myself. It's refreshing, and much appreciated.

I'm not thanking you, you understand, but in general, techies have a hard time empathizing with the non-tech user. True in almost any profession: the cognoscenti can't understand how the layman doesn't get that! It's easy! ... hence, all those stickies and wordy explanations (apologies to bored geeks), to be as accessible as possible to as many as possible. (cough)

Now, that's enough of that. Don't thank me for saying that. Or else. Or else... uhm... oh, right! Or else I shall have to thank you again!

Now you're quoting a Monty Python movie, or Peter Falk in "The Cheap Detective" ...

[dzbuk]

Dear sir,

I'd be really, really, REALLY grateful if you include this option. The necessity to confirm every "cascade" of scripts is really annoying in so many situations - If you'd include it as an option in configuration menu (even with a big red warning with skull and crossed bones in the background and necessity to confirm twice the will to turn it on as long as I'd have to do it just once and since then be free to "enable all the scripts the on the tab no matter how deep 'cascaded' they are") you'd help me.

Sincerely yours,
dzbuk

[Tom T.]

Dear dzbuk:

Please re-read the original post in this thread, which explains why that "feature" will not be available.

It also says that you can achieve the same goal by checking "Scripts globally allowed (dangerous)" in NoScript Options > General tab.
Which is what your feature request amounts to: You don't know what scripts will be called in succession, so in essence, you're already giving permission to the entire scripting universe.

If you do check "Globally allow" to avoid the inconvenience, I'd recommend that you uncheck it *before* leaving that site, so that you will resume having NoScript's full protection at other sites that don't do this.

Perhaps if enough people e-mailed the webmasters of sites that do this, the ugly trend might change.

Please note that there is always a trade-off between security and convenience. If everyone were honest, we wouldn't need locks on our cars and homes, nor have to carry around key rings. And that having one's identity stolen, computer compromised, bank account drained, etc. are much more inconvenient. But you are free to choose the "Globally allow" in any given situation.

Thank you for your interest in NoScript.

Sincerely yours,
Tom

[m--s]

I'd like to add to the discussion, as this is the only reason for me to even consider other options than NoScript (not that these exist, but still... )

Dear dzbuk:

[...] It also says that you can achieve the same goal by checking "Scripts globally allowed (dangerous)" [...]

Well, definitely not the same goal.

Let me explain: I'm routinely opening 300-400 tabs simultaneously (well... not by hand, usually via sessions) and there are a lot of websites where I need to register, login, check something, switch to some other tabs, pull in and gather all the needed bits and pieces from some other websites (and I don't know which ones in advance) then copy-paste it to the destination tabs (which usually have Javascript all over), etc.

So, the option to globally allow all my tabs simply scares me - in fact, I have been forced to do so a few times and it usually ended in me forgetting to turn the protection back on... also, the option to whitelist each and every webpage just to use it once or twice would be (and in fact, it IS) a lot of time wasted for me. It all comes down to me using NoScript more than the Firefox itself, (mainly selecting the damn option repeatedly, just like the title says...).

If I were to use your suggestion, I would be forced to enable/disable scripts repeatedly - also, some websites don't work correctly after this switch until the next reload,so it would be an

Code: Select all

enable-reload-disable-open new tab-(actual work here)-switch back-enable-reload

while this option simply allow me to use

Code: Select all

enable-open new tab-(actual work here)-switch back

... not to mention, that in the first case, I'd need to remember to switch the option off after finishing, or else...
... not to mention, that sometimes reloading a heavy webapp resets all the information entered...
... also sometimes I need to work with two or three 'nasty' sites simultaneously - just thinking about this is a pain, so let me skip further description

I hope you understand my POV - but I can elaborate further if you want. The general point of all this is that this option would save me a lot of time. I'm not claiming that I'm a typical user, but what else can I do than to write here?

I really admire your professional attitude here (and patience, above all), so I really do hope you'll reconsider not forcing users to something against their own will - as a programmer I can say that trying to predict all the use cases for the users, and locking out everything else is just pure evil . A good example here would be what some GNOME developer once said (AFAIR): 'we removed the option to select the font color, because that would enable selecting white font on the white background'... isn't this scary?

Regards,
ms

[Tom T.]

@ ms:

3-400 tabs? ... definitely an edge case scenario.

Since you're a programmer, you should have no trouble writing ABE rules, as was done earlier in this thread.

Certainly, a PITA the first time, to collate the scripts and sites, but as that happy user noted, an easy tweak every time a new site must be added, or a new script source added or deleted. But that user didn't find it too arduous.

In truth, 400 tabs isn't that much more dangerous than one tab for using "Globally allow". Granted, there's a larger chance that at least one site will be vulnerable to XSS, or that any particular site will call a malicious script, whether it be in the first or tenth iteration of reload. But *over time*, if this is the habit, isn't one repeatedly subjecting oneself to these risks 400 times with different sites on different occasions, vs. 400 tabs/sites on one occasion?

I do understand your POV, though 400 is a new record for max tabs open that I've seen here -- previous was 50-100. JOOC, how much RAM is Fx using at the time?

I really admire your professional attitude here (and patience, above all), so I really do hope you'll reconsider not forcing users to something against their own will

Thank you for the kind words, definitely. But please note that it's not something that "I" can reconsider. These decisions are made by Giorgio, who is solely responsible for NoScript's code.

I proposed this sticky in our private admin+mod forum/watering hole because of how frequently the question is asked. Giorgio said it was a good idea. Also, he gave his seal of approval to the final draft. Which would sort of imply that he feels the same way about this, would it not? -- else he'd have offered the option that the two of you (and some others) have asked for.

LOL at the "white on white" font choice. But the downside there is merely not being able to see anything. The downsides here are much greater. The concern, at least in IMHO -- can't speak for Giorgio, but I suspect he shares this concern -- is that many users, who lack your level of tech savvy, just *wouldn't understand* the degree of risk that they're taking.

A direct inspiration for the sticky was a user who asked for this, and when I explained why, said, oh, now it all makes perfect sense, thanks. Offering that option might give an impression of lower risk than it is, whereas something as explicit as "Allow globally (dangerous)" -- anyone who has any idea what a script is, and how it can be used for malice -- why else install NS? -- will understand that risk. Let me see if I can find that thread.

OK, the OP is here, my reply is a bit lower, here, and the epiphany/Eureka! of the OP is here. Clearly, she did not know what the dangers would be, but after the explanation, did understand.

If this option were offered in the GUI or menu, even with a "dangerous" (I like the skull and crossbones idea ), it lends some kind of sanction to it.

You're certainly free to contact Giorgio directly to express your wishes, but these were his wishes so far.

Please try ABE, as above. ABE FAQ.

Also, see if FAQ 5.2 would help your situation anyway. I'm not sure it would, since I can't envision your scenario , but something in those choices may make life easier.

Again, thanks for the kind words, and for your use and support of NoScript.

Regards,
Tom

p. s.: I've often forgotten to revoke temp permissions, too, although for one or two scripts, not globally, and done an oops! when realized it. Which is why I prefer to let ABE do the "remembering" for me -- automatically.

[Thrawn]

With all of this talk about ABE rules and site-specific permissions, I'm surprised that no-one has mentioned RequestPolicy? Block all cross-site requests by default, interface similar to NoScript.

[Tom T.]

With all of this talk about ABE rules and site-specific permissions, I'm surprised that no-one has mentioned RequestPolicy? Block all cross-site requests by default, interface similar to NoScript.

Big fan of RP, but the issue here is *allowing*, not blocking, isn't it? ...

Or are you saying, let RP default-deny, then allow all in NS?

At the kind of sites we're talking about, (cascading scripts and objects through multiple reloads and iterations), I have to keep opening RP menu, too, because each (off-site) item in NS menu that needs temp-allow will also need temp-allow in RP. I don't mind the extra work as a price of security and privacy, but it seems additional to, and not in place of, NS.

Cheers.

[Thrawn]

With all of this talk about ABE rules and site-specific permissions, I'm surprised that no-one has mentioned RequestPolicy? Block all cross-site requests by default, interface similar to NoScript.

Big fan of RP, but the issue here is *allowing*, not blocking, isn't it? ...

Or are you saying, let RP default-deny, then allow all in NS?

At the kind of sites we're talking about, (cascading scripts and objects through multiple reloads and iterations), I have to keep opening RP menu, too, because each (off-site) item in NS menu that needs temp-allow will also need temp-allow in RP. I don't mind the extra work as a price of security and privacy, but it seems additional to, and not in place of, NS.

Cheers.

Yes, I was suggesting that, when you want a script to be allowed at some sites and denied at others, you permanently allow it in NoScript and control it via RequestPolicy. It's comparable to how you leave JavaScript enabled in the browser and control it via NoScript.

Doesn't work so well if you really want to temporarily allow all from a site...but then again, you can tell RequestPolicy to allow all requests originating from a site, so not too bad.

[Tom T.]

At the kind of sites we're talking about, (cascading scripts and objects through multiple reloads and iterations), I have to keep opening RP menu, too, because each (off-site) item in NS menu that needs temp-allow will also need temp-allow in RP. I don't mind the extra work as a price of security and privacy, but it seems additional to, and not in place of, NS.

Yes, I was suggesting that, when you want a script to be allowed at some sites and denied at others, you permanently allow it in NoScript and control it via RequestPolicy. It's comparable to how you leave JavaScript enabled in the browser and control it via NoScript.

Doesn't work so well if you really want to temporarily allow all from a site...but then again, you can tell RequestPolicy to allow all requests originating from a site, so not too bad.

OK, I understand what you're saying now. But it does seem a bit O/T to this thread, in which users *do* want to TA an entire site rather than guess, or triage by trial-and-error, which of a dozen scripts may be needed. They do so, only to find that once done, and the page reloads, that even *more* scripts get called, *which were not in the menu the first time*. This may happen for a third, or even fourth, cycle. Quite aggravating.

I don't see RP helping out any, because even if you Globally Allow in NS, the same issue of allowing requests to A, B, C in RP, then reload, and requests are made to D, E, F, reload, etc ... still happens.

The purpose of this sticky was to explain *why* NS will not, *in advance*, TA all scripts that may be future-called by those one chooses to allow or TA from the menu. We had enough inquiries of that type that it was felt a sticky thread would explain the safety reasons for the inconvenience. But of course your ideas for overall control are always of interest, and possibly could be posted in Forum Extras > Security or > Web Tech.

[Thrawn]

The difference is that ABP is not a security tool, just as NS is not primarily an adblocker. ABP just protects you from tje nuisance of seeing ads, so it's reasonable to make exceptions based on the top-level site. But for security purposes, that is not good enough. Each domain is a potential threat, and must be individually handled.

You may want to try RP. Permanently allow the sites in NS, then 'Allow all from this site' in RP.

[dhouwn]

Heh, that spammer got you.

[Thrawn]

Argh, you're right. That spam account has done the same trick in a bunch of places lately.

[Guest]

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.

[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 http://forums.informaction.com/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.