Category Archives: wp donottrack

Do not donate to me!

Some people ask me if they can donate for my software. My answer invariably is they can’t, because I don’t want money. Instead I would like them to make a small donation to a good cause!

Why? Well, I’m a very lucky guy, living in the richest region of one of the richest countries of the world and having a full-time job that allows me and my family to live a comfortable life. Software is “just a hobby” which I hope is a small contribution to make the web (and by extension the world) a slightly better place.

So given that context and given the fact that there are many ways in which the world could be made a better place, I would like to ask you to donate any amount of money you think my little projects are worth to a good cause. Just pick one, click and donate!

And there are many, many more great causes both locally and internationally that can use our help!

Care to share; testing Simple Share Buttons Adder

A couple of days ago a WP DoNotTrack user asked which WordPress sharing plugin I would recommend instead of privacy-killer “Share Buttons” by Lockerz / AddToAny. I’m not really into those sharing thingies (except for my little own performance-centric experiment maybe), but I nevertheless had a quick look in the Plugin repository and this was my feedback:

Just did a quick test with “Simple Share Buttons Adder“, no tracking there that I can see, cfr. this webpagetest test result (I did disable the custom font in styling->share text to avoid having to fetch a google font).

No tracking and performance isn’t shabby either, but some speed-improvements could be made:

  • By default the plugin includes a Google Font, which slows the page down. Changing this to “inherit from my website” in the “Styling”-settings, improves the performance.
  • Each share service’s image is fetched separately, from a performance point of view it would make sense to use one image sprite instead.
  • You can add a share counter: but without a caching plugin the page load is slowed down significantly, but with a caching plugin the counters aren’t updated any more. ideally the share counter would be empty on page load (i.e. just placeholders in HTML) and after the page has loaded an ajax call would get and set the correct numbers. The “backend” the ajax-call connects with could feature some light caching (5 minutes maybe)?

But all in all a nice sharing plugin, so if you want to have those share buttons, do give Simple Share Buttons Adder a go.

Looking in the mirror: 2012 numbers, 2013 goals

man in the mirrorAs I did a year ago for 2011, here I am looking in the mirror at my 2012 numbers and 2013 goals:

  1. This blog:
    • 130 blogposts (78 “real” posts and 52 aggregated lifestream-events)
    • 109285 pageviews, the most popular individual article being 5 tips to tackle the problem with iframes (8622 views). Off all new 2012 blogposts, Fix Samsung ICS Exchange connection errors was read most with 5727 views.
    • 294 comments (including trackbacks and my own replies)
    • Main goal for 2013: carry on, I guess? Maybe some more personal posts in Dutch. I’ve always loved to write in my native language, but it can be pretty time-consuming as I tend to rewrite a text multiple times before I’m OK with wording and flow (which I’m not as sensitive to in my non-native English).
  2. WP YouTube Lyte, my WordPress plugin to do “lazy load YouTube embedding”, is doing really well:
    • 9 minor and 2 major releases including the big 1.0.0 milestone
    • 66286 downloads (passing the 100.000 downloads mark in July)
    • Main goal for 2013 and long overdue; responsiveness but also even better performance (less reliance on JavaScript to do heavy lifting, using less http-requests).
    • Moreover, I was honored to see Yoast’s Video SEO plugin has support for WP YouTube Lyte and equally proud to be able to decline a commercial proposal to have my plugin add a link next to each and every LYTE player.
  3. WP DoNotTrack 2012 proved a fruitful year for my 3rd party tracking filtering plugin:

2012 was also the year that I got to know Drupal & Acquia a lot better, the year my lovely daughter learned how to read, the year I grew scared of Europe’s economical & Belgium’s political future, the year I saw Radiohead live and the year I finally learned how to fly.

Jetpack Notifications puts Quantcast tracking in your WordPress Admin

WP DoNotTrack user Marco Donati asked why the plugin did not stop Quantcast from being included in the WordPress admin pages. After some research (with the kind assistance of Marco), I discovered not one but two problems;

WP DoNotTrack relies on “output buffering” in WordPress to filter/ modify the HTML when in “Forced (default)” or “SuperClean” mode. Apparently WordPress does not use output buffering in the admin-pages, so WP DoNotTrack did not get triggered. My bad! I’ve updated the code to fallback to “Normal” mode when in admin and will push out a new version with this fix soon.

But then it got slightly ugly; even with this fix in place, the Quantcast-tracker kept on appearing! It was being called from within an iFrame, outside the reach of WP DoNotTrack. The culprit turned out to be the brand new “Jetpack Notifications” feature which -as most of Jetpack- is activated by default. As from Jetpack 1.9, you’ll see a small icon next to the greeting text on the right side of the admin-bar. When you click that icon a drop-down appears which contains the iFrame and the tracking code. To disable, in “Notifications” click on “Learn more” to reveal the “Disable”-button. Click that one and the icon, iFrame and tracker code are gone. Good riddance!

