Page 1 of 1

permissions aren't persisted

Posted: Thu Dec 21, 2017 9:49 pm
by krichter
Setting a script permission to Trusted only has an effect until closing Firefox. When it's started again, the permission is reset. My test case is https://bugzilla.mozilla.org/enter_bug.cgi which requires https://bugzilla.mozilla.org to be trusted.

experienced with 10.1.6.1rc1 on Ubuntu 17.10 with Firefox 57.0.1

Re: permissions aren't persisted

Posted: Thu Dec 21, 2017 10:11 pm
by Giorgio Maone
Did you click the icon clock ("temporary") to fade it away and set the permission to permanent?

Re: permissions aren't persisted

Posted: Fri Dec 22, 2017 7:52 pm
by Problem Areas
Firefox 57.0.2, NoScript 10.1.6. All domains and configurations suddenly removed after weeks of consistent use. Didn't update or change anything concerning NoScript in the meantime. Are we gonna get a stable release anytime soon?

Re: permissions aren't persisted

Posted: Fri Dec 22, 2017 8:36 pm
by Bounder
I can replicate similar behaviour on my GNU/Linux system. For example; starting with a fresh NoScript installation:

01. Visit https://www.mozilla.org/en-US/firefox/new/
02. Click on the NoScript icon in the browser toolbar.
03. Two entries are listed, both as "DEFAULT"!! The entries are:
  • "...mozilla.org"
  • "https://www.mozilla.org"
04. Set all URIs and/or domains which appear in the NoScript drop down panel to "UNTRUSTED":
  • Only one entry for the URI "https://www.mozilla.org" should remain.
05. Select "CUSTOM" as Temporary Allow, and tick the "script" and "font" boxes.
06. Click the green Reload icon to set the above temporary allowed custom settings.
07. Close all Firefox browser sessions.
08. Launch Firefox, re-visit https://www.mozilla.org/en-US/firefox/new/
09. Click on the NoScript icon in the browser toolbar.
10. Only the following address should show, and it should show the status as "UNTRUSTED":
  • "...mozilla.org"
11. Repeat steps 05 to 09 (above).
12. Now; two entries are listed, both as "DEFAULT", exactly as in step 03 (above)!! The entries are:
  • "...mozilla.org"
  • "https://www.mozilla.org"
Naturally, I expect the tempory custom settings to revert back to the "UNTRUSTED" state everytime, upon exiting the browser session, or clicking "Revoke Temporary Permissions". Clearly, in NoScript version 10.1.6, this is not happening everytime, only some of the time.

I blacklist every site I visit. I then use "CUSTOM" to temporarily allow only the items that block the content I wish to access.

Is this a Linux only issue? I would not know as I don't run MS-Windows, or MacOS. Contrary to the user agent being reported in my post on this thread, I'm actually running:
  • NoScript-10.1.6
  • Firefox-57.0.2 Linux-x86_64
  • Debian GNU/Linux
My workaround for now is: Manually re-blacklist any site where I've used a customised temporary allow rule, prior to ending the browser session.

Re: permissions aren't persisted

Posted: Fri Dec 22, 2017 11:02 pm
by bo elam
Bounder wrote: Naturally, I expect the tempory custom settings to revert back to the "UNTRUSTED" state everytime, upon exiting the browser session, or clicking "Revoke Temporary Permissions". Clearly, in NoScript version 10.1.6, this is not happening everytime, only some of the time.
Thats how that has always worked for Untrusted domains. Whenever you allow or Temporarily allow an Untrusted domain, when all is over, the domain goes to Default, not to Untrusted. If you want to continue maintaining that domain as Untrusted afterward, you must remember this and set the domain back to Untrusted. This here regarding Untrusted domains is no bug or problem but by design.

Bo

Re: permissions aren't persisted

Posted: Wed Dec 27, 2017 3:37 am
by krichter
Thats how that has always worked for Untrusted domains. Whenever you allow or Temporarily allow an Untrusted domain, when all is over, the domain goes to Default, not to Untrusted. If you want to continue maintaining that domain as Untrusted afterward, you must remember this and set the domain back to Untrusted. This here regarding Untrusted domains is no bug or problem but by design.
The fact that a problem is caused by the design doesn't solve it or magically make it a non-problem.

I can confirm that using custom settings works around this issue. I guess we can set it on the large list of regressions and removal of extremely useful functionality that has been introduced with the Quantum-version which has been extensively criticized at numerous places (with negative connotation only afaik). Let's hope for a fork.

Please move the development to a code hosting platform like gitlab.com and support requests to a platform controlled by meritocratic swarm intelligence like superuser.com since it's unlikely that development will work in this format without an enormous organisation and communication overhead.

Re: permissions aren't persisted

Posted: Wed Dec 27, 2017 4:23 am
by bo elam
krichter wrote: The fact that a problem is caused by the design doesn't solve it or magically make it a non-problem.

