InformAction Forums

The UI (menu and settings) prevents you from adding a whitelist entry that's more specialised than an existing one (it matches a proper subset of what an old entry matches) and with this prevents unnecessary whitelist bloat. An example would be if you tried to add foo.example.org but you've already got example.org in the whitelist.

But interesting, the other way around it does not do anything against the unneeded entries, e.g. if there's bar.example.net in your whitelist and then you add example.net, then you've got both entries in the whitelist but the former one is useless.

Wouldn't it be smart to delete (but maybe ask/inform the user beforehand) the more specialised entry when you add a broader one?

dhouwn wrote:Wouldn't it be smart to delete (but maybe ask/inform the user beforehand) the more specialised entry when you add a broader one?

It's intentional, to honor the minimum surprise principle.
Think of the case where you whitelisted mail.google.com because you're a GMail user, then you need to temporarily whitelist google.com for something exceptional. Is really your intention to loose your GMail permissions on next session? (notice that the same reasoning applies to permanent permissions, even though it's less exacerbated).

Actually I was just thinking of the case of permanent whitelisting since obviously a "temporary" action shouldn't have permanent side-effects. And exactly for preventing surprises I was proposing to inform/ask the user first.

But anyway, I just saw it as another possible nice-to-have for making sure the whitelist stays nice and clean. It would fit well with some other RFEs I read about here on the forums outlining ideas to help the user find outdated/useless entries by displaying the whitelist as a sortable table with columns for domain, subdomain and maybe additional info like when and where that entry was added.

Oh, if NoScript just had a public bug tracker where all that great ideas could be added, marked as "priority-low-but-nice-to-have" and then wither there for years just like on Mozilla's.

dhouwn wrote:But anyway, I just saw it as another possible nice-to-have for making sure the whitelist stays nice and clean. It would fit well with some other RFEs I read about here on the forums outlining ideas to help the user find outdated/useless entries

If one's whitelist is that long, it's probably far too many.
They're already alphabetized, with http first and https later, after about:x. Which makes it easy to go down the list and remove old ones.
Even better, if you're not certain that you'll be using a site often, there's an option called "temporarily allow". This option keeps the whitelist very clean. I have around 40 or so entries.

by displaying the whitelist as a sortable table with columns for domain, subdomain and maybe additional info like when and where that entry was added.

I don't see how "when and where added" is useful. You either need that site in your list, or you don't any more.
This RFE sounds like "feeping creaturitis", a/k/a "bloat" - keeping in mind that there has always been a substantial part of the user base (low-tech users) who think NS is "too complicated" already. With all due respect for your many fine contributions here, I don't support the RFE. Along with "least surprise" goes "least complicated".

Oh, if NoScript just had a public bug tracker where all that great ideas could be added, marked as "priority-low-but-nice-to-have" and then wither there for years just like on Mozilla's.

Oh, if only NoScript had Mozilla's budget and "thousands of vounteers"!
Keeping up with the flood of new releases of Fx/SM, emerging threats, continued development of projects such as ABE, handling support requests virtually alone, with a small staff of now-and-then unpaid volunteers, I'd say are all first priorities, and probably enough.

NOTE to Forum readers: As said, I have a great deal of respect for long-time contributor dhouwn, and so this post was a bit "tongue-in-cheek" in mood, though serious in content. I trust it will be taken in that spirit.