Now I just “discovered” that the Mozilla team have rendered that somewhat clumsy procedure -which required me to log in each time I restarted my computer or browser- redundant with their “Firefox Multi-Account Containers” add-on, allowing you to contain entire sessions to one (or more) tabs;
So now I have one browser window with a couple of tabs in the Google container, one tab in a Facebook container and all others in the “default” container where Google & Facebook can’t track me (fingerprinting aside, but there’s an option for that).
NoScript remains one of my favorite browser addons (or plugins or whatever they’re called these days). Look what it just proposed to block while browsing bol.com (one of the big online retailers in BE and NL);
So when does GDPR go in effect exactly and will I be able to opt-out of data-sharing from that moment onwards?
So you (vaguely) know about the GDPR I’m sure. German netizens seem ahead of the curve, as I’ve been mainly getting questions about Autoptimize and WP YouTube Lyte from that part of Europe. It even looks like the German implementation of the GDPR is pretty strict, with people removing externally hosted resources (like Google Fonts and Facebook widgets) from their sites.
It’s in that context that user ekatarinal on the WordPress support forum for WP YouTube Lyte asked if the thumnails for the Lyte video’s could not be loaded locally. That way user information (IP-address -and if the user is logged in to Google a lot more- would not be available to Google/ YouTube unless and until the visitor clicked the play-button. Additional advantage; no extra dns-lookup, http connection or ssl/ tls negotiation, no short caching-headers, … so very likely to improve performance as well!
And that’s why WP YouTube Lyte 1.7.0 is in the works and it will have that option. In fact it’s already up on Github in a first incarnation (call it beta), so if you want to test you can download the zip-file here.
EDIT: Lyte 1.7.0 was released on April 28th, no need to go down that Github road.
Wildbirds & Peacedrums "There Is No Light" (official video)
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)?
and adds sharing-buttons for Twitter, Google+ and Facebook to that div (Linkedin, Yammer and Tumblr are also supported). You can see lyteShare.js in action on this test-page. The webpagetest.org test result is great when compared to that of the big boys;
Now the question is; does the world really need yet another social sharing widget solution, even if it is easy, fast & not a vehicle for 3rd party behavioral web tracking? Does the world (and this blog) even need social sharing widgets at all?
Doing Web Performance can be so easy, really! I was asked to do a performance analysis of a new website and one of the things I didn’t like was the fact that the footer contained social media sharing buttons using the ShareThis widget. I’m not a fan of sharing widgets in general, as they tend to slow webpage loading and rendering down and as they almost invariably come with “3rd party tracking” for behavioral marketing purposes.
Conclusion: if performance is of any importance for your website (and it should be), you really have to avoid using 3rd party widgetery!
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?