"Enable GhostRank" in Ghostery 2.7.2 conflicts with NoScript

[fixanoid]

Hi! This is a repost from Ghostery support board. Original topic here: https://getsatisfaction.com/ghostery/to ... h_noscript

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120317 Firefox/14.0a1

Steps to reproduce:
1. In a new profile, install Ghostery 2.7.2 and the latest NoScript (currently 2.3.5rc6).
2. Enable GhostRank in Ghostery. Other options can remain unchanged.
3. Visit https://adblockplus.org/en/development- ... stallation

Actual result:
The ABP page shows but does not jump to the anchor where the heading "How do I install/update development builds?" is.

Expected result:
I do not need to scroll to the desired part.

Note:
1. If GhostRank is disabled, the ABP page works as expected.
2. If I allow the scripts in ABP from NoScript, the page works as expected. This issue only affects NoScript-blocked sites.
3. This issue does not occur in Ghostery 2.7.1.

Thanks in advanced and thank you for this great extension.

Here are some findings that I've got from Ghostery side:

Appears to be some kind of a NoScript vs Ghsotery issue?

When GhostRank is on, new version of Ghostery will collect page analytics: load time and number of ad spots. To determine the number of ad spots, I run the page through a retrieval code that iterates over page elements and compares them to what an should be: basically a size check for for an ad: is it 300 x 250? If yes, its an ad spot. So, part of that code checks actual CSS values by calling this:

v = doc.defaultView.getComputedStyle(el, null).getPropertyValue(prop);

for height and width. The value is returned to my code just fine, but it appears that the page stops processing after this when NoScript is installed. I'll try to determine what causes this in NoScript code, assuming it does something there... Stay tuned =)

I've done my testing on Firefox 11, Windows 7, Ghostery 2.7.2 and NoScript 2.3.5 with the same result as original poster. NoScript options were not fiddled with, so all defaults were on.

I've found the issue in Ghostery, but no explanation as to why this would collide with NoScript. Quick examination of NoScript code led me to believe I need a more qualified opinion =). Please let me know if anything else is needed to debug and find the issue. Thanks!

[Tom T.]

From your top link:

2. If I allow the scripts in ABP from NoScript, the page works as expected. This issue only affects NoScript-blocked sites.

The first part of that sentence implies that ABP itself is running scripts to do some function. (I don't use ABP; sorry.) If so, of course ABP scripts would have to be allowed.

When GhostRank is on, new version of Ghostery will collect page analytics: load time and number of ad spots.

This is a long shot, but is Google Analytics or urchintracker used for that purpose? - both default-denied in NS.

3. This issue does not occur in Ghostery 2.7.1.

So the question is, what changed in Ghostery from 2.7.1 to 2.7.2, especially something that might involve scripting? Possibly a Ghostery issue, not an NS issue.

FWIW, NoScript is set to be the *last* processor of requests, precisely so that ABP users would get to see things, and decide whether to block them, before NS blocks them.

You could try latest development build, to see if it fixes the issue.

When the error happens, what shows in Error Console (Ctrl+Shift+J, or Firefox Tools > Web Developer > Error Console)?

Could you please copy any red Error messages and paste them here? Also please click "Messages", and post here any messages relating to NoScript, including ABE or XSS.

[fixanoid]

Hi Tom, thanks for your attention. Here are some more details.

1) ABP link is used as an example, ABP is not installed and not needed to replicate this issue.
2) Ghostery does not use GA or urchin, its a pixel XHR call to our own server.
3) Ghostery 2.7.2 does change this stuff from 2.7.1 as seen in quote #2 on my original post, there is a new line of code:

v = doc.defaultView.getComputedStyle(el, null).getPropertyValue(prop); The value is returned to Ghostery code just fine, but it appears that the page stops processing after this when NoScript is installed.

4) I've installed latest dev build, 2.3.6rc4 and it has the same issue.
5) Error console contains this error:

Error: Image corrupt or truncated: <unknown>
Source File: <unknown>
Line: 0

And message console is empty.

Thanks!

[Tom T.]

Hi Tom, thanks for your attention. Here are some more details.

1) ABP link is used as an example, ABP is not installed and not needed to replicate this issue.

Sorry, saw it in your OP and assumed it was part of the package or of what was causing the error.

2) Ghostery does not use GA or urchin, its a pixel XHR call to our own server.
3) Ghostery 2.7.2 does change this stuff from 2.7.1 as seen in quote #2 on my original post, there is a new line of code:

v = doc.defaultView.getComputedStyle(el, null).getPropertyValue(prop); The value is returned to Ghostery code just fine, but it appears that the page stops processing after this when NoScript is installed.

4) I've installed latest dev build, 2.3.6rc4 and it has the same issue.
5) Error console contains this error:

Error: Image corrupt or truncated: <unknown>
Source File: <unknown>
Line: 0

And message console is empty.

Thanks!

You're quite welcome.

As in this thread on NoScript blocking an SVG-based POC, NS treats some JS-type functions, calls, or hooks as scripts, or in his terms, "scriptlets", and blocks them accordingly, because they can in fact be used for malice.

I have a very strong hunch that this is what is happening here, although I will ask Giorgio to confirm and perhaps find a work-around.

Before I escalate this to Giorgio, though, could I ask of you one last diagnostic favor? I know that a number of Ghostery users have reported the problem, but those who use Ghostery, NS, etc., tend to have other add-ons also (frequently ABP, but many others, of course), so we need to rule out an extension conflict, even if caused by a third add-on (not Gh or NS). Therefore, please:

1) Create a clean profile
2) Install latest version of Ghostery, leaving all default settings (plus the Rank part that toggles the issue, apparently)
3) Install latest (stable or dev build) version of NoScript, leaving all the default settings.

Does the issue still persist? If not, another add-on may be jamming up the works between Gh and NS.

If it persists after this acid test, I'll escalate this to Giorgio.

Thank you and all of the Ghostery team and users for your patience.

[Giorgio Maone]

The image corrupt message doesn't seem to have anything to do with this, because it happens even with NS disabled.
I could reproduce on a clean profile with Gh & NS.
Investigating...

[Giorgio Maone]

NoScript per-se has nothing to do with this problem either.
It happens also with NoScript uninstalled and JavaScript disabled from Firefox's own content panel.
I'd call this either a Ghostery or a Firefox bug...

[Tom T.]

NoScript per-se has nothing to do with this problem either.
It happens also with NoScript uninstalled and JavaScript disabled from Firefox's own content panel.
I'd call this either a Ghostery or a Firefox bug...

Do you have any idea why OP reports that allowing script on the visited page -- ABP page, in their test case -- makes the issue disappear?

2. If I allow the scripts in ABP ((The visited page - Tom T.)) from NoScript, the page works as expected. This issue only affects NoScript-blocked sites.

[Giorgio Maone]

NoScript per-se has nothing to do with this problem either.
It happens also with NoScript uninstalled and JavaScript disabled from Firefox's own content panel.
I'd call this either a Ghostery or a Firefox bug...

Do you have any idea why OP reports that allowing script on the visited page -- ABP page, in their test case -- makes the issue disappear?

2. If I allow the scripts in ABP ((The visited page - Tom T.)) from NoScript, the page works as expected. This issue only affects NoScript-blocked sites.

Well, it's quite simple: the above is incorrect, should be "This issue only affects JavaScript-disabled sites", no matter the means (NoScript, Firefox, CSP, iframe=sandbox or anything else). As such, it's not a NoScript bug at all.