GµårÐïåñ wrote:
As you can see, everything suggested is considered, its just a matter of ONE man finding the time to fit it into his chaotic schedule to implement, not withstanding the crap that is slung his way or the web in general, and he still manages to amaze me with his dedication to keep this tool the most up to date and ahead of the curve as anything I have ever seen.
The hard work and dedication to fixing majors issues is both
_amazing_ and
_very much_ appreciated.
Side Note: It's often so hard to read intentions via plain text like this. Let me clearly state that I'm a very grateful NoScript user and fellow software developer just looking to "give back" via improvement ideas.
Giorgio Maone wrote:
In the meanwhile you can express your preference and ideas in a brainstorming form, but please don't expect a lot of verbal feedback on my side until something "visible" which we can talk upon and revise is actually released in the form of a NoScript build: so far new NoScript features have been pushed out of the blue, either directly as a response to some security issue or to a very high-level user request, and user-driven refinement have been discussed and performed after that, directly on the live thing.
I don't fee like changing this approach, which has been quite successful from my point of view because it fits well my forma mentis.
As a NoScript user, this is a perfect model that will work very well for both of us. However, as a software developer, I hope this won't preclude you from implementing different alternatives; e.g. if you release a beta with XYZ and then get convinced that ABC would really be better, the fact that XYZ is already coded hopefully won't influence whether or not to use ABC.
And yes, I completely understand if you don't reply to my ramblings in any way.
Giorgio Maone wrote:
Just as a quick sketch, the "Site Permission Manager" [... clipped, see
original post for full quote ... ]
I think I understand what you described above. You are basically keeping most of the current functionality, but unifying the UI for easier configuration. A few things are unclear tho:
1) If every entry must be categorized by Trusted, Unknown, or Untrusted, then what's the point of also having permissions for each entry? e.g. Trusted says you can run JavaScript and foo.com is "Trusted", so why does foo.com need a "can run JavaScript" setting? If you allow foo.com's settings to override the Trusted group's settings, won't that be very confusing for the user (e.g. why didn't foo.com run JavaScript when it's "Trusted"?).
2) Practically speaking, are you going to be able to show all settings in a single UI table? I count over 20 settings and this could easily grow over time. You could abstract the actual settings with a pop-up dialog, but then would the Site Permissions Table's "permissions" columns show any useful information?
3) By listing each site one per line, how does your design handle grouping multiple sites together for a single web portal? For example, how can I combine yahoo.com, yimg.com, etc together so I can enabled/disable "Yahoo Mail" as a whole?
Again, please don't get me wrong. I think having exactly what you described would be an awesome benefit that I'd eagerly consume, but when this topic was originally discussed with words like "groups" and "policy management", I pictured something very different. Here's a rough idea of what sprang to my mind.
[Warning: This is long. Get a drink and hit the head now.
]
The core is still a list of relationships between sites and the settings for those sites. The main difference is that everything is done via Site Groups and Policy Groups instead of individual sites and individual permission settings.
A Site Group is a list of one or more Site Rules. A Site Rule can be an individual host name, a regex, or a reference to another Site Group. For novices, they'll be entering lots of individual host names just like they do now. But having the ability to add regexs and refer to other groups adds lots of power to system.
A Policy Group is similar to a Site Group, except it operates on (big surprise) Policy Rules. A Policy Rule is just a permission setting with it's associated value. To enable cascading of permissions, each permission can have a value of Yes, No, or "Don't care". "Don't care" means the value is inherited from another group.
An example will help solidify the concept. Here I'm using <+...+> to denote a special, innate group and <...> to denote a user created group. First, let's see the overall "Site Policy Relationships":
Code: Select all
Site Group | Policy Groups
----------------+-------------------------
<+Whitelist+> | <+Trusted+>
<+Unknown+> | <+Untrusted+>
<+Blacklist+> | <+Untrusted+>, <+Quiet+>
<Giorgio Maone> | <Giorgio Maone>
At this level, everything is abstracted to a high level, but based on the nomenclature, it is also very clear what is intented. Let's drill a little deeper and see what's in each Site Group:
Code: Select all
Site Group | Sites
----------------+-------------
<+Whitelist+> | foo.com
| https://(login|service).bar.com/
| <Yahoo Mail>
<+Unknown+> | n/a
<+Blacklist+> | annoying-ads-r-us.com
| we-track-your-clicks.net
<Giorgio Maone> | noscript.net
| informaction.com
| maone.net
<Yahoo Mail> | yahoo.com
| yimg.com
Again, this is pretty straightforward. Novice users will just be populating the <+Whitelist+> and <+Blacklist+> groups with a list of host names. Advanced users will create groups (like <Giorgio Maone> and <Yahoo Mail>) so they can track a collection of sites as a single service.
Now let's look at the Policy Groups:
Code: Select all
Policy Group | Policy Settings
--------------+---------------------------------------------------------
<+Trusted+> | JavaScript=yes, Show <noscript>=yes, Java=yes,
| ClearClick=yes, XSS=no, Quiet=yes, ... etc ...
<+Untrusted+> | JavaScript=no, Show <noscript>=yes, Java=no,
| ClearClick=yes, XSS=no, Quiet="don't care", ... etc ...
<+Quiet+> | Quiet=yes
Giorgio Maone | JavaScript=yes, Show <noscript>=yes, Java=no,
| ClearClick=yes, XSS=no, Quiet=yes, ... etc ...
Here, the special groups of <+Trusted+> and <+Untrusted+> are what you'd expect. They contain the key settings that most users will use all the time. The twist is that you can combine multiple Policy Groups to aggregate permissions; e.g. the <+Untrusted+> and <+Quiet+> groups are set to complement each other for the <+Blacklist+> site group. Of course, advanced users can create their own Policy Groups (like <Giorgio Maone>) to contain just the specific settings for those sites.
To manipulate the settings for each group, you'd probably want a pop-up dialog. This table listing of Policy Groups and settings is a short-hand summary. The nice thing about using a summary/dialog method is that you can add as many settings as you want without having to completely redesign the UI.
With the example complete, you can see that the built-in Site/Policy Groups are used much like the current NoScript uses them. What may not be apparent is the full power of user defined Site/Policy Groups.
In this example, there are two custom Site Groups and one custom Policy Group. The <Yahoo Mail> custom Site Group allows the user to enable/disable all of Yahoo Mail by adding/removing it from the <+Whitelist+> group. The two <Giorgio Maone> groups define both the sites for "Giorgio Services" and the most restrictive permissions that still allow full functionality.
But here's the best part: By allowing user defined Site/Policy Groups, you can provide preset "packages" of permissions for services! For example, someone could post a Site Group and a Policy Group for Facebook and any NoScript user could input them to get the most exact, most restrictive, yet fully functional Facebook settings.
If you take this concept a step further, NoScript could help automate downloading these settings on demand. And the coup de grace is that this makes remote management of NoScript permissions in an Enterprise version almost trivial; i.e. the remote admin would use a specific naming convention for their rules so the periodic updates wouldn't overwrite any existing custom settings.
As a mega-bonus, having a database of Site/Policy Groups for common sites also solves two key NoScript issues: users dumping NoScript because their favorite "multi-server" service is broken and users giving sites far too many permissions. AFAIK, these are the biggest issues that hamper NoScript adoption and my solution addresses them without forcing NoScript to directly provide all of the configuration information for every web service.
So there's the concept. I'm sure there are tons of variations and small points that need to be ironed out, but I think the core idea is complete. There are a few big issues that warrant specific mention, tho:
1) This might be too much for novice users. Having a Site/Policy Group database (especially with NoScript being able to automatically lookup and download them) would help, but the UI still might be too complex. If this is the case, the solution is to add some "Novice panes" to the options UI. The "Novice panes" present a simplified view for modifying the innate groups (the <+...+> groups). For example, you'd have a Whitelist tab that contained a "List of Sites" sub-tab (which was just a simple list of host names that users can add/edit/delete) and a "Permissions" sub-tab (which is a simplified subset of permissions checkboxes that apply to the <+Trusted+> group).
The key point is to keep the code using the complex version and leverage the UI to simplify things when necessary. Tho, TBH, I think if you had a database of Site/Policy Groups and a way to easily input them into NoScript, a large portion of Novice usability issues would be solved.
2) Without knowing how NoScript is currently implemented, my solution could force a near total rewrite of all code that references permissions. NoScript not having a concrete schedule for voluntary development helps, but if enough has to be rewritten, the rewrite will result in a separate stream needing to be maintained while emergency fixes are being done in the release version. So not only do you need to count the work of the actual redesign, but you then have to include a substantial amount of work to maintain two streams.
3) This may present some real-time challenges. Depending on some implementation details, it could be algorithmically complex to determine what to do when a site matches multiple groups. Similarly, it could be difficult to coalesce multiple policy groups to determine what to actually do. There are many strategies for dealing with these scenarios (from disallowing them in the first place to caching the results of complex operations), but some solutions lead to even more complexity.
In conclusion, I want to say four things:
a) This is definitely a complex solution, but once the "security engine" of NoScript understands Site/Policy Groups, the extensibility is awesome. For example, you could fold in ABE functionality by simply adding new Policy settings. Since there will be an ever-increasing number of exploits (and therefore policy settings), having this extensibility seems almost necessary.
b) The ability to download Site/Policy Groups for common web services (which can also be used to push settings to Enterprise clients) is a very appealing idea. If you tried to do this kind of database without name-able groups, you'd end up with a soup of sites and settings that even an advanced user would have trouble deciphering. IMHO encapsulation of sites/policies is almost necessary in order to take NoScript to the next level.
c) I am a happy NoScript user that expects nothing -- remember that I'm just looking to help by throwing some ideas on the stoop and seeing if the cat licks 'em up
.
d) I can't believe you read the whole thing! You can go to the restroom now
.
Thanks for your attention,
-Foam