Well, good news, have been running with the revised and corrected rule all day and not one incidence of the previously experienced errors. Many thanks.
Just one question, the format of the rule that you got wrong: was the format invalid? If so, shouldn't NoScript have reported the rule as invalid in format?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
grahamt wrote:Well, good news, have been running with the revised and corrected rule all day and not one incidence of the previously experienced errors. Many thanks.
Just one question, the format of the rule that you got wrong: was the format invalid? If so, shouldn't NoScript have reported the rule as invalid in format?
It was not an invalid regular expression, just it didn't do what it was meant to do.
OK, still good news and the iGoogle page itself seems to post far, far quicker. I suppose that's because NoScript isn't doing any of the checking that previously slowed it down. As I understand it, the effect of the new rule is to turn off XSS checking for the Google website. Whilst that may have solved the immediate problem, is that wise? I thought that's why I installed NoScript in the first place!
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729)
grahamt wrote:As I understand it, the effect of the new rule is to turn off XSS checking for the Google website. Whilst that may have solved the immediate problem, is that wise?
The effect is actually turning off XSS checks for requests originated by the iGoogle startup page.
This is less safe than default setup, but much safer than turning off XSS completely or uninstalling NoScript.
Could you try latest development build (1.9.9.32), removing the XSS exception?
InjectionChecker should be about 5 times faster on that kind of nested URIs, therefore your problem may be fixed.