I can confirm that using custom settings works around this issue.
I was talking specifically about Untrusted domains. I have a very large black list, I dont black list domains that need to be allowed temporarily often. I dont think we should black list domains that we need on a regular basis. I only have a couple that are black listed but require once every few months. So, to me personally, temporarily allowing Untrusted domains going to Default when all is done has not been a problem. I know that when all is over, I have to set them back as Untrusted.

About domains set as Custom. In my computers, I see same behavior with Custom domains as what we see with Untrusted domains, when they are set to Temporarily trusted, they go Default when you close the browser or revoke temporary permissions. Personally, I think that's fine.

Regarding Trusted domains, if you do as Giorgio suggested, the Trusted permission is set for good. As far as I can tell, that is working flawlessly. If its not in your computer, then perhaps your settings are corrupted.

Bo

Re: permissions aren't persisted

Posted: Wed Dec 27, 2017 5:25 am
by barbaz
krichter wrote:I guess we can set it on the large list of regressions and removal of extremely useful functionality that has been introduced with the Quantum-version which has been extensively criticized at numerous places (with negative connotation only afaik). Let's hope for a fork.

Please move the development to a code hosting platform like gitlab.com and support requests to a platform controlled by meritocratic swarm intelligence like superuser.com since it's unlikely that development will work in this format without an enormous organisation and communication overhead.
krichter, being the OP doesn't entitle you to off-topic ranting. Get back on topic now.

Re: permissions aren't persisted

Posted: Wed Dec 27, 2017 12:56 pm
by Bounder
Hi. I'll begin by apologising for my delayed response - I've been away from an available terminal.

Thanks for the reminder Bo. I do seem to remember now, the old "Classic" behaviour regarding temporarily allowing a blacklisted address, and then having to manually blacklist said address again once done using it. Similar behaviour now in NS-!0+; is this really by design, or is it unintentional?

Feature Request: I do think that it is indeed wholly worthwhile, that one can have the ability to apply a Temporary "CUSTOM" setting to a Blacklisted site, and then have it reliably return to the blacklist every time the site is no longer required in the course of a browsing session (e.g; via "Revoke Temporary Permissions") or, every time automatically at the end of a session.

Why do I ask this? As I mentioned in my previous post, I like to blacklist everything and only allow as required. I prefer to try and keep my attack surface as small as possible. There is the odd situation where I may wish to enable a blacklisted address for a particular site, but otherwise would never allow it for others. It's all about context and combination. Lastly, it is just way too easy to forget to manually re-blacklist an address.

It is great to have NoScript back again.

Real user agent: FF-57.0.2 GNU/Linux-x86_64/x11; NS-10.1.6.1; HTTPS Everywhere.

Re: permissions aren't persisted

Posted: Wed Dec 27, 2017 3:26 pm
by barbaz
@Bounder: 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

Re: permissions aren't persisted

Posted: Wed Dec 27, 2017 3:59 pm
by Problem Areas
Problem Areas wrote:Firefox 57.0.2, NoScript 10.1.6. All domains and configurations suddenly removed after weeks of consistent use. Didn't update or change anything concerning NoScript in the meantime. Are we gonna get a stable release anytime soon?
So, I don't want to make another thread just for this and with no way to reproduce the problem, but this still happens to me on 10.1.6.1. This time I imported the saved configuration after the wipe, but am I the only one with this issue?

Re: permissions aren't persisted

Posted: Wed Dec 27, 2017 9:02 pm
by barbaz
Problem Areas wrote:So, I don't want to make another thread just for this [...] am I the only one with this issue?
Well, do you have the same issue as the OP?

If so, then obviously you are not the only one with this issue.
If not, your posts should be split to a new thread if you want help. Don't worry about not having exact steps-to-reproduce, we're willing to help troubleshoot.

Let us know, thanks.

Re: permissions aren't persisted

Posted: Wed Dec 27, 2017 11:21 pm
by Problem Areas
barbaz wrote:
Problem Areas wrote:So, I don't want to make another thread just for this [...] am I the only one with this issue?
Well, do you have the same issue as the OP?
Actually no, but the title seemed to fit the issue which I described above. Never mind then; since it's random, no one is reporting it, and I don't have a clue what might be causing it, I'll just drop it.
When/if the domains/configuration resets again, I'll just import the saved config.

Re: permissions aren't persisted

Posted: Fri Dec 29, 2017 4:49 am
by Bounder
@Barbaz: Thanks for the heads up, and reminder regarding Firejail - much appreciated. Firejail has been on my very dusty "to do list".

@The Forum: I could achieve similar by de-activating all categories in "DEFAULT", however I do not wish to alter "DEFAULT"'s , default settings - I'd rather use "UNTRUSTED" for my blacklisting, i.e., what it is designed for, thus maintaining flexibility.

I think that my feature request, see my earlier post in this thread, would take some of the "rough edges" off a very granular system - enhancing it's useability somewhat. I don't think I would be the only NS user who uses the blacklist approach.

Re: permissions aren't persisted

Posted: Fri Dec 29, 2017 9:50 pm
by bo elam
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