Discussion: Site Specific Permissions Policy

Bug reports and enhancement requests
Post Reply
mik33mik
Posts: 18
Joined: Fri Mar 20, 2009 11:59 am

Add a script manager feature

Post by mik33mik » Wed May 13, 2009 2:48 pm

Hi Giorgio,
what do you think about to add a script manager to obtain a granular control of Javascript such as Controle de Scripts?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.18) Gecko/20081029 Firefox/2.0.0.18

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3339
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: Add a script manager feature

Post by GµårÐïåñ » Wed May 20, 2009 5:49 am

I was waiting on this to hear what Giorgio had to say but personally I think that is putting a huge amount of complexity into the code that might prevent less advanced users from getting proper usage out of NS; however, that being said, would love something like this to be integrated into the future major release of NS that would have some form of site level policy and stricter permission boundaries. As discussed here: viewtopic.php?f=10&t=415
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

User avatar
Foam Head
Senior Member
Posts: 57
Joined: Sun May 03, 2009 5:35 pm

Re: Add a script manager feature

Post by Foam Head » Thu May 21, 2009 7:05 pm

Agree with Guardian.

I can't speak for all browsers, but FireFox already has a small subset of global JavaScript functions you can enable/disable. On a global scale, I think the browser is the correct place for this functionality. However, if NoScript supported a full policy/group model, you could create specific permissions for each group and then these detailed JavaScript functionality settings would fit in nicely.

BTW: These are smatterings of policy/group discussions in various threads. Is it time for a formal discussion to take place as part of NoScript 2.0 development? I know I have an idea of how it would work in my head, but I'm sure so does everyone else. It could be useful to flesh out the specific design before coding line one.

-Foam
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3339
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: Add a script manager feature

Post by GµårÐïåñ » Thu May 21, 2009 7:48 pm

Foam, all relevant threads regarding that subject were combined into this sticky and we asked that everyone review the comments made there and also propose any thoughts and suggestions there so that Giorgio has one place to gather ideas and bounce back concepts as well. Try it: viewtopic.php?f=10&t=415

I will also merge this thread there for further replies and discussion.
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

User avatar
Foam Head
Senior Member
Posts: 57
Joined: Sun May 03, 2009 5:35 pm

Re: Add a script manager feature

Post by Foam Head » Thu May 21, 2009 9:27 pm

GµårÐïåñ wrote:Foam, all relevant threads regarding that subject were combined into this sticky and we asked that everyone review the comments made there and also propose any thoughts and suggestions there so that Giorgio has one place to gather ideas and bounce back concepts as well. Try it: viewtopic.php?f=10&t=415

I will also merge this thread there for further replies and discussion.

Gotcha. However, merging so many topics into one thread makes it a little hard to follow what's being said (e.g. you want to respond to something on page 3 only to find your response was deprecated by something on page 5). IMHO, it might be easier to create a new forum to hold all of these discussions each in their own thread.

Regardless, based on this thread, I assume the development is still at the brainstorming user requirements stage. What is the next stage? Is someone going to summarize the user requirements for a second-level discussion? Or are you going publish a proposed design? Or are you doing everything behind the scenes and the next user input will be feedback after a beta is released? And what is the rough projected time-frame of each stage? I have some ideas, but I'm not sure of the best time/method to give them.

Thanks,
-Foam
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3339
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: Discussion: Site Specific Permissions Policy

Post by GµårÐïåñ » Thu May 21, 2009 9:42 pm

I'll discuss it with Giorgio and if practical, I will create threads specific to each topic and split the topics to their respective threads within that forum. So much of what was being said was so repetitive because people didn't read that it was already said that this was an attempt to put it in ONE place and have people actually read what has been said and give feedback only when there is something new to add. At this point, people can give what they want to see and Giorgio will try to consider it along with the vision he has already in mind for the next release. I am sure at some point, he will open up a dev release for those willing to try it and give feedback but for now as you said, its more of "give a suggestion" and "it will be worked on behind the scene until later" type situation.
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

User avatar
Foam Head
Senior Member
Posts: 57
Joined: Sun May 03, 2009 5:35 pm

Re: Feature Request: Aggressive Domain Boundary Enforcement

Post by Foam Head » Thu May 21, 2009 9:58 pm

user2037 wrote:It seems to me that domains (in combination with cryptographic certificates) are the last, best hope for ensuring healthy boundaries between Internet destinations. And the more sites carelessly knit domains together the more users will become accustomed to it. A tool which highlights *every* domain boundary very clearly would really help. For example, why does one have to look to the status bar to see where a link truly leads? I'd prefer an unobtrusive tool-tip-style pop-up appearing only when hovering over the link. Perhaps there could even be a tool-bar or more status icons for the various boundary cross resources. It could indicate what has been blocked or allowed. It could also be grouped by resource type (style, image, script, object, etc.) or domain of origin. Another visual indicator could be to outline or overlay/shade objects from, or referring to, external domains.


