Links not working on a website? You can fix that! · 2013-12-04 10:42 by Wladimir Palant

Adblock Plus users who decided to disable tracking have been complaining about severe issues on some websites for a while already. On the websites in question, clicking a link simply wouldn’t do anything unless one disables Adblock Plus. Our investigation has shown that bugs in Adobe SiteCatalyst are to blame for this issue. SiteCatalyst is a tracking solution that Adobe acquired from Omniture. A “forced link tracking” feature introduced recently is the source of these issues. Originally it was enabled for Google Chrome only, in a follow-up version for Mozilla Firefox as well.

What can be done about it?

Have you found a website with broken links? You can report it in the EasyList/EasyPrivacy forum (no registration required). The filter authors will add a new filter to block Adobe SiteCatalyst on this website. Unfortunately, blocking it on all websites by a generic filter isn’t possible because the website owners tend to install it under different names.

You might also be able to block that script yourself. In Firefox you can click the Adblock Plus icon on the problematic web page and choose “Open blockable items” from the menu. Enter “script” as the search term to list scripts only. Typically, the SiteCatalyst script will have “omniture” somewhere in its name, or it will be called “s_code.js”. If the corresponding line isn’t red then the script isn’t blocked — you can double-click the line to open the filter assistant and block it. Make sure to select the first option in the “Look for pattern” section of the filter assistant — you want to block only this one script, not the entire folder.

If you are a website owner using SiteCatalyst, you can disable link tracking in the configuration of your SiteCatalyst instance with the following statement:

s.useForcedLinkTracking=false;

Did you try to contact Adobe?

Yes, we did. We contacted Adobe mid-June, listed the bugs in SiteCatalyst and how they can be fixed. We were then asked for exact steps to reproduce and we delivered those, an explanation of how the issue can be reproduced on adobe.com. Our contact confirmed that this was exactly what they needed — and then there was silence. We’ve sent a reminder three months later but the current state is still that Adobe is for some reason unable or unwilling to fix the bugs in their scripts. So Adobe SiteCatalyst continues to cause issues on websites of Adobe’s paying customers and even on Adobe’s own website.

What are these bugs exactly? Are they hard to fix?

No, fixing these bugs is trivial. The main issue concerns the way data is transmitted. When a link is clicked on the website SiteCatalyst “swallows” the click and creates an image instead to send tracking data. It then generates a fake link click when this image loads. The code looks like this:

if(!im)
  im=s.wd[imn]=new Image;
im.s_l=0; 
im.onload=new Function('e','...');

The issue here is that the image can fail to load, something that might be caused by Adblock Plus but also by connectivity issues or a server failure. There will be no load event in that scenario but rather an error event and so the fake link click will never happen. The solution is to add the handler for both events so that it is always executed when the request is done:

im.onload=im.onerror=new Function('e','...');

Now SiteCatalyst isn’t meant to track more than one link click. Normally only the first link click should be swallowed by the bug above, the subsequent clicks would be handled as intended. The code looks like this:

if(!s.useForcedLinkTracking)
  ...
else
  s.b.removeEventListener(\"click\",s.bc,false);

This should remove the click listener after it is triggered for the first time. The problem is that the code adding the click listener looks like this:

s.b.addEventListener('click',s.bc,true)

Can you spot the bug? Right, the third parameter of the two calls (useCapture) isn’t identical — a capturing event listener has been added but the code tries to remove a non-capturing listener. As a result, removing the listener doesn’t actually happen.

This isn’t really rocket science. The bugs can be fixed with minimal changes that wouldn’t take any developer more than an hour to implement and test. The bug report we sent to Adobe had the same level of detail, it outlined exactly what went wrong and how it can be fixed. Why wasn’t Adobe able to fix their bugs then? Beats me.

Tags:

Comment [3]

  1. Anonymous · 2013-12-04 17:43 · #

    To what extent is the script identical across different sites? How difficult would it be to add some kind of content-based blocking?

    Reply from Wladimir Palant:

    There is a purely technical issue here: in order to see the script content it needs to load first. At that point it is no longer possible to prevent it from executing however.

    Of course one could possibly detect that this script is running and remove its event listener. However, this might have unintended side-effects if the script changes (a newer version or a modified version on some website). Also, it is unclear whether interfering with website functionality like that would be appropriate.

  2. Anonymous · 2013-12-08 01:54 · #

    > There is a purely technical issue here: in order to see the script content it needs to load first. At that point it is no longer possible to prevent it from executing however.

    In theory, couldn’t that be fixed in Firefox, adding a hook that runs before the script runs?

    Reply from Wladimir Palant:

    There is no way to add such a hook, neither in Firefox nor Chrome.

  3. Debashisa Jena · 2013-12-22 21:54 · #

    There is a solution! I got it! I switched my DNS servers to FoolDNS and it came out fixed for me! And Adblock Plus removes the frames “domains filtered” by element hiding rules, perfect combination!!

Commenting is closed for this article.