[FIXED] Base permissions are not propagated throughout

[GµårÐïåñ]

I was wondering if someone, Giorgio, can explain to me why NoScript is behaving in a way that seems contrary to the intended behavior. Let's take the site where I first experienced this issue and go from there to better explain what I mean.

1. I went to "www.scripnet.com"
2. My settings are set to show only base level and 2nd level domain items in the menu
3. I clicked on scriptnet.com first level item and temporarily allowed it
4. Then I get a partial icon and when you look at the menu it has the FULL domain, including the port designation and https protocol as a separate item to the base level that I have already allowed and should include ALL variations of the base level.

So why are we seeing this? A bug? Intended behavior? Why?



My expectation is that when I allow the base level of a domain, that all sub-domains, http/ftp/https/etc.. protocols and all trailing paths and ports to be allowed based on that permission. Seems not the case here, so I wanted to understand why that is. If a bug, then we can fix it and if intended behavior then I need to understand WHY do I need to allow the full https/uri/port configuration of the page separately to the base level permission? Especially that when I temporarily allow the full https://www.scripnet.com:8443/ path, it will disappear completely off the list, so it means that it should have been part of the original top level permission, no?



TIA

[Giorgio Maone]

This is an unfortunate implementation detail: CAPS don't automatically imply URLs with explicit port designations (http://some.site.com:1234) when domain (site.com) is in a list.
Therefore NoScript tries hard to make this implementation detail as transparent as possible, by automatically adding descendants with port designation the the temporary whitelist as soon as they're seen, but sometimes (due to cache effects or network glitches) this mechanism fails and you end to see spurious (from your "user-side" POV) but legit (from CAPS' POV) menu entries.

[al_9x]

Therefore NoScript tries hard to make this implementation detail as transparent as possible, by automatically adding descendants with port designation the the temporary whitelist as soon as they're seen

When ignorePorts==true, you hide the different ports intending to automatically whitelist them when the base domain is whitelisted. This is not happening in this case nor on my simple test, why? If your are not going to auto whitelist them, what's the point of hiding them in the first place?

Incidentally, for single label host names (http://localhost:81), not only is http://localhost:81 not initially hidden, but http://localhost is shown twice, can you please address the localhost questions in this thread

[GµårÐïåñ]

This is an unfortunate implementation detail: CAPS don't automatically imply URLs with explicit port designations (http://some.site.com:1234) when domain (site.com) is in a list.
Therefore NoScript tries hard to make this implementation detail as transparent as possible, by automatically adding descendants with port designation the the temporary whitelist as soon as they're seen, but sometimes (due to cache effects or network glitches) this mechanism fails and you end to see spurious (from your "user-side" POV) but legit (from CAPS' POV) menu entries.

With respect for you and what you have accomplished, I will accept that as a glitch and live with it but you can see why I would see that and say "what the heck happened here" and especially when I temporarily allow that specific one and it disappears instead of sticking around like an item that had to be allowed individually. There is truly no way to ensure that it gets whitelisted by NS on the client side without this happening? If you say no, I accept but I think that to some lesser knowledgeable individuals this might pose a great confusion. I was a pro and I couldn't resolve in my own mind why it was happening (of course that was before you explained) and it still bugs me slightly but I understand why you say it happens and I can respect that. But if you can find a way to make it more stable and consistent in capturing such situations and transparently resolving it, that would be great. Thanks again.

[GµårÐïåñ]

When ignorePorts==true, you hide the different ports intending to automatically whitelist them when the base domain is whitelisted. This is not happening in this case nor on my simple test, why? If your are not going to auto whitelist them, what's the point of hiding them in the first place?

I am not sure if you are having the same problem or confirming and agreeing with what is happening to me or you have a different issue here? It's not clear to me.

Incidentally, for single label host names (http://localhost:81), not only is http://localhost:81 not initially hidden, but http://localhost is shown twice, can you please address the localhost questions in this thread

Is this an issue that would benefit from being merged with this post as to keep the responses in one place?

[al_9x]

When ignorePorts==true, you hide the different ports intending to automatically whitelist them when the base domain is whitelisted. This is not happening in this case nor on my simple test, why? If your are not going to auto whitelist them, what's the point of hiding them in the first place?

I am not sure if you are having the same problem or confirming and agreeing with what is happening to me or you have a different issue here? It's not clear to me.

Confirming. When ignorePorts==true, all the ports should be auto white-listed. It's failing on the simplest of pages:

Code: Select all

<script src="http://test.invalid:81/"></script>

so this looks like a bug, rather than a glitch, Giorgio?

Incidentally, for single label host names (http://localhost:81), not only is http://localhost:81 not initially hidden, but http://localhost is shown twice, can you please address the localhost questions in this thread

Is this an issue that would benefit from being merged with this post as to keep the responses in one place?

No, the single label (localhost) symptoms are different, it's a different issue.

[Giorgio Maone]

Confirming. When ignorePorts==true, all the ports should be auto white-listed. It's failing on the simplest of pages:

Code: Select all

<script src="http://test.invalid:81/"></script>

so this looks like a bug, rather than a glitch, Giorgio?

Nope. There's no contract about them to be "autowhitelisted", even though it is what happens for documents (temporarily), because otherwise scripts couldn't run there.
For <script> elements, if the parent page is allowed the external script is let load if the same URL without port specification is allowed, but the whitelist is left untouched. This is meant to reduce useless whitelist clutter.

[al_9x]

Confirming. When ignorePorts==true, all the ports should be auto white-listed. It's failing on the simplest of pages:

Code: Select all

<script src="http://test.invalid:81/"></script>

so this looks like a bug, rather than a glitch, Giorgio?

Nope. There's no contract about them to be "autowhitelisted", even though it is what happens for documents (temporarily), because otherwise scripts couldn't run there.
For <script> elements, if the parent page is allowed the external script is let load if the same URL without port specification is allowed, but the whitelist is left untouched. This is meant to reduce useless whitelist clutter.

This seems very confusing and misleading. If the script is allowed to run (which I didn't realize before but just confirmed experimentally), what does it mean for its domain:port to remain not whitelisted? What is the point of it being in the menu? The script is already allowed, so what reason is there for whitelisting it? All it seems to do is mislead you into thinking that something is blocked, when it isn't. Thankfully, with ignorePorts==false everything is explicit and clear, no surprises.

[Giorgio Maone]

There's no contract about them to be "autowhitelisted", even though it is what happens for documents (temporarily), because otherwise scripts couldn't run there.
For <script> elements, if the parent page is allowed the external script is let load if the same URL without port specification is allowed, but the whitelist is left untouched. This is meant to reduce useless whitelist clutter.

This seems very confusing and misleading. If the script is allowed to run (which I didn't realize before but just confirmed experimentally), what does it mean for its domain:port to remain not whitelisted? What is the point of it being in the menu?

These are all UI-level glitches, which will eventually be fixed.
Actually the easiest shortcut to fix them is adding the site to the temporary whitelist (just like I already do for frames), but I would have preferred not to (even though it meant yet another "special case" in the UI code) in order to minimize the redundant entries

[Giorgio Maone]

Please check latest development build.

[al_9x]

Please check latest development build.

scripnet.com is ok, but there are issues with my test page

test.invalid=127.0.0.1

http://test.invalid/tests/porttest/porttest.htm

Code: Select all

<script src="http://localhost:81/tests/porttest/porttest.js"></script>
<script src="http://test.invalid:81/tests/porttest/porttest.js"></script>

1. when "test.invalid" is temp allowed, "http://localhost:81" is also whitelisted (shouldn't be) and appears in the menu with the port
2. when "http://localhost" is temp allowed first, it disappears from the menu (should show forbid), and "http://localhost:81" is not whitelisted, only "http://localhost" (I think both should be?)

[Giorgio Maone]

scripnet.com is ok, but there are issues with my test page

test.invalid=127.0.0.1

http://test.invalid/tests/porttest/porttest.htm

Code: Select all

<script src="http://localhost:81/tests/porttest/porttest.js"></script>
<script src="http://test.invalid:81/tests/porttest/porttest.js"></script>

1. when "test.invalid" is temp allowed, "http://localhost:81" is also whitelisted (shouldn't be) and appears in the menu with the port
2. when "http://localhost" is temp allowed first, it disappears from the menu (should show forbid), and "http://localhost:81" is not whitelisted, only "http://localhost" (I think both should be?)

Fixed in latest development build.

http://localhost:81 is not whitelisted if http://localhost is temp allowed first because the script element pointing it doesn't even attempt to be loaded (because the document is not allowed to run scripts), and therefore it doesn't get intercepted and auto-allowed. There's no relevant side-effect, though, for usability (which is the aim of auto-allowing).

[al_9x]

Fixed in latest development build.

http://localhost is still disappearing from the menu after being allowed first. This doesn't happen with portless scripts, and I don't think should happen here.

Also, the localhost duplication issue you intended to fix is still in rc7

[Giorgio Maone]

Also, the localhost duplication issue you intended to fix is still in rc7

I couldn't reproduce that one. Could you be more detailed?

[al_9x]

Also, the localhost duplication issue you intended to fix is still in rc7

I couldn't reproduce that one. Could you be more detailed?

http://localhost/tests/porttest/localhost.htm

Code: Select all

<script src="http://localhost:81/tests/porttest/porttest.js"></script>

if you load the above, "http://localhost" is in the menu twice, Fx 3.6.10, NS 2.0.3.1rc7, new profile