"temporary allow" not temporary...

Ask for help about NoScript, no registration needed to post
ginahoy
Senior Member
Posts: 57
Joined: Tue Feb 07, 2012 6:32 pm

"temporary allow" not temporary...

Post by ginahoy »

When I "temporary allow" a site that's listed as Untrusted, I expect that site to revert to Untrusted status after I close the page, or at least after I close and reopen FF. But that's not what's happening. I have to click "Forbid" again. As it turns out, Temporary Allow permanently removes sites from the Forbid list !

Getting things back to where they were can be tedious when I temporarily allow multiple sites for troubleshooting purposes, since I may not encounter the scripts for a while. By that time, I will have forgotten that I had previously verified that it's OK to forbid a given script.

I can't say how long this has been happening, maybe for as long as I've been using NS? I just haven't bothered posting an inquiry until now.

I'm running NS v5.1.8.3 on two machines (Linux FF55, and XP FF52esr), and behavior is the same.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
barbaz
Senior Member
Posts: 10847
Joined: Sat Aug 03, 2013 5:45 pm

Re: "temporary allow" not temporary...

Post by barbaz »

That behavior is by design.

Quoting relevant posts from another thread -
barbaz wrote:I solve that by running multiple browser instances in sandboxes that get dumped on quit. This way you can change permissions however you need to, leave them in any state, and they'll all be back how you want on the next browser startup.

Since we're both Linux users, you can do same thing I do - https://forums.informaction.com/viewtop ... 664#p83664
bo elam wrote:
Bounder wrote:@Barbaz: Thanks for the heads up, and reminder regarding Firejail - much appreciated. Firejail has been on my very dusty "to do list".
By the way, for Windows, there is Sandboxie. I adopted NoScript and Sandboxie days apart in early 2009. They work very well together, any changes you make in NoScript (temporary or not), go away when you close the browser/delete the sandbox.

Bo
*Always* check the changelogs BEFORE updating that important software!
-
Pansa
Senior Member
Posts: 318
Joined: Fri Nov 24, 2017 10:30 pm

Re: "temporary allow" not temporary...

Post by Pansa »

You aren't supposed to move domains from untrusted to temp allow anyway.

The untrusted list is for domains that you know you don't trust, not even temporary.

This is why temporary rules revert to default afterwards, because that is the list that pages are on that you haven't decided yet, or have changing opinions about.
If you think that the default preset still allows too much, you can remove the preinstalled permissions for default pages in the options.
Moving EVERY domain from default to untrusted without a good reason and then switch them from untrusted to temp trusted just blows up the ruleset that no script needs to work through on every page load for every domain being called. If you want the behaviour as if the default is like untrusted, it is better to change the default behaviour to mimic the untrusted set to begin with.


No script doesn't remember what rules USED to apply for a given domain, it only remembers what the current rule is (and temp rules get deleted on closing the browser, leaving the domain without rule -> default)
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
ginahoy
Senior Member
Posts: 57
Joined: Tue Feb 07, 2012 6:32 pm

Re: "temporary allow" not temporary...

Post by ginahoy »

barbaz wrote:That behavior is by design.
Pansa wrote:You aren't supposed to move domains from untrusted to temp allow anyway. The untrusted list is for domains that you know you don't trust, not even temporary.
Huh. Then what's the purpose of "Temporarily allow (site)" for entries in the Untrusted list? Is this just a misnomer for "Revert to default"?

Generally, whenever I visit a site that generates objects in the default list, I block each object that I can verify it doesn't impact the site. I obviously have no clue if a blocked object might later break another site.
Pansa wrote:...you can remove the preinstalled permissions for default pages in the options.
Where do I find permissions for default pages?

@Barbaz, thanks for references to previous threads where this issue was discussed, so I won't waste mine or anyone else's time explaining why it would make sense to return temporarily allowed objects to blocked status. I'll keep Firejail in mind, but it seems a bit overkill as a workaround for this.

BTW, I just noticed there's an option to "Ask for confirmation before temporarily unblocking an object." I assume this refers to the use of "Temporarily allow" for Untrusted sites, although I just checked this option and it doesn't seem to work. Perhaps it means something else?
Mozilla/5.0 (Windows NT 5.1; rv:52.0) Gecko/20100101 Firefox/52.0
Pansa
Senior Member
Posts: 318
Joined: Fri Nov 24, 2017 10:30 pm

Re: "temporary allow" not temporary...

Post by Pansa »

ginahoy wrote:
Pansa wrote:...you can remove the preinstalled permissions for default pages in the options.
Where do I find permissions for default pages?
in version 10.1.6.3 at the top of the options page.
Pansa wrote:You aren't supposed to move domains from untrusted to temp allow anyway. The untrusted list is for domains that you know you don't trust, not even temporary.
Huh. Then what's the purpose of "Temporarily allow (site)" for entries in the Untrusted list? Is this just a misnomer for "Revert to default"?

Generally, whenever I visit a site that generates objects in the default list, I block each object that I can verify it doesn't impact the site. I obviously have no clue if a blocked object might later break another site.
I don't really understand your perspective here.
It's not as much a misnomer than it is different from what you expect. Temporary rules get removed on reload. Leaving NO rule. It just doesn't build a rule on top of an existing rule to which it reverts.