I think NoScript could help with this. The problem is showing the cross-site links to the user. You don't want to manipulate the rendered content's styles (e.g. changing the "blue underline" to a "red underline" to mean cross-site), because there are simply too many style permutations. However, the mouse icon is changed far less often (and usually to just a different standard icon, very rarely to a custom cursor) and is controlled by a single CSS 2.1 style. What if NoScript overrode the cursor property for cross-site links with a special NoScript icon? Since JavaScript can change the classes and styles of a link (including the cursor property), NoScript would need direct browser notification when a link is hovered over -- which may or may not be possible. But if NoScript could trap all "the mouse is hovering over a link" events, this might work very well.

-Foam
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3339
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: Discussion: Site Specific Permissions Policy

Post by GµårÐïåñ » Thu May 21, 2009 10:09 pm

Agreed, excellent point but even that is further complicated by addons like this: Link Alert, I am thinking some kind of overlay injection might work better (not exactly like Ghostery but similar and more focused), hard to say what kind of mess or overhead that would create though. :?:
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

User avatar
Foam Head
Senior Member
Posts: 57
Joined: Sun May 03, 2009 5:35 pm

Re: Discussion: Site Specific Permissions Policy

Post by Foam Head » Thu May 21, 2009 10:12 pm

GµårÐïåñ wrote:I'll discuss it with Giorgio and if practical, I will create threads specific to each topic and split the topics to their respective threads within that forum. So much of what was being said was so repetitive because people didn't read that it was already said that this was an attempt to put it in ONE place and have people actually read what has been said and give feedback only when there is something new to add. At this point, people can give what they want to see and Giorgio will try to consider it along with the vision he has already in mind for the next release. I am sure at some point, he will open up a dev release for those willing to try it and give feedback but for now as you said, its more of "give a suggestion" and "it will be worked on behind the scene until later" type situation.


Ok, so it sounds like the development paradigm is pretty loose: the user community gives specific examples and ideas based on their own experiences, but really Giorgio is the engine that will drive changes. Odds are he's been thinking about this for a long time and already has the bulk of the design dreamed up. While our feedback can help clarify the ideas in Giorgio's head, we essentially have to wait until he unveils something -- which will probably be in the form of a development snapshot beta. For something that has such a fundamental impact on NoScript I was hoping for a little more transparency and interactivity than that, but in no way will I complain about such a wonderful tool provided for free :D.

BTW: One thing that might help reduce repetitive requests from users is a summary of current suggestions at the top of this sticky (or a summary sticky in the forum if you decide to split this thread). Ideally the summary would include "official" terminology and a link to the first post in threads discussing the topic. As a side benefit, this summary could become the "user requirements" that could help frame future design discussions and decisions.

Thanks,
-Foam
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

User avatar
Giorgio Maone
Site Admin
Posts: 8742
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: Add a script manager feature

Post by Giorgio Maone » Thu May 21, 2009 10:19 pm

Foam Head wrote:Regardless, based on this thread, I assume the development is still at the brainstorming user requirements stage

Not quite. I've been designing the "Site Permissions Manager" feature almost one year now, but NoScript's development has been prevalently emergency-driven, since web-based threats have been escalating quickly.

If you look at the development history, you'll see NoScript has been constantly pushing the "state of the art" of client-side web security, deploying the first and yet to-date best countermeasures against issues previously considered non-manageable on the client side, like XSS or Clickjacking.
Such definitely non-trivial and pretty unique features require a lot of tuning, especially on the usability and specificity side (my usual approach is "make it safest first, then deal with false positives").
I started considering anti-XSS mature from this point of view only some months ago, and I'm still tuning ClearClick.

That said, recently I started to cope with oldest RFEs for "convenience" features, like configuration management (import/export/synchronziation).

The next mandatory stop is ABE, which is NoScript's take on CSRF and can't be deferred anymore, due to commitments taken with the NLNet Foundation and OWASP.

After ABE I'll be hopefully, if no other emergency... emerges, able to finally resume my original plan for the "Site Permissions Manager" and include its prototype in NoScript 2.0.

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.

Just as a quick sketch, the "Site Permission Manager" I've got in mind will be a tabular UI listing one site for each row, and one capability for each column after the site pattern one. One extra column will represent the "Trusted" or "Untrusted" state. Each column except the site pattern one will be very compact, represented by a state-changing icon, but revealing a more descriptive tooltip hint on mouseover.
"Capabilities" will be the ones currently managed by NoScript, i.e. JavaScript, Java, Flash, Silverlight, "Plugins", and possibly "Media" (native video/audio HTML 5, currently coalesced with the "Plugins" capabilities).
User will be able to toggle any of these capabilities across 3 states:
  1. Enabled
  2. Disabled
  3. Default, which can be enabled or disabled depending on the Trused/Untrusted/Unknown status of the current site
