futtta's blog

After having NoScript disable the Facebook Like widget a couple of weeks ago, I felt really bad for Mark Zuckerberg who must have been feeling singled out by my actions. If only to make all widgets equal and as I don’t use them anyway, I’ve now told NoScript (only available in Firefox) to also block the Google+ and Twitter widgets with the following ABE User ruleset (under NoScript Advanced options):

# also stop google+ widget
Site plus.google.com
Accept from plus.google.com
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)


# and twitter
Site platform.twitter.com
Accept from twitter.com
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)

It was always my intention to elaborate on my small donottrack plugin for WordPress, but it was only when Automattic upgraded to the new asynchronous Quantcast code that I was forced to look actually dig in.

The new Quantcast-code doesn’t use the old-fashioned document.write, but inserts the javascript asynchronously with an insertBefore on the parent of the first script-node (as popularized by the asynchronous Google Analytics-code). Variations on this method would include e.g. using appendChild or adding it to head (although that might not exist).

A couple of months ago I experimented with the DomNodeInserted event, but that isn’t supported by all browsers. And even when it works, I found no consistent way to stop the tracking script (which was already added to the DOM, as the event is triggered after) from being loaded or executed. But last week while searching for a better solution I found a reference to javascript AOP on StackOverflow and after following some links I discovered the JQuery AOP-plugin.

JQuery AOP allows one to (amongst other things) add an advice around a method. When the method is called, the advice kicks in before the execution. The advice is a function which can investigate and change the parameters used by the method. And that’s exactly what the current version of DoNotTrack does; it has AOP.around (I’ve removed the JQuery dependency) catch insertBefore and appendChild, investigates the src-attribute and replaces that value if it points to quantserve.com before allowing the method execution to proceed.

 scriptParent=document.getElementsByTagName('script')[0].parentNode;  aop.around( {target: scriptParent, method: /[insertBefore|appendChild]/},         function(invocation) {                 if ((typeof(invocation.arguments[0].src)==='string')&&((invocation.arguments[0].tagName.toLowerCase()==='script')||(invocation.arguments[0].tagName.toLowerCase()==='img'))) {                         if (sanitizer(invocation.arguments[0].src)===true){                              invocation.arguments[0].src='javascript:return false;';                         }                 }                 return invocation.proceed();         } ); 

I’m working on a more generic version of an AOP-based WordPress Privacy plugin now. In a first stage it will probably be based on a blacklist, that is editable in the WP Privacy options-screen but at a later date a whitelist-based approach will be added (based on an integration with webpagetest.org). Let’s add that to my New Years resolution for 2012, shall we?

After almost a year of peace and quiet, Quantcast tracking code has returned to this blog. As reported by Brian Yang, the stupid hack that stopped the code from being included doesn’t work any more. Automattic recently switched to the new Quantcast-code, which instead of using the old-fashioned document.write now gets inserted asynchronously by a DOM-method (insertBefore). I’m looking at ways to stop this from happening or at least limit it one way or the other, but for the time being there’s no fix. Bear with me and do speak up (in the comments below of via the contact form) if you think you can help!

If you don’t like Facebook’s omnipresent Like widgets (there were already plenty of reasons why not to like them and last week’s cookie-debacle only added to that conclusion) and if you already use NoScript so you don’t want to install another plugin (like Ghostery, which reports any tracking activity and allows you to block it), you can put this in NoScript’s ABE user ruleset (NoScript Options -> advanced -> ABE);

# Allow Facebook scripts and objects to be included only
# from Facebook pages
Site .facebook.com .fbcdn.net .facebook.net
Accept from .facebook.com .fbcdn.net .facebook.net
Deny INCLUSION(SCRIPT, OBJ, SUBDOC)

This tells NoScript to allow Facebook scripts (you know, to visit facebook.com), but to stop them from being included in other sites. I guess with NoScript’s surrogate scripts one might even be able to replace Facebook’s Like-widget with one that just shows the old-fashioned (and harmless)  share-button. Now wouldn’t that be fun?

So what’s with all that nagging about tracking and that DoNotTrack plugin, you might wonder? Well, it’s pretty simple actually.

1. Some very popular WordPress plugins include 3rd party tracking, sometimes even without properly disclosing, often without means to disable this behavior
2. 3rd party tracking has privacy implications: all your visitors are tracked by the 3rd party, in general for behavioral marketing purposes (depending on what data is captured, tracking might even be illegal in some countries)
3. 3rd party tracking has a performance impact: every visit to your blog will include between 2 and 5 extra requests for the 3rd party tracking to succeed, effectively delaying full page rendering

It is my conviction that blog owners should be able to install and use WordPress plugins without having to worry about undisclosed tracking and that plugins should provide a way to disable such 3rd party tracking if included.

As this is not the case yet, we have to resort to (messy) solutions to stop unwanted tracking from happening. And that’s exactly what DoNotTrack does. It’s a small javascript-hack in a WordPress-plugin to stop 3rd party tracking introduced by some of the most popular plugins.

Some details from the readme.txt:

• What works:
  • It stops images or javascript being loaded form quantcast & media6degrees if these are added using document.write
  • It sets a2a_config.no_3p to true for addtoany not to execute the 3rd party tracking
• What does not work (yet): Tracking code added using innerHTML or appendChild/insertBefore is not yet intercepted (but I’m working a solution for that)
• What else might be added:
  • a widget which explains tracking for your visitors, with a link to this bookmarklet to opt out of many tracking/ advertising services at once
  • other known opt-out code to disable tracking for all visitors of your blog
  • support for the DNT-header as seen in Firefox4
• How you can help:
  • Provide me with links to plugins that include browser-based tracking + domain where the tracking is done.
  • Provide me with known opt-out code (javascript) to disable tracking services on a site.
  • Tell plugin writers you’re not happy with 3rd party tracking!
  • Tell your visitors about tracking & privacy, link to e.g. http://www.privacychoice.org/

And remember: if you host your WordPress blog yourself, you and nobody else should be able to decide who tracks your users!

While the entire German blogosphere seems to have discovered the pretty unpleasant, secretive inclusion of Quantcast tracking in the “WordPress.com Stats” plugin, I found an article on the blog that broke the story in Germany, that explains how you can somewhat limit (valid) privacy-concerns with Google Analytics.

You just have to push “_gat._anonymizeIp” as an option in the _gaq object, as shown on line 5 in this code snippet:

<script type="text/javascript">   var _gaq = _gaq || [];   _gaq.push(['_setAccount', 'UA-xxxxxxx-x']);   _gaq.push(['_trackPageview']);   _gaq.push(['_gat._anonymizeIp']);    (function() {     var ga = document.createElement('script');     ga.type = 'text/javascript';     ga.async = true;     ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';     var s = document.getElementsByTagName('script')[0];     s.parentNode.insertBefore(ga, s);   })(); </script> 

According to the relevant Google Analytics docs page, this:

“Tells Google Analytics to anonymize the information sent by the tracker objects by removing the last octet of the IP address prior to its storage. Note that this will slightly reduce the accuracy of geographic reporting.”

Call me naive (or overly idealistic), but shouldn’t your Google Analytics implementation have this option on as well?

A quick update about the WordPress.com Stats plugin secretive inclusion of Quantcast tracking:

• Automattic’s CEO proudly blogged about the huge leap Quantcast sees in the usage of sites in the Automattic network as from November and confirms self-hosted wordpress blogs are now considered part of Automattic’s network:
  

  the bump you see in November is when we started tracking Polldaddy, ID, Gravatar, and WordPress.com Stats users in addition to WordPress.com visitors

• A German law-firm that seems to specialize in internet, law and privacy wrote about Automattic’s  Quantcast tracking, claiming that using the Stats plugin migth put you at risk of legal action. I’m not a lawyer, but privacy laws in Germany (and Europe as a whole) are a lot stricter, so self-hosted bloggers should be careful when installing plugins that include tracking.
• My little DoNotTrack plugin got downloaded quite a few times this last month. Maybe I should iron out the quirks, make it a bit more generic and see if I can get it listed on the wordpress.org plugins repository?