google-analytics surrogate breakage on wikia.com

[Alan Baxter]

On http://dragonage.wikia.com/wiki/Dragon_Age_Wiki, the flyouts for the menu on the left side no longer work unless I allow google-analytics.com. This behavior occurs in both NS 2.0 and NS 2.0.1rc2. According to the original reporter, the flyouts worked properly -- even with google-analytics.com untrusted -- with "1.9.9.* and earlier NoScript versions". Original report at http://forums.informaction.com/viewtopi ... =10&t=4765

I guess this is caused by one of the surrogate changes in NS 2.0. Could you add it to your "to do" list, Giorgio?

[therube]

I sometimes get a flyout, at least for some of the menu items, & then it reverts to (what I called) a flydown.

Only wikia.com allowed.

Perhaps that "Featured Media" (slideshow) is interfering? Or not?

Allowing google-analytics.com & I always get a flyout.

[al_9x]

This is not a surrogate issue, it's caused by a <noscript> element loading of a stylesheet. You can check it by disabling "show the <NOSCRIPT> element after blocked script"

I have two questions about this:

1) this <noscript> element does not directly follow the blocked script. It follows an inline scripts that is not blocked, so why is it activated?

2) Should the loading of a stylesheet from <noscript> perhaps be considered a web bug and blocked? It isn't now.

[Giorgio Maone]

1) this <noscript> element does not directly follow the blocked script. It follows an inline scripts that is not blocked, so why is it activated?

This is a recent change, prompted by the need to make the new style reCaptcha from Google work on (almost) any site with any permission combination.
The rationale is that it's often observed that 3rd party scripts are included and then used by the immediately following embedded script element, with a noscript element placed after the last one.
NoScript now searches for the first noscript sibling which immediately follows the blocked script or one of its immediate successors, if they're all script elements.

2) Should the loading of a stylesheet from <noscript> perhaps be considered a web bug and blocked? It isn't now.

If you take web bugs as security issues (which are not), any load (either frames, plugins, images, stylesheets, DTDs, prefetched links and so on) should be considered a web bug.
However, since they're NOT a security issue and we've got other means to block them, if we're determined to do, NoScript takes the pragmatic approach of considering the most obvious and common kind, i.e. images. For instance if frames were considered web bugs, reCaptcha wouldn't work on noscripted pages.

[therube]

Neat. I kind of learned something today. I think.
But it's got me scratching my head. Which may be your 1) question?

If wikia.com is not Allowed, so <SCRIPT> is blocked, then noscript.css should run (in a default NoScript install).
Presumably noscript.css is broken? Or else the menu's would work, which they do not.

Now if wikia.com is Allowed, <SCRIPT> is not blocked, so (perhaps) the <NOSCRIPT> element should not run, but it is?
And is that what is breaking the site, when google-analytics.com is not allowed?

Now if wikia.com is Allowed, & if you disable Show the <NOSCRIPT> ... follows a blocked <SCRIPT>, then noscript.css does not run, & the site displays correctly, even without allowing google-analytics.com?

[Giorgio Maone]

Mmm, maybe the correct work around here is marking script elements which we've run surrogates for as "executed" some way, thus preventing them from being evaluated for <NOSCRIPT> activation.

[al_9x]

The rationale is that it's often observed that 3rd party scripts are included and then used by the immediately following embedded script element, with a noscript element placed after the last one.
NoScript now searches for the first noscript sibling which immediately follows the blocked script or one of its immediate successors, if they're all script elements.

I suppose that's a common pattern, but the counter example is probably also common (though it doesn't apply here). You put all your script tags in a row, with a <noscript> at the end which is not targeted for/related to the blocked script at the begging. One way to mitigate this would be to terminate the <noscript> search at the first allowed external script, i.e. only consider inline scripts as being related to the preceding blocked external script. Would that still take care of recapcha?

NoScript takes the pragmatic approach of considering the most obvious and common kind, i.e. images. For instance if frames were considered web bugs, reCaptcha wouldn't work on noscripted pages.

What do you think of blocking everything with an exceptions domains setting (covering reCapcha)?

If not the above, what do you think of blocking everything if the blocked script is untrusted (this would actually apply here for many who have analytics as untrusted) This seems to me definitely a good idea, untrusted being indication that you don't want them to weasel out of the blockage in any way.

Mmm, maybe the correct work around here is marking script elements which we've run surrogates for as "executed" some way, thus preventing them from being evaluated for <NOSCRIPT> activation.

Seems like a good idea. The presence of a surrogate, indicates that the consequences of blocking have been thought through, so there is no need for alternative content. Also perhaps the surrogate itself can signal whether or not it wants <noscript> activation (via the script or a special character)

[Giorgio Maone]

One way to mitigate this would be to terminate the <noscript> search at the first allowed external script, i.e. only consider inline scripts as being related to the preceding blocked external script. Would that still take care of recapcha?

It would work for reCaptcha, not sure about other stuff.

NoScript takes the pragmatic approach of considering the most obvious and common kind, i.e. images. For instance if frames were considered web bugs, reCaptcha wouldn't work on noscripted pages.

what do you think of blocking everything if the blocked script is untrusted (this would actually apply here for many who have analytics as untrusted) This seems to me definitely a good idea, untrusted being indication that you don't want them to weasel out of the blockage in any way.

You mean not to show the <noscript> element for untrusted scripts? That seems OK to me.

Mmm, maybe the correct work around here is marking script elements which we've run surrogates for as "executed" some way, thus preventing them from being evaluated for <NOSCRIPT> activation.

Seems like a good idea. The presence of a surrogate, indicates that the consequences of blocking have been thought through, so there is no need for alternative content. Also perhaps the surrogate itself can signal whether or not it wants <noscript> activation (via the script or a special character)

This is done in latest development build ("signal from surrogate" aside, since however the surrogate may easily make up for the noscript element in its code, if it's required).

[al_9x]

One way to mitigate this would be to terminate the <noscript> search at the first allowed external script, i.e. only consider inline scripts as being related to the preceding blocked external script. Would that still take care of recapcha?

It would work for reCaptcha, not sure about other stuff.

I think showing a <noscript> following an allowed external <script> just because some preceding script in a contiguous chain has been blocked, will create more problems than it solves (if it solves any at all).

You mean not to show the <noscript> element for untrusted scripts? That seems OK to me.

I was suggesting blocking all requests (not just images) from such <noscript> as web bugs (for privacy and to prevent forcing of unwanted content on the user). Not showing <noscript> at all is going a bit further, but I guess is ok as well.

This is done in latest development build ("signal from surrogate" aside, since however the surrogate may easily make up for the noscript element in its code, if it's required)

fixed