InformAction Forums

Hello,
I've created this topic separately from another one started by me, as I'll probably have a lot of another requests/bug tracks. Some of them would be just a translation of users' wishes posted on Russian mozilla community.

Bug 1
If a user has checked a box "temporary allow base domains of 2nd lvl by default" and goes to site1.com which has scripts of site1.com and site2.com then the scripts from site2.com get blocked and the ones from site1.com are allowed. That's ok.
But then a user goes to site2.com just to see what is that. As he visited this site - the rules from it also get temporary allowed, but they are allowed for all other sites, too, i.e. on site1.com too, which I consider a bug and it should be changed to that way: a user visits site2.com and the scripts of site2.com are allowed only on that site and nowhere else.

Feature 1
Add complex rules supporting exceptions.
Example: I add to whitelist a rule 1) goodsite.com# (Bug 1 should be fixed by adding this type of exceptions to the rules).
2) goodsite.com#@anothergoodsite.com
3) goodsite.com@anothergoodsite.com
4) goodsite.com@badsite.com (badsite.com is blacklisted)
and expect: 1) scripts from goodsite.com domain would run only on goodsite.com and nowhere else. I also thought of space saving, that's why just a @@ at the end is enough and is better than goodsite.com@goodsite.com
2) scripts from anothergoodsite.com and goodsite.com domain would run only on only on goodsite.com (and nowhere else).
3) scripts from anothergoodsite.com would be allowed on a goodsite.com, though a goodsite.com scripts would be still blocked.
4) scripts from blacklisted badsite.com would be allowed on the goodsite.com, and the rule with exception should have a higher priority over the blacklist.

I.e. the syntax I offer is the following: site[#][@site1[,site2[,...]]]
# - whitelists the scripts of site only for site
@site1[,site2[,...]]] - scripts from site1 and site2 would be allowed on site

Bug 2
NoScript options window stays always-on-top. I know it's a feature, and quite useful one, but the bug is that there is no button to minimize that window.

Feature 2
When you'll finish adding the layered system, could you add an about:config preference to change the way layers work?
someting like noscript.layerpermissions where 1 would be a default value, but changing it to 0 would make subscriptions' rules have a higher priority over user defined rules.
I request it exactly as an about:config preference, not as a checkbox somewhere in the settings so plain users won't even know of it.

Giorgio, could you please give a comment to this request?

iDrugoy wrote: Bug 1

The label says "Temporarily allow top-level sites by default", and "Temporarily" means until the end of the session for all NoScript commands, so it's definitely not a bug.
At most, it may be a RFE, and one which could be fulfilled only when a full DB-based permission abstraction, on top of CAPS, is done.

iDrugoy wrote: Feature 1
Add complex rules supporting exceptions.

This is definitely a low priority item, because

1. You can obtain more or less the same results using ABE
2. Some of these feature will be absorbed in the fine-grained permissions system

However, I understand that this would help subscription maintainers to have control over fine grained permissions, but please notice that ABE subscriptions are planned as well.
Furthermore, your proposed syntax should be probably reversed, since "@" stands for "at" and I when I see "goodsite.com@anothergoodsite.com" I read "goodsite.com at anothergoodsite.com", rather than vice-versa.
Finally, blocking scripts on the parent site but allowing on 3rd parties is impossible, given how Gecko works.

iDrugoy wrote: Bug 2
NoScript options window stays always-on-top. I know it's a feature, and quite useful one, but the bug is that there is no button to minimize that window.

Sorry, this is how XUL dialogs work. Unluckily you can't have it both ways.

iDrugoy wrote: Feature 2
When you'll finish adding the layered system, could you add an about:config preference to change the way layers work?

Yes.

First of all thanks for a reply

Giorgio Maone wrote:

iDrugoy wrote:Bug 1

The label says "Temporarily allow top-level sites by default", and "Temporarily" means until the end of the session for all NoScript commands, so it's definitely not a bug.

It's correct, but as a user I thought that feature should allow these scripts only on their parental sites, not everywhere else, that is what I complained about. But as you wrote

Finally, blocking scripts on the parent site but allowing on 3rd parties is impossible, given how Gecko works.

I have to ask: is the same situation here about Gecko's possibilities, or you just don't regard it as a bug and don't want to change current behavior?

Giorgio Maone wrote:

iDrugoy wrote:Feature 1

This is definitely a low priority item, because

1. You can obtain more or less the same results using ABE
2. Some of these feature will be absorbed in the fine-grained permissions system

However, I understand that this would help subscription maintainers to have control over fine grained permissions, but please notice that ABE subscriptions are planned as well.
Furthermore, your proposed syntax should be probably reversed, since "@" stands for "at" and I when I see "goodsite.com@anothergoodsite.com" I read "goodsite.com at anothergoodsite.com", rather than vice-versa.
Finally, blocking scripts on the parent site but allowing on 3rd parties is impossible, given how Gecko works.

Well, @ was just an example (though I still think it was the best one), you may change it to any other symbol, but this kind of rules would really make maintaining subscriptions easier.
And it's a pity about what you've said about Gecko. I should report this as feature-request to Mozilla dev team

Giorgio Maone wrote:

iDrugoy wrote:Bug 2

Sorry, this is how XUL dialogs work. Unluckily you can't have it both ways.

Well, ok, it doesn't bother me really much, just a little inconvenience

Giorgio Maone wrote:

iDrugoy wrote:Feature 2

Yes.

Great! Thanks.

iDrugoy wrote:is the same situation here about Gecko's possibilities, or you just don't regard it as a bug and don't want to change current behavior?

It's not the same as the Gecko limitation (i.e. it would be technically possible, even though after lots of work on NoScript's side), but I just don't plan to change this feature soon because there are different development priorities at this moment.