InformAction Forums

I know there have been a few similar issues, but none seem to match mine. I apologize if this has been addressed before.

I have NoScript installed on several machines I use. This problem always happens after an update to NoScript, but does not happen to every machine nor with every update. However, each machine has had the issue at one time or another. It is very infrequent and does not seem to be consistent.

The main issue is that all the default whitelisted sites keep being readded to my whitelist. No custom additions to the whitelist are removed; just the ones that come enabled by default get re-added. When I install NoScript the first thing I do is remove all the default whitelist items except for about:* and the chrome and resource ones. I have very few items I permanently whitelist and everything else that is temporarily allowed on a per case basis. However, I now find myself having to review the config after every update and occasionally re-remove the default items.

The first few times I thought maybe I just missed the steps of removing them to begin with, but after the last update I had to remove them again on a machine that has been running and properly configured with some time.

Any help would be great because this is really annoying, and some of these sites are - in my opinion - dangerous to accidentally allow through.

There are only 3 circumstances causing the default whitelist to be restored:

1. Current whitelist couldn't be parsed from preferences, i.e. the preference called capability.policy.maonoscript.sites is missing from prefs.js. Notice that it being simply empty doesn't cause the default whitelist to be restored. It being absent does.
2. User hit the NoScript Options|Reset button
3. The configuration is locked.

Either way, current whitelist gets erased before the default whitelist being restored, therefore if

umbrae wrote: No custom additions to the whitelist are removed

we don't fall in any of these cases.

Maybe some other extension of yours is messing with NoScript's preferences (it's already been observed in at least two cases with extensions recommended on AMO), or your prefs.js file gets periodically corrupted and your observation about custom additions not being removed is inaccurate.

I'm afraid this may not help you, umbrae, but I want to add this data point. I removed some of the default whitelisted items a few years ago. None of them have ever been restored by a NoScript update. Good luck with your issue. It sure does sound inconvenient.

I confirmed that with the last update 2 of machines did have this happen, and this means 4 login profiles had this issue. Custom entries persist, and all 4 profiles have different sets so its not my imagination. In all cases capability.policy.maonoscript.sites does exist in prefs.js. I have not had any other issue on any of the machines with my preferences, so Idon't think this is a file corruption issue. I would think other settings would be affected if that was the case: not just noscript.

As far as other extensions, I use No-Script, CS Lite, and AdBlock Plus: nothing else. I have been using these all together and have not had an issue in the past: at least outside the drama a while back with No-Script and Adblock Plus. The issue started earlier this year with maybe a total of 10 occurrences so far.

Is there anything I can do to narrow this down? Is there a way to lock the lists or backup prior to an update? I like noscript, but I use this to protect my kids as well as myself. If this behavior continues I will have to try an alternative. I really need to have fine and predicable control over Javascript, and this issue disrupts that.

Thank you for the help.

umbrae wrote:Is there anything I can do to narrow this down? Is there a way to lock the lists or backup prior to an update?

Several ways to lock or backup (e.g. NoScript Options|Export), but nothing automatic on updates because updates should not touch any of your settings.

However, if the only sites that are added are those in the default whitelist, an easy work around for this issue (which, again, has been reported only by you) is just clearing the noscript.default about:config preference.

Thank you very much. I will try those and see what happens next time.