InformAction Forums

NoScript suddely disables everything independent of settings
I have NoScript 10.1.9.3 running on Ubuntu 18.10 with FF 62.0.
Until about half an hour ago everything worked fine and I was able to (temporarily)enable/disable JS as needed
as I believe most people are using NoScript.

I can not remember having done anything unusual, but all of a sudden NS disables everything if the plugin is enabled at all.
It doesn't matter how fine grained site settings are.
So right now I can only enable/disable everything by enabling/disabling the plugin.
To be able to write this post I had to disable NoScript....

Does anybody have an idea what could have happened and how I can fix this?
I already tried reinstalling the plugin, restarting FF and restarting the whole OS.

I'd be grateful for any useful suggestions.

Mike

Could you please send me your NoScript Options>Export configuration file? Email is shown here
Thanks!

I think I've also been hit by the "§" issue.
https://forums.informaction.com/viewtop ... 186#p98556

I've checked the config export and over 100 sites had the "§" in front. Especially those that I currently have open in tabs.
After resetting NoScript, things work again but I have to rebuild my setting from scratch.
Maybe that is good since it shrinks the number so allowed JS sources.

I think I know exactly what's going on (a crossing between two bugs in two different PAST versions biting together now).
I suspect auto-allowing top level sites has something to do with that, too.
I'm about to release a fix 10.1.9.4 later today, but in the meanwhile NoScript Options>Reset should fix the issue.
Please notice that the only entry to be removed is the "§:" (without any domain attached) one.

Giorgio Maone wrote: I suspect auto-allowing top level sites has something to do with that, too.
I'm about to release a fix 10.1.9.4 later today, but in the meanwhile NoScript Options>Reset should fix the issue.

I've never used that feature.

Giorgio Maone wrote: Please notice that the only entry to be removed is the "§:" (without any domain attached) one.

[...]
"§:artf.ly",
"§:artrange.co.uk",
"§:netdna-ssl.com",
"§:eurid.eu",
"§:", <=== You're talking of this one?
"§:192.168.30.82",
"§:jsdelivr.net",
"§:alicdn.com",
"§:amazonpay.com",
"§:dnsspy.io",
"§:who.is",
"§:d31qbv1cthcecs.cloudfront.net",
"§:staticbrainz.org",
"§:notebooksbilliger.de",
"§:alternate.de",
[...]

What is the meaning of the "§" in from of so many entries?
The only thing I can see is that non of them have a http:// prefix - In contrast to the ones that don't have a "§", those exist with or without the prefix.

But I can also see "duplicates" like
"§:192.168.30.82",
"192.168.30.82",
"meilenrechner.de",
"§:meilenrechner.de",

""§:" stands for "Secure", and it's the internal prefix for domain entries which are meant to be matched only if served through https.
You should never have an empty domain entry, but a bug in 10.1.9.2 caused it to be added automatically if you had "Temporarily set top level sites to TRUSTED" and maybe other ways.
This wouldn't have normally break everything like it did, if not combined with another otherwise innocuous change in 10.1.9.3 (that's why downgrading appeared to be a "fix") which caused invalid match patterns to be generated for the new DOM-based CSP enforcing backup (couldn't check, but I suspect a "§:192.168.30.82" entry would cause this as well).
In other words, quite a mess to figure out but a fix should be ready very soon.

Giorgio Maone wrote:""§:" stands for "Secure", and it's the internal prefix for domain entries which are meant to be matched only if served through https.

Thanks for the info

Giorgio Maone wrote:In other words, quite a mess to figure out but a fix should be ready very soon.

Cool.

Please check latest development build (or stable 10.1.9.4):
v 10.1.9.4
=============================================================
x Prevent total breakages when policies accidentally map
to invalid match patterns
x Internal messaging dispatch better coping with multiple
option windows
x Avoid multiple CSP DOM insertions

Interesting.

I started having the exact same issue last night.

FF Quantum 62 (64bit)
Noscript version 10.1.9.6

Was working fine all day then suddenly I refresh facebook only for it to tell me I need to enable javascript, no other site with js working either.

Only way round it was to disable noscript restrictions on that tab even though the domains are showing as allowed; effectively turning it off.

Just sat down today and obviously the same problem. (Had thought it might have just been a glitch and a reboot might sort it)

Confusing

supz wrote: I started having the exact same issue last night.

FF Quantum 62 (64bit)
Noscript version 10.1.9.6

Could please send me your NoScript Options>Export file?

here's a paste of it

https://pastebin.com/253waLhZ

Just look for a "*" entries in your known sites and set it to DEFAULT, rather than UNTRUSTED.
Or edit the export file, removing both the nonsensical entries in the untrusted: [] array, and import it back.
Now, it would be nice to understand: how did those end there? :-/

Removing the untrusted entries and reimporting worked.

no idea how/why they got there but reading the schema it makes sense why nothing was working if there was a wildcard in the untrusted.

thanks for the help

So there is https:, http:, & then http: followed by *.
What does that last one, *, mean?

(And presumably (?) one would not want the http: entries in there, assuming the site did in fact have https: ?)

therube wrote: What does that last one, *, mean?

Nothing, I suppose it has been entered by hand?

therube wrote: (And presumably (?) one would not want the http: entries in there, assuming the site did in fact have https: ?)

[/quote]
Yep, you just need the §:xyz.com one.