whitelist item expiration

[nilsa]

Is there a way to specify a maximum age of entries in the whitelist?
To keep the whitelist manageable it would seem reasonable to delete entries that have not been visited for a specified period of time.

[Giorgio Maone]

No, not yet.

[Tom T.]

Is there a way to specify a maximum age of entries in the whitelist?
To keep the whitelist manageable it would seem reasonable to delete entries that have not been visited for a specified period of time.

I'm not entirely sure I support this suggestion. When I do go back to WhitelistedSite.com after some months, I'll wonder why it's broken, then have to re-add it to w/l. If the site's policies, trustworthiness, or use of webapps changes, I can remove it easily. This idea seems perhaps another unnecessary complication.

My Fx Cookie list has about a million entries (haha), and I wish it had a convenient "Find" function. My NS whitelist is *very* short (and recommend that yours not grow too large; use Temp Allow for all but your regularly-visited sites). But if it became an issue, it's easy to "Export" to a text document on your desktop or whatever, open with Wordpad (much neater than Notepad), edit it as desired, then "Import" the edited list back into NS.

[therube]

Oh, oh, oh, the Luddite speakith .

Now don't you know that one of the improvements in SeaMonkey 2 & FF3 is that you can filter cookies (similar to how you can filter in about:config).

Otherwise, Nirsoft: MozillaCookiesView - Cookies Manager For Mozilla/Firefox/Netscape Browsers.

[Alan Baxter]

Now don't you know that one of the improvements in SeaMonkey 2 & FF3 is that you can filter cookies (similar to how you can filter in about:config).

I assume Tom was talking about Cookie Exceptions, which does not have a filter, even in Fx 3.0. If I recall correctly, Tom has Fx set up to "Ask every time" and sets exceptions from there. Apparently he subsequently has a long list of exceptions.

[nilsa]

I tried the export function and was confused by the fact that most (if not all) sites appeared 3 times with
file://, http:// and https:// prefixes respectively.
What is the reason for this?
Do I have to delete all 3?

[Giorgio Maone]

I tried the export function and was confused by the fact that most (if not all) sites appeared 3 times with
file://, http:// and https:// prefixes respectively.
What is the reason for this?
Do I have to delete all 3?

Yes, you should delete all 3.
The reason for the triple specification is a bug in Mozilla's ScriptSecurityManager parser, which requires this redundancy for 2nd level domains.

[nilsa]

That makes it kind of a nightmare to clean up the list.
How about if you just stored the full domain and when loading the list if necessary make the needed duplicates on the fly?
That would also make the list much smaller.

And while I agree that one should use the "temporary allow" as much as possible,
I often use a website for few days to check it out and then promptly forget about it.
So a voluntary (and probably long - say a year) expiration time makes sense to me.

[Tom T.]

Now don't you know that one of the improvements in SeaMonkey 2 & FF3 is that you can filter cookies (similar to how you can filter in about:config).

I assume Tom was talking about Cookie Exceptions, which does not have a filter, even in Fx 3.0. If I recall correctly, Tom has Fx set up to "Ask every time" and sets exceptions from there. Apparently he subsequently has a long list of exceptions.

Alan is correct. But not only exceptions are stored there, but also "block". The exceptions are not many, but every site I've ever visited, for tech support or whatever, tries to set a cookie, so the block list is indeed long.

[Tom T.]

...And while I agree that one should use the "temporary allow" as much as possible,
I often use a website for few days to check it out and then promptly forget about it.
So a voluntary (and probably long - say a year) expiration time makes sense to me.

If you use it for a few days and forget about it, isn't leaving it in your list for a year kind of a long time to remain vulnerable?
If you're only "checking the site out" for a few days, why not Temp Allow until you decide whether it will become one of your regular sites? A couple of extra clicks, but easier than the procedure you complained of, and safer than leaving a questionable (in your mind) site w/l for a year.

It should not be that difficult to edit your exported whitelist. Let's say you want to delete somesite.com. Edit > Find > somesite. Delete, click "next" (or even easier, hit F3), delete, (lather, rinse, repeat, as they say on US shampoo bottles). This removes every permutation of somesite. I'm not seeing the problem.

Or just go to somesite.com, open NS menu, and click "Forbid somesite.com". That's even easier.

[Foam Head]

I think there is a definite use case for some kind of Whitelist expiration. I think it should be more of a "renewal notice" than a true "expiration", tho. You don't want to remove Whitelist entries since they may still be necessary and valid. However, over time people do forget things so a reminder would be nice.

IMHO this kind of "renewal notice" wouldn't fit too well with the current Whitelist design, but I can definitely see how it would mesh with a group/policy paradigm. And if you go so far as to implement downloadable Site/Policy Groups (discussed here), the renewal notice would be a perfect way to remind the user to check for updated versions of their downloaded Site/Policy Groups.

-Foam

[Tom T.]

If you *never* go back to the site, and it's a primary, not a third party serving ads or whatever, how is it a danger sitting in your whitelist? Much of my w/l is government-related sites (public records) from which I need data. (Most of the rest is my banks, etc.) They're not going to be running scripts on hotbabez.com or whatever. If I don't go to one for a year, how is it hurting me? But getting popup reminders, "You need to renew PalermoTaxCollector.com" all the time would be far more annoying.

I just looked in my brief w/l, and the *only* third-party script-runners are recaptcha.net and akamai.net, which we all pretty much need. The rest, aside from those above, are regularly visited, and plugins are still NOT allowed, except per-logo-click. I think the bloat (cure) is worse than the issue, and sw bloat and complexity always reduce security and maintainability (the prime criteria). IMHO. YMMV. I think there are higher priorities for NS dev and enhancement.

[nilsa]

The advantage of expiring items in the whitelist is trimming the size of it and thus improving performance.
When I exported mine to a text file, it had over 10000 lines in it!
I'll be sure to use temporary allow from now on.

[nilsa]

Issue with "temporarily allow":
I run Firefox with startup set to "Show my windows and tabs from last time".
In this mode it would be kind of nice if the "temporarily allow" survived a Firefox restart,
but this is probably difficult if not impossible to implement.

[Foam Head]

Tom T, if every NoScript user was as disciplined as you are, then I agree there would be no need for Whitelist "renewal notices". But like nilsa's 10,000 line Whitelist/Blacklist export file demonstrates, there are clearly different usage models that would benefit from some kind of "renewal notice". A few key points of how I envision this working:

1) Users would be able to globally enable/disable renewal notices. On the renewal notice pop-up, you'd be able to select "never show me this again" which would toggle the global option for you. I'd start renewal notices on by default, but one click on the first pop-up permanently disables it -- hardly bothersome to users that don't want it.

2) Yes, I do think there is a security risk in keeping sites in the Whitelist that you no longer frequent. There are degrees of trustworthiness and very few sites are "I will forever trust no matter what". For example, if I was on Facebook all the time, I could see adding Facebook to the Whitelist. I don't really consider Facebook "safe", but in order to use it, it needs scripting and adding it to the Whitelist means I don't have to Temp Allow it five times a day (yes, in this example I'm a teenager ). Since Facebook is not really "safe", the sooner I can remove it from the Whitelist, the better. With no automatic reminder, is it hard to imagine it staying there forever?

3) Even if users attempt to self prune their Whitelist, it is sometimes hard to know exactly what sites are associated with what services. For example, the default configuration has live.com in it. The hostname alone doesn't indicate what it is or why I need it. So now users are stuck wondering "well, if I remove live.com, will that make me safer or break something I need?" Novice users will end up keeping it for fear of breaking something. Over time, this will keep happening and users will end up with an alphabet soup of nondescript hostnames in their Whitelist. IMHO NoScript needs a way to identify the "service" every Whitelist entry belongs to.

Nilsa, I think that's a very interesting idea. Since FireFox supports the idea of storing a session between browser restarts, I don't see any reason why NoScript's temporary permissions shouldn't also survive. I think it should be a NoScript global option (e.g. "Temporary permissions survive browser restarts") and permissions should only survive if there is a page for that site stored in the session.

-Foam