There is no specific "purpose" for the temp allow site button other than it would be a visual clusterfuck and unreasonable programming and computation effort to have every line in the list have context sensitive buttons.
All lines of objects have the same buttons.
In the same vain you might ask why there is still an "untrusted" button once you set an object to trusted.
The answer is "because the UI doesn't remove buttons based on what your choice is"

You just don't need to move all objects to "untrusted" in the first place.
Just leave all the objects that you know don't impact the site in default. It's a lot of clicks to move everything to untrusted.

Untrusted is for pages you know you will never want to run.
default is for the sites you just don't need to run at this moment for all you know.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
barbaz
Senior Member
Posts: 10847
Joined: Sat Aug 03, 2013 5:45 pm

Re: "temporary allow" not temporary...

Post by barbaz »

ginahoy wrote:Huh. Then what's the purpose of "Temporarily allow (site)" for entries in the Untrusted list? Is this just a misnomer for "Revert to default"?
Untrusted means "I do not want to allow this site now or in future, so please stop asking me about it".
https://noscript.net/features#blacklist

If you Temporarily allow an Untrusted site, you are clearly saying the site no longer fits the definition of Untrusted. So it should not revert to being Marked as Untrusted.
ginahoy wrote: Firejail [...] seems a bit overkill as a workaround for this.
No it's exactly the right level of workaround. What you would never want to allow outside a sandbox is likely a superset of what you would never want to allow inside the sandbox. And what you would never want to allow inside the sandbox will vary depending what you're doing. So it is very reasonable to always use sandboxes to Temporarily allow sites that you want to keep Marked as Untrusted, if you want those sites to revert to Untrusted when you're done.

If you disagree, you maybe over-using Mark as Untrusted.
ginahoy wrote:BTW, I just noticed there's an option to "Ask for confirmation before temporarily unblocking an object." I assume this refers to the use of "Temporarily allow" for Untrusted sites,
Nope, it refers to clicking blocked object placeholders or stuff in the Blocked Objects sub-menu.

@Pansa: they're using NoScript Classic, not NoScript 10.
*Always* check the changelogs BEFORE updating that important software!
-
Pansa
Senior Member
Posts: 318
Joined: Fri Nov 24, 2017 10:30 pm

Re: "temporary allow" not temporary...

Post by Pansa »

barbaz wrote: @Pansa: they're using NoScript Classic, not NoScript 10.
Thank you for pointing that out, I completely missed it.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
ginahoy
Senior Member
Posts: 57
Joined: Tue Feb 07, 2012 6:32 pm

Re: "temporary allow" not temporary...

Post by ginahoy »

Pansa wrote:
ginahoy wrote:Generally, whenever I visit a site that generates objects in the default list, I block each object that I can verify it doesn't impact the site. I obviously have no clue if a blocked object might later break another site.
I don't really understand your perspective here.
I see NS as a tool for preventing unnecessary scripts from slowing down my browsing experience. I have no knowledge as to whether a script is 'trustworthy' or not, or what its purpose might be. Some years ago I used to click over to the (still) experimental NS page that links to several 3rd party domain evaluation sites for a given script domain, but I found that takes a lot of time and in the end, the only thing that matters is whether a script is necessary for a site/page to function, at least for the features I need to use.

The problem is that a script that may be unnecessary for one site to function may turn out to be necessary on other sites that I've yet to encountert. I'm not sure how I could ever be in a position to declare any site as "Untrusted" forever, at least not without spending a lot of time researching the purpose of the script and speculating whether it might conceivably be required for site functionality for some future site I might visit. That's particularly problematic since web developers don't always follow good practice when structuring their pages.

So from that perspective, it sounds like I should generally leave script-generating sites in default status as you guys have suggested. However, I was under the impression (perhaps falsely) that pages sometimes don't load properly (hang) when certain objects are in the default list. By clicking the "Forbid" button, other previously "Allowed" scripts can proceed thus allowing the page to finish loading. Can someone comment on this? In particular, is there any difference (with Classic NS) in the behavior when an object is in the default list versus the Untrusted list? If not, then I should stop using the Forbid option.
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
bo elam
Senior Member
Posts: 208
Joined: Sat Oct 14, 2017 2:25 am

Re: "temporary allow" not temporary...

Post by bo elam »

ginahoy, let me give you my perspective about Untrusted domains. I have a large black list done based on sites that I visit. My criteria to forbid a domain: I forbid/Untrust domains that I see all over the net that overtime, I came to realize that I dont need for nothing, anywhere. Doing it like that, I cant remember last time I had to switch a domain from Untrusted to trusted and back to Untrusted. As of right now, the only domain that I have as Untrusted that I know I might need to trust somewhere is cloudflare.com. Years ago, I used to have to take that domain out of my Untrusted list quite often but it seems sites where I stream live sports are using it now less and less often. I used to do that also with ajax.googleapis but with NoScript 10, I ended up creating a Custom rule for it. This 2 domains were/are the exceptions to my rule for untrusting a domain. Your Untrusted list should be pretty much a list of domains that you can completely ignore when you visit sites at random.

Bo
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:57.0) Gecko/20100101 Firefox/57.0
Post Reply