futtta's blog

I finally found some time to continue to work my other WordPress plugin. WP DoNotTrack checks for elements being added to the DOM by JavaScript to stop 3rd party tracking by some of the major plugins or themes.

Version 0.6.0, which I released last week, features a new “forced” option. This mode aims to provide better compatibility with JavaScript-optimizing plugins such as Autoptimize and W3 Total Cache by adding the relevant code only after those optimizers have done their job, using the output buffer. There will probably be a 0.6.1 today or tomorrow, to solve a small problem with mixed HTTP/HTTPS requests on the admin-page while in HTTPS. The output buffer sure is a powerful thing and for version 0.7.0, I’ll build on that to optionally filter the full HTML (with PHP Simple HTML DOM Parser) to stop unwanted requests for images, scripts or iFrames in there.

Do contact me if you found a bug, if you have questions or if you’d like specific feature to be added, I tend to rely heavily on user feedback to improve my plugins! And if you’re happy with how it works, drop by on the WP DoNotTrack-page on wordpress.org to rate it and/ or to confirm it works with your version of WordPress!

On a blog that uses WP YouTube Lyte which I happened to stumble across, the following warning was displayed:

Hey! If you’re browsing in Firefox, there’s a very good chance that you won’t see youtube / video embeds.

As I really don’t like bugs but couldn’t reproduce any issue myself, I contacted the blog’s owner to find out what was happening. The description of the problem was pretty confusing:

The still shot/first frame of the video is there with the play icon, so things look hopeful, but when you click on the play icon the entire video disappears from the page. Page structure / layout does not change, but you are left staring at a blank white box where the embed should be.

A white div of death, really … Anyway, to cut a long story short, the misbehavior was caused by “Karma Blocker“. This Firefox addon “blocks resources based on their karma”, using a ruleset that scores behavior to blocks banners, trackers and also WP YouTube Lyte (or rather, the YouTube iFrame). Apparently the combination of the bad karma of JavaScript and the iFrame triggered the blocking mechanism.

I couldn’t code around Karma Blocker and chances are small the default configuration will give YouTube iFrames better karma, but the next version of WP YouTube Lyte (1.1.0, to be available soon) will display a simple message kindly letting users know they might want to adapt their Karma Blocker’s weightings.

But why is karma punishing me?

Let’s apply the duck-test to Google;

1. They’re changing their privacy policy without offering users a true opt-out
2. They severely limited access for Scroogle, the Google-scraper for privacy-nuts, to the point where it is effectively out of service (although apparently Google isn’t the only one to blame)
3. They have been caught with their hands in your cookie jar, not only bypassing user’s cookie preferences in Safari but also in Internet Explorer

So if Google looks, swims and quacks like it doesn’t care about user privacy, it must be that it … doesn’t care about user privacy.

I on the other hand do care about my privacy, so I decided to put even less eggs in Google’s basket: I’ve switched my search-engine to startpage.com, which is operated by a Dutch company (i.e. one which has to comply with stricter European privacy laws) and which guarantees privacy while being powered by Google.

Startpage’s only downside: they are blocked by our company internet-filter because they provide proxy-services, so as an alternative I also use the less powerful DuckDuckGo (I changed keyword.url in Firefox’ about:config to “https://duckduckgo.com/?q=”). And a nice bonus; DuckDuckGo also has a nice Android-app, which I have installed to replace Google Search on my Sammy SII as well.

Jailbreaking is not a crime, but we shouldn’t take that for granted, because as Bunnie (XBox hacker) writes;

Three years ago, the [U.S.] Copyright Office agreed to create an exemption to the Digital Millennium Copyright Act so that folks could jailbreak their smartphones. But that exemption is about to expire.

Given the fact that the U.S. jailbreaking-scene is an important contributor, I signed the EFF petition which asks the Copyright Office for continued support for jailbreakers;

Being an avid Android-user, jailbreaking permits me to replace heavily customized (and in some ways crippled, think CarrierIQ) vendor-specific versions of Android with clean, crisp, fast and secure after-market “mods” such as CyanogenMod.

You should really sign this as well!

AddToAny, one of the most popular sharing-widgets around, has had 3rd party tracking by Media6degrees for quite some time already. I wasn’t too happy about that, but it did have the no_3p option to disable this “functionality”. Half a year ago however AddToAny was acquired by Lockerz.com and it now includes tracking by Lockerz.com which cannot be turned off and does not check for navigator.doNotTrack either.

I’ve contacted the developer (Pat’s a swell guy, really) and he answered he would look into honoring the DoNotTrack header, which he wrote he’d love to include in Q1 somewhere. In the mean time, if you have AddToAny on your site, you can already hide the Lockerz “Earn” tab. And if you’re on WordPress, you could install (or upgrade) WP DoNotTrack, which I’ve updated to stop the Lockerz tracking (make sure lockerz.com is your blacklist).

If there’s a Drupalista out there that uses AddToAny and would like to stop Lockerz tracking; I’d be happy to co-author a Drupal DoNotTrack module, do get in touch!

Did you know you can limit the damage an iframe can do by adding the “sandbox” attribute? And that you can add a value to that attribute to loosen your grip if you choose to do so?

I remember reading about this a couple of years ago or so, but forgot as  support for this html5 spec was limited to Chrome (Apple added support in Safari as well). But while investigating a problem a WP DoNotTrack-user was facing, I re-discovered iframe sandboxing (it effectively stopped the javascript-based tracking inside the iframe) and noticed that support for it is to be included in Internet Explorer 10 and that Mozilla is finally working on an implementation as well.

So yeah, the option to sandbox iframe’s pointing to blacklisted (or non-whitelisted) hostnames will probably be in a future version of WP DoNotTrack. Stay tuned!

I pushed out a major new version of WP DoNotTrack to the WordPress plugin repository and major in this case means:

• you can now choose between a blacklist and whitelist-approach (previous version did blacklisting only)
• define what exactly is in that black- or whitelist (previous version came with a hardcoded blacklist)
• option to block javascript-initiated tracking code from being added for all your visitors, or just those that explicitly opted out of tracking in their browser (supported in MS IE9 and Firefox 9, not supported in Google Chrome)
• and off course an option-page under wp-admin to change all these settings

Because of these new features (4 of them) and because I think the plugin is already at least 50% mature, I decided to bump the version from 0.1.0 to 0.5.0. Never been good at math anyway …

If you encounter any problems when installing or configuring this plugin, you might find valuable info in the FAQ. But here’s two tips anyway:

1. In general caching and js-aggregating plugins can interfere, so you might want to disable those while working on your WP DoNotTrack configuration and re-enable (with cleared caches) once you’re satisfied with the result.
2. If you’re running WP YouTube Lyte with the bonus “donottrack” feature activated, you’ll want to deactivate that before installing/ activating WP DoNotTrack. If you don’t do that, you’ll have to turn to the FAQ …

Don’t hesitate to contact me or leave a comment beneath this here little blogpost if you run into problems, if have a feature request or if you just want to chat a little. I just love receiving feedback!