Page 1 of 1

<noscript> and web bug problems

Posted: Sun Aug 08, 2010 2:51 pm
by al_9x
http://www.mailinator.com/valueclickvert.jsp

This page has a <noscript> following a <script> with an image web bug.
  1. When mailinator.com is not whitelisted
    1. With default settings - image shown as expected, but 2 requests for it are made, is <noscript> being added twice?
    2. With "hide noscript" ("forbid web bugs" autochecked) - image is still shown (shouldn't be) - 1 request
    3. With "hide noscript" without "forbid web bugs" - this combination is not supposed to be possible, but if you close and reopen options you can uncheck "forbid web bugs" - image is still shown (shouldn't be) - 2 requests
    4. With "forbid web bugs" - image is still shown (shouldn't be) - 1 request
  2. When mailinator.com is whitelisted
    1. With default settings - image not shown (should be) - but 1 request is still made
    2. Without "show noscript for blocked script" - ok (no image, no request)
    3. With "hide noscript" ("forbid web bugs" autochecked) - ok (no image, no request)
    4. With "hide noscript" without "forbid web bugs" - image not shown, but 1 request is still made
    5. With fastclick.net untrusted - ok (no image, no request)

Re: <noscript> and web bug problems

Posted: Fri Nov 05, 2010 11:44 pm
by Giorgio Maone
Unfortunately this is due to a side-effect of the HTML parser (which seems to be standardized by HTML 5, since it's exhibited by Chrome as well): since <NOSCRIPT> element cannot, by spec, appear in the head section, its content (without its <NOSCRIPT> wrapper!) is moved (in Chrome) or copied (in Firefox) in the beginning of the body section.
Once is there, NoScript has no way to understand we're talking about a "web bug" as we define it (an image inside a NoScript element).

Even though I could search for some kind of work-around (e.g., since Firefox copies rather than moving, hence duplicate the request, I could annotate any web-bug found by NoScript's policy and prevent the same image from being loaded later in the document), but I'm not very concerned about it, because a web-bug in the head usually (like in this case) mean that we're inside an iframe, which is already a tracker.