My advice to Jetpack users; explicitly disable any feature you do not use. Jetpack might offer some nice functionality, but of that is available in other plugins as well and being tied in that heavily into wordpress.com does come at a price. Moreover it seems there are some security concerns; as an user with author permissions I had access to the Jetpack overview page and I was able to activate the “Jetpack Comments” feature on Marco’s blog, but I couldn’t disable it. Call me a paranoid security-zealot, but non-administrator users should not really be able to do that, should they?

Content Security Policy; Great! or Wait?

A couple of days ago I had another look at Content Security Policy, a technology that allows a site to tell a browser resources are allowed to be loaded to protect against XSS and some other types of web application vulnerabilities. CSP was originally devised by the Firefoxians, but is in the process of being standardized by the W3C with support in Firefox, Chrome, Safari and even the upcoming Internet Explorer 10.

Great!
The functionality offered by CSP (blocking requests that are not allowed) is pretty close to what WP DoNotTrack tries to do, so I decided I’d try to integrate CSP in my plugin, based on the following assumptions:

  • CSP-mode will only work for WP DoNotTrack if it is configured to use a whitelist
  • As most WordPress+plugins installations are bound to have pages with at least inline JavaScript and/or style, I have to add “unsafe-inline” to allow those to continue to work (which indeed limits the level of protection against XSS-attacks)
  • Given that a lot (most?) WordPress installations implement WP Super Cache of W3 Total Cache, it will -at least in a first stage- only kick in if WP  DoNotTrack is configured to filter unconditionally
  • Ideally the JavaScript-based component of WP DoNotTrack would “see” that CSP was activated and would not perform those nifty JavaScript AOP trickery

The “proof of concept”-quality code I ended up adding to wp-donottrack.php was pretty simple:

function wp_donottrack_csp() {
 global $listmode;
 if ($listmode==="1") {
  $whitelist=wp_donottrack_getWhiteList(true);
  $csp="default-src 'self' 'unsafe-inline'";

  if (is_array($whitelist)) {
   foreach ($whitelist as $white) {
    $csp.=" *.".$white;
   }
  }

  header("X-Content-Security-Policy: " . $csp); //FF & MSIE10
  header("Content-Security-Policy: ". $csp); //new standard
  header("X-WebKit-CSP: " . $csp); //chrome & safari
 }
}

add_action('init', 'wp_donottrack_csp', 10, 0);

Wait?
With this code on my testblog I started playing around in a couple of browsers. Based on that experience I found the following limitations:

So in this particular context (and specifically the absolute need for “unsafe-inline”), I’ve decided to hold off implementing CSP (I might implement iFrame sandboxing as support for that is coming with IE10 and will probably also land in Firefox 17). But if you have full control over a particular website or -application (meaning you can remove all inline JavaScript and CSS and all instances of evals in insourced JavaScript) and you want to harden your installation to stop cross-site scripting, you really should start thinking about implementing CSP (as Twitter seems to have done already)!

WP DoNotTrack: user opt-out for your Cookie Law pleasure

It was long overdue, but I finally came around to releasing version 0.8 of WP DoNotTrack. The main feature to warrant the bump in the version-number, is the addition of conditional filtering based on user opt-out.

There is no opt-out UI in the plugin, but it hooks in to “Civic Cookie Control“, a JavaScript-based widget with a nice and customizable UI, which allows your customers to consent to cookies or to opt-out of them. When on WordPress, you can easily enable and configure Civic Cookie Control by installing the Cookie Control WordPress plugin.

If you’d prefer to do without Cookie Control, you can add your solution for users to opt in or out and set a cookie “dont_track_me” with value “1”, which will trigger conditional filtering as well. A very, very basic implementation could be to add something along these lines in the head-section of your site (in header.php of your template):

var r=confirm("Click \"OK\" for the full experience or \"Cancel\" to disallow 3rd party sites to store cookies on your computer.");
if (r==true) {
document.cookie="dont_track_me=0;";
} else {
document.cookie="dont_track_me=1;";
}

The other features of 0.8 from the Changelog:

  • new: “forced” mode now default
  • bugfix: re-introduced the bugfix for whitelist mode that was rollbacked in 0.7.2 (and a bug in that bugfix was the reason for 0.8.1, actually)
  • bugfix: conflict with prototype which caused wysiwyg editing of Wysija newsletter templates to break

Join the Internet Defense League

Member of The Internet Defense LeagueYesterday I added a notification bar to this blog which invites visitors to join the Internet Defense League.

The notification bar is one of the several ways to participate with your own site or blog. I really liked the modal version better but that one seemed a tad too disruptive (I’m not 100% sure visitors would immediately understand this being an overlay with the actual blogpost underneath) and based on some tests on webpagetest.org (after adding internetdefenseleague.org and internetdefenseleague.s3.amazonaws.com to my WP DoNotTrack whitelist) it turned out to be significantly slower as well. The notification-bar variant has a more limited impact on page load time; only one extra 4.9KB request before document complete and a total of 5 requests at 14.1KB, which is … acceptable for this performance-nut.

So if you, like me, believe that we as internet-users should unite to take action against any law that goes against our interest (think SOPA, PIPA, ACTA, HADOPI, …), then joining the Internet Defense League might be a good idea.