The first rows of the table will be reserved to 3 "special" entries, i.e. "Trusted sites" and "Untrusted sites", and "Unknown sites", where you can define your default policies for the 3 categories which web sites can "historically" fall in according to NoScript: this way, backward compatibility and the original NoScript simplicity is preserved. The "Unkown sites" permissions, specifically, applies to all the web sites which are not listed in the "Site Permission Manager", i.e. the non-whitelisted sites in current NoScript lingo. The "Trusted sites" are the current whitelist, and the "Untrusted sites" the current blacklist.

Additional statuses and capabilities may be added after first release, the most important of which (emerged in recent discussions) are (in decreasing importance order):
  1. "Trust only if parent is trusted" (status) will apply the default trusted permissions (or the custom defined ones) only if the parent site is trusted, otherwise treat as unknown. It has been asked to enable some common 3rd party scripts/objects (e.g. google-analytics.com) only for certain trusted sites.
  2. "Allow all trusted embeddings" (capabilities), disabled by default, will allow some sites to automatically show their trusted embeddings (e.g. Youtube movies) even though the current default policy for trusted sites is restricted (like a "super-trusted" exception to the current NoScript Options|Plugins|Apply these restrictions to trusted sites as well).
  3. "XSS-protected destination" and "XSS-checked-origin" (capabilities), both enabled by default, as a quick even though coarse-grained alternative to current XSS exceptions. As a bonus, this flag could be activated on the fly by an extra menu item in the XSS notification bar options.

The site manager will replace the current Whitelist tab, and there will be an option to open it, filled with just the current page's content sources, in a popup window triggered by clicking on NoScript's icon, e.g. in place of the current "sticky" menu.
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

User avatar
GµårÐïåñ
Lieutenant Colonel
Posts: 3339
Joined: Fri Mar 20, 2009 5:19 am
Location: PST - USA
Contact:

Re: Discussion: Site Specific Permissions Policy

Post by GµårÐïåñ » Thu May 21, 2009 11:19 pm

I was going to reply to you but Giorgio was kind enough to take time and give a very comprehensive reply, so I won't repeat anything and its pretty complete. :mrgreen:

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. :ugeek:

So keep the suggestions coming, many heads are always better than one but the genius to implement it is still our "beloved dictator". :twisted:
~.:[ Lï£ê ï§ å Lêmðñ åñÐ Ì Wåñ† M¥ Mðñê¥ ßå¢k ]:.~
________________ .: [ Major Mike's ] :. ________________
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10

User avatar
Foam Head
Senior Member
Posts: 57
Joined: Sun May 03, 2009 5:35 pm

Re: Discussion: Site Specific Permissions Policy

Post by Foam Head » Sun May 24, 2009 12:25 am

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. :ugeek:

The hard work and dedication to fixing majors issues is both _amazing_ and _very much_ appreciated. :D

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. :D]

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.

d) I can't believe you read the whole thing! You can go to the restroom now :P.


Thanks for your attention,
-Foam
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

Samus_
Posts: 6
Joined: Mon Jun 08, 2009 9:14 am

request: allow scripts sourced fron domain

Post by Samus_ » Mon Jun 08, 2009 9:27 am

hello, I would like to ask you to consider extending the whitelisting option to allow running scripts based not on the domain they're hosted but from where they're being used; the reason for this is that I want to allow scripts on some sites to support them with advertising but not all host their own ads so I'm forced to allow those domains globally and I don't want them running on sites I didn't intended to, just the ones I pick.

as an example, the RequestPolicy add-on implements a similar concept.

thanks!
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042810 Firefox/3.0.3

User avatar
therube
Ambassador
Posts: 7469
Joined: Thu Mar 19, 2009 4:17 pm
Location: Maryland USA

Re: request: allow scripts sourced fron domain

Post by therube » Mon Jun 08, 2009 12:08 pm

More granular control may be available with a development build & ABE - Application Boundaries Enforcer.
Just don't ask me how to set up a rule for it?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.19) Gecko/20110420 SeaMonkey/2.0.14 Pinball NoScript FlashGot AdblockPlus
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090403 SeaMonkey/1.1.16

Samus_
Posts: 6
Joined: Mon Jun 08, 2009 9:14 am

Re: Discussion: Site Specific Permissions Policy

Post by Samus_ » Tue Jun 09, 2009 9:51 am

oh great, I'll check that thanks!

btw I also had a bit of trouble with AdBlock some may be interested on this topic: http://adblockplus.org/forum/viewtopic.php?t=4066
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.10) Gecko/2009042810 Firefox/3.0.3

Post Reply