AddToAny removed-from-here


Update 02-2015: the information below does not reflect the way AddToAny works now and as such only has historical value, read this comment by the developer for more info.
When looking at my blog’s performance in Google Webmaster Tools I saw Google complained of multiple dns-lookups. I knew about stats.wordpress.com, google-analytics.com (well, yeah …) and gravatar.com, but one domain in the list didn’t make sense to me at all; media6degrees.com, so I started to investigate a bit. Grepping the wordpress-, theme- and plugin-code on my server didn’t reveal anything, so I went into Firebug to see what was happening in javascript.
Apparently the AddToAny WordPress-plugin was initiating the call:

  1. add-to-any requests http://static.addtoany.com/menu/page.js (which is rather big but gzipped & cache-able)
  2. page.js in turn contains tracking (near the end of the file), by requesting an 1X1 pixel image at http://map.media6degrees.com/orbserv/hbpix?pixId=2869&curl=<encoded URL of page>
  3. media6degrees then sends the pixel and … sets multiple cookies in the process

And what’s media6degrees business you ask? Maybe they’re just providing the add-to-any author with statistics? Well, not exactly. This is what media6degrees writes on their website: “We deliver scalable custom audiences to major marketers by utilizing the online connections of their consumers.” So by using AddToAny, you’re providing media6degrees with data about your site’s visitors, which they can use to sell targeted communication to their customers.
If visitors of small-time blogs like mine would be the only ones affected by this, the damage would be limited. But AddToAny is also implemented on large local news-outlets such as deredactie.be or De Standaard Online and no doubt on some big international sites as well. Somehow I doubt those organizations know they’re feeding their visitors to media6degrees and I bet some of them would even strongly disagree.
I’m not happy about this, that much is clear. AddToAny offers great functionality, but:

  • it adds unneeded requests to my page, causing the page to finish loading later (dns-request + http-request)
  • it enrolls my site visitors in a targeted communication platform without anyone knowing (or agreeing)
  • none of this is communicated on the AddToAny website or on the AddToAny WordPress plugin page

I mailed the author about this earlier this week (when i didn’t even know about media6degrees tracking cookies yet), but got no feedback up until now and I logged an issue on the wordpress.org support forum as well. And I decided to pull the plug on AddToAny off course, replacing it with sociable, making my blog render yet another millisecond faster, while at the same time protecting my visitors from this sneaky behavioral tracking by AddToAny and media6degrees.

Google Webmaster Tools Irony

A couple of days ago Google launched Site Performance as a labs project in Google Webmaster Tools. Being obsessed with speed is great and there indeed are valid remarks for this blog, but what to think of the advice below:

google site performance ironyThat’s right, I really should gzip-compress those javascript-resources! Google, please give me access to your servers so I can fix this immediately!

Trading eAccelerator for APC

Yesterday I somewhat reluctantly removed eAccelerator from my server (Debian Etch) and installed APC instead. Not because I wasn’t satisfied with performance of eAccelerator, but because the packaged version of it was not in the Debian repositories (Andrew McMillan provided the debs), and those debs weren’t upgraded at the same pace and thus broke my normal upgrade-routine. Moreover APC will apparently become a default part of PHP6 (making the Alternative PHP Cache the default opcode cache component). Installation was as easy as doing “pecl install apc” and adding apc to php.ini. Everything seems to be running as great as it did with eAccelerator (as most test seem to confirm).