bug: noscript.untrusted

[kwiniec]

I think I found a bug. When I set noscript.untrusted to a second-level domain of the form foo.bar and then vist URLs of the form http://foo.bar or http://www.foo.bar ("blacklist mode"), javascript is ignored as expected. But when I restart the browser and then vist those URLs, javascript is unexpectedly executed. In fact, the only noscript.untrusted entries that work the same after a browser restart as they do after setting are those that fully specify resource type and lower-level domains. I found this a couple of years ago in FF2, but until today hadn't tested all the permuations and chalked it up as a "feature".

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.14) Gecko/2009082706 Firefox/3.0.14 NS/1.9.8.86

P.S. What URL formats, delimiters, and wildcards are required/optional/unused/illegal in the noscript.untrusted string?

[Giorgio Maone]

Do you edit the preference manually from about:config?
Does it change after browser restart?

[kwiniec]

Do you edit the preference manually from about:config?

Yes.

Does it change after browser restart?

No, the string does not change.

[Giorgio Maone]

Do you edit the preference manually from about:config?

Yes.

Then the strange thing is that it work before restart.
Because of legacy issues with Mozilla code, a 2nd level domain entry matches its subdomains but not itself, unless the version including scheme is explicitly put in the list.
Using the UI to allow/mark as untrusted hides this implementation details.

[kwiniec]

Then the strange thing is that it work before restart.

Indeed. In fact, upon retesting, I see the status bar icon does not indicate javascript is being blocked even though it is.

Because of legacy issues with Mozilla code, a 2nd level domain entry matches its subdomains but not itself, unless the version including scheme is explicitly put in the list.

I now see this part working as described -- manually entering foo.bar does indeed block http://www.foo.bar after restart. I must have been hallucinating earlier.

Using the UI to allow/mark as untrusted hides this implementation details.

I also see now that using the UI to block foo.bar (which I never tried before) explicitly adds foo.bar, http://foo.bar, and https://foo.bar to the noscript.untrusted string. And with foo.bar matching http://www.foo.bar (and presumably https://www.foo.bar), all the bases are covered. So the only bug is the first one above, and its primary effect is only to prevent anyone figuring out how it works. Which I guess is of arguable importance.

And so I would like to change this to a low-priority enhancement request: please consider someday adding something akin to a "noscript.mozlegacycompat" boolean which defaults to "true" and which when set to "false" allows foo.bar to match itself. This would make managing the untrusted list a lot faster and less error-prone.