donwms wrote:
It is generally agreed that disabling unneeded software features reduces the attack surface, so the more features that are disabled, the less attack surface there is. Of course, reducing the attack surface is a good thing, even for trusted sites.
That's the basic state of NS already; all JS, and as much active content as possible otherwise, is disabled on all sites until the user allows it selectively. That's the central point about whitelisting isn't it?
In terms of NoScript, I want to be able to minimize my attack surface, even for trusted sites. In other words, I would like some method assign different options on different websites.
You have this already in the NS (contextual) sorry, I mean Options menu - - and also in extra non-UI preferences.
One way to accomplish this would be to allow the user to define and name multiple sets of NoScript trust options, then allow the user to assign websites to one of those named option sets. This would allow him to pick a level of trust from a manageable number of choices.
The various Temporary Allow, Permanently Allow, Block plugins on untrusted and trusted sites already gives this control - - although some few users have asked for more granular control over plugins.
NoScript could come with some example option sets, perhaps three options sets:
1. Unknown: Everything disabled (Unknown sites assigned to this set of options, by default)
2. Known: Many features disabled. (Many web sites should work, but with reduced risk)
3. Trusted: Most features enabled. (Only very trusted sites should be assigned to level)
The user could modify or delete these sets of options. Or he could create more.
NS already has these features.
Your state 1. is equivalent to all active content not allowed; the (context)sorry, again I mean Options menu gives you access to customise NS to a more tied-down configuration than even the very cautious default NS configuration, plus there are quite a few more hidden preferences to tie NS right down with. In other words, the whole web is untrusted
by default in NS
Your state 2. is how most experienced users of NS already navigate - - ie with the default NS configuration - plus plugins blocked on "allowed" sites, and then temporarily allowing sites and objects only if some function is needed - and then only the minimum domains that are needed for some feature to work. In this configuration, Giorgio has designed a unique context menu that makes NS navigation
on-the-fly not only one of the most transparent forms of process control amongst browsers, but also (and this is the most important for all values of usability that matter) the least intrusive into both web use and browser function.
Your state 3? Whitelisting is possible for any number of domains - and with more granularity than the default configuration. Certainly plugin whitelisting is not as finely controllable. I would say that many particular site requirements for plugin whitelisting could be met by a user creating a profile for this kind of whitelisting.
My advice for new adopters, as a plain long-time user of NS and an even longer member of the Fx community, is to firstly become familiar with Fx and it's many unique features that can be used in conjunction with specific NS settings, and then to boldly go onto the web with NS - using the context menu on-the-fly - which is its genius usability - and find out just how little whitelisting or *spit* blacklisting a user really has to concern themselves with.
From a practical viewpoint, trust is not simply black or white. There are many levels of trust. My trust in someone is based on more than whether they are easily identifiable and reachable and on more than whether or not I could sue them. The same goes for a web site. Some web sites should clearly not be trusted,
Most true!
and should be on everyone’s black list.
Well, with NS all sites are on everyone's blacklist, every day, until the user decides otherwise - - and in a default retractable form too :-) - - surely the safest way when a domain's trust status may be subject to many changes that a user doesn't keep current with.
Some sites can be totally trusted and can be put on your white list.
Yes, but that's only on current information surely? What about tomorrow when the site's been corrupted or the company's been sold? Better to temporarily allow and to have a tiny whitelist. My whitelist in my general browsing profile is 2 entries long - and more for convenience of cookie setting per visit rather than a set-to-forget convenience.
However, most sites are somewhere in between.
Which is why Temporarily Allow, and the domain granularity already in NS suit the thoughtful user so well.
All of the above, of course, recognises that there is a demand for a Group Policy version of NS, but for the general single user points you've made, NS is already providing an extremely flexible whitelisting approach to security.
Edited once to correct bad use of "context" where it should have read "Options"
