There are plenty of commercial solutions available, as well as some apps, that stream directly over the Internet. But, as I had mentioned, the tablet was dirt cheap and so it should be indicative of the amount of money I was willing to spend.

I already owned a USB TV stick, which I used on my laptop, and wanted to use this as the receiver. It’s a PCTV Nanostick T2, based on the Sony CXD2820R demodulator, which is (or was?) the only device to support the UK’s DVB-T2 format for HD reception.

The USB TV stick is directly supported by the 3.x kernel (as an em28xx device), and naturally, the RPI did too. So it was a matter of finding what software would stream from the TV source over the network, and what software that would be able to accept and display this stream – particularly on an Android device.

Heads up! While the Raspberry Pi will detect the USB TV stick that is directly connected to it, it cannot provide enough power to it. This means it will not be able to tune into any channels. So the USB TV stick must be attached to a self-powered USB hub (which in turn is connected to the RPI, of course).

This is where XBMC comes into play. Since version 12 of XBMC (“Frodo”), it is now possible to watch live TV via a PVR back-end. What’s great too, is that XBMC runs on a plethora of operating systems and devices, including Android. The app is not yet available in the Google Play store, so you need to manually download and install it. Just note, that before you install it on your Android, you may need to enable the Unknown sources option found under the Android’s system settings (under the Security tab).

Tvheadend

So with the “front-end” sorted, all I needed was the back-end for the Raspberry Pi. I settled on using Tvheadend, because it is very lightweight and runs on the ARM device just fine. However, I didn’t install it from binary as, well, there wasn’t one available – at least not in individual form. Compiling is a breeze though, and the developers already have everything available for a .DEB package. I skipped building a .DEB package, simply for sake of simplicity, but used their init script, config files, etc.

To compile Tvheadend, you start by getting the necessary packages. Some I will list here are optional, but I prefer to cram as much “optional” stuff into a build, so I won’t need to recompile everything it when I do need it at one point.

sudo apt-get install git build-essential \
  libavcodec-dev libavformat-dev libssl-dev \
  libavutil-dev libavahi-client-dev libcurl3 \
  w-scan

After the packages have been installed, proceed to clone the source code of Tvheadend using git. This will create a directory called tvheadend based on the location where you are, generally /home/pi/ if you’ve logged in via SSH.

git clone git://github.com/tvheadend/tvheadend.git

Now proceed to the directory and run the initial configuration. Running the configuration will check if you have the required packages installed, and fetch DVB scan data from a remote server.

cd tvheadend
./configure

If everything went well, you should not have received any fatal errors. You may see a few “fail” messages, but these are benign.

As I live in the London area, the Freeview transmitter is Crystal Palace. However, the source from which the configuration obtains the DVB scan data appears to be slightly outdated and may cause some hiccups. In my case, I’ve simply provided my own scan data using the previously installed w_scan application. You may skip this, if it doesn’t apply to you.

w_scan -cGB -x > ./data/dvb-scan/dvb-t/uk-CrystalPalace

This will directly replace the file in tvheadend/data/dvb-scan/dvb-t/uk-CrystalPalace, so if you’re concerned, you may wish to make a copy first.

Then proceed to compile Tvheadend, which for obvious reasons will take a little longer on a Raspberry Pi than a conventional computer:

make clean && make

Installation

Once it has been completed, you’re ready to install it. As mentioned earlier, Tvheadend already contains everything needed to build a .DEB package from which you could install it. However, I chose not to, and simply used some of the existing files to install it manually:

sudo su
make install
ln -s /usr/local/bin/tvheadend /usr/bin/tvheadend
cp ./debian/tvheadend.init /etc/init.d/tvheadend
chmod +x /etc/init.d/tvheadend
update-rc.d tvheadend defaults

cp ./debian/tvheadend.default /etc/default/tvheadend
adduser --quiet --system --group --shell /bin/bash hts
mkdir -p "/home/hts/.hts/tvheadend"
cat > /home/hts/.hts/tvheadend/superuser <<EOF
{
"username": "superadmin",
"password": "MySuperSecretPassword"
}
EOF
chmod 600 /home/hts/.hts/tvheadend/superuser
chown -R hts:hts "/home/hts/.hts"
exit

Heads up! The one thing that you should pay attention to, is the portion here it creates the /home/hts/.hts/tvheadend/superuser file. The username and password provided here are only for sample purposes, and you should change this to something you’ve thought up yourself.

If you have a firewall setup on your RPI (and you should!), remember to open up the TCP ports 9981 and 9982 for the appropriate network. UDP is not required.

Configuration

Now that you have installed it, fire up Tvheadend:

sudo service tvheadend start

And configure it further at http://(ip address or domain name of your PI):9981. You will be prompted for a username and password, which was provided earlier in the superuser file.

Some guidance for configuration can be found in XBMC’s Wiki - it does not mention that after you’ve selected DVB input, you should tick the box Enabled found in the Adapter Configuration box, and then save the settings before it will perform an initial scan. You can follow its progress by expanding the window at the bottom (click the chevrons pointing upwards in the bottom-right corner).

Additionally, you need to setup the Access Control list, also found in the Configuration area, to allow/restrict access from devices. This is explained in more detail in the Tvheadend Wiki.

After this, you can configure XBMC, by going into its system settings, and enabling the Tvheadend HTSP Client add-on. Once that has been enabled, click Configure for it, and provide the necessary details, which at minimum is the IP or domain name for the Raspberry Pi. Finally, still within XBMC’s system settings, enable Live TV. You are now able to watch live TV! Unless …

Bugs!

There’s a bug with the Raspberry Pi firmware related to its USB. Or, there’s a problem with the USB itself. Either way, it affects many video streaming devices, such as webcams and TV USB sticks (like the em28xx devices). The result is that you may find yourself rather annoyed by the fact that live TV is barely “live”, and mostly consists of black screens or what appears to be a very bad signal. Looking at the logs for Tvheadend, you may notice many lines similar to this:

Apr 1 21:45:02 raspberrypi tvheadend[13259]: TS: Sony CXD2820R/London: 490,000 kHz/BBC ONE: MPEG2AUDIO @ #102: Continuity counter error, 533 duplicate log lines suppressed
Apr 1 21:45:03 raspberrypi tvheadend[13259]: TS: Sony CXD2820R/London: 490,000 kHz/BBC ONE: MPEG2VIDEO @ #101: Continuity counter error, 5777 duplicate log lines suppressed
Apr 1 21:45:03 raspberrypi tvheadend[13259]: TS: Sony CXD2820R/London: 490,000 kHz/BBC ONE: MPEG2AUDIO @ #106: Continuity counter error, 121 duplicate log lines suppressed
Apr 1 21:45:03 raspberrypi tvheadend[13259]: TS: Sony CXD2820R/London: 490,000 kHz/BBC ONE: MPEG2AUDIO @ #102: Continuity counter error, 534 duplicate log lines suppressed

Thankfully, this problem has been addressed by the Raspbian teams, and requires that you update your kernel (firmware). You can double-check the current version, which will likely produce something similar to this:

# uname -a
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux

The important bit is the #371 part here, which is the one that has the above described issue. Updating the kernel/firmware is slightly different than what you’d expect from most Debian distributions (which is simply apt-get a linux image), but Liam McLoughlin has created a simple script to help you with that. Here’s a quick how-to:

sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
sudo rpi-update

Just let it run its course, which involves updating itself and then obtaining the latest firmware. If this is the first time you’ve run it, it will download about 42 Megabytes worth of files. After it has successfully completed downloading and installing, you need to reboot the Raspberry Pi. Once back up, the kernel/firmware version should have been updated to at least the following:

# uname -a
Linux raspberrypi 3.6.11+ #401 PREEMPT Fri Mar 29 22:59:09 GMT 2013 armv6l GNU/Linux

Again, the important part here is the #401, changed from the previous #371.

Using Cookillian on my own website, I had initially decided on using the strict method. It barred cookies outright and required the visitor to make an explicit decision about cookies. With this method, the average between opt in and out was nearly 50:50 down the middle. For June, I decided to change from explicit to implied consent, and as seen in the statistics below this changed the numbers significantly:

These numbers were taken from Cookillian’s statistics for the specified month, and takes into account those that ignored the alert. As you can see, at most 20% of the visitors (for the Czech Republic) had decided not to receive cookies. A combined average of 15.92% visitors decided not to receive cookies, which is certainly a significant difference between the near 50:50 split when using explicit consent.

I’m wondering whether this is simply a matter of convenience outweighing matters of e-privacy (as the EC has nicely named it). And while I do think it is important to let a visitor decide about cookies, was the law in itself really worth the effort – and aggravation? Time will tell.

Based on a suggestion in the WordPress Support forum, the new option provides a method for remembering the last shown background image. This allows Background Manager to continue with that image on another page, provided that page uses the same Image Set (no override).

A bug related to click-able background images has been fixed. Previously, the option to open a link in a new window did not work as intended, opening the link in the same browser window instead.

Another minor bug was related to the Pinterest “Pin it” button. The way Background Manager handled it, with each new image shown as the background, an entry was added to the browser’s history affecting the back-button functionality. This was fixed in time for the release of 1.1.6.

A lingering issue was related to Full Screen background images, which hopefully has been resolved. Depending on the theme, the background images could potentially be moved “out of sight”, and thus give the impression Background Manager did not work. This was due to a positioning error.

Also, under certain circumstances, the natural image width and height could not be obtained. This was required to calculate the image ratio and positioning, which at times resulted in a width or height of zero, thus invisible. A different method for obtaining the natural width and heigh has been implemented, based on the browser’s capabilities.

Finally, a bug corrected as part of the development process, was a related to how Background Manager filtered the Media Library functions. It caused some issues with adding new images to the Image Set.

On to the next version!

Edit 14:25 BST Version 1.1.6.1 has been released as a hot-fix to some reported issues of screen elements “missing”.

Furthermore, the JavaScript header/footer was only loaded when cookies were permitted. This behaviour has been changed in version 1.1.18, where it will also load if cookies are not deleted — this keeps it in sync with the “delete cookies before/after” option.

Also in 1.1.18, the default alert now uses the AJAX API to opt a user in, or out, depending on the availability of JavaScript. If JavaScript is not available, it will use the convential method instead.

Enjoy!

As found at http://www.worldipv6launch.org/infographic/

• Person A is given nonce “A”
• Person B is given nonce “B”
• Person B attempts to submit data to the server on behalf of person A
• The server reads the submitted data from person B as “Person A with nonce  ’B’ is submitting data”. Knowing that Person A does not have nonce ‘B’, it ignores/denies the submitted data.

WordPress differs by giving it a lifespan and allowing the nonce to be used more than once within that lifespan by the same person. And by the ‘same person’ it is meant a logged in WordPress user, or an anonymous user (visitor not logged in).

The benefit is that the server does not need to keep track what nonce it has given to any particular user. It just needs to know the user returning the nonce and the current time; based on that information, it creates another nonce and checks if it matches the one returned.

Using time as part of a nonce

As time varies, WordPress needs to allow for a nonce generated at 10:01 AM to be valid at 10:02 AM. It does this by using a time “tick” instead of the actual time, which is generated in two steps:

1. First divide the lifespan of a nonce, in seconds, by two
2. Divide the Unix timestamp by the above value, and round it up using ceil()

By default, the lifespan is 86400 seconds, or 24 hours (and can be adjusted with the nonce_life filter). Half this, 12 hours, is 43200.

So at 10:01 AM on 18/06/2012, the Unix timestamp is 1340031660. Dividing that by 43200, rounded we get 31019. A minute later (10:02 AM), the timestamp is 1340031720. Dividing and rounding, we also end up with 31019. In fact, for the first 12 hours of the day this value will be the resulting “tick”.

The reason WordPress divides the timespan in two, is that it can determine if a nonce was created in the first or second half of its full lifespan, simply by incrementing a “tick” by one.

Nonce time caveat

Based on a 24-hour lifespan, a “tick” as calculated above is the same for each 12-hour span of a day. At 07:45 AM the “tick” is the same as 9:30 AM and 11:59 AM. But it will be one less than a “tick” created at 12:01 PM (a new 12-hour span within the day) or 15:30 PM.

Because of this, a WordPress nonce is not valid for exactly 24-hours from the moment that it was created, but up to 24 hours, depending how far into a 12-hour period a nonce was created.

Nonces and WordPress Cache

Nonces can also be used on the “public” side of WordPress, and can help reduce abuse of data submissions. My WordPress plugins use this, as do some others like Contact Form 7.

As a nonce is often added as a (hidden) form element or using JavaScript, this means that it will also end up being cached by a WordPress plugin such as WP Super Cache or W3 Total Cache. This can cause some issues with nonce verification.

The main issue is how long a page is cached and how most caching plugins determine the age of a cached page. As mentioned earlier, a nonce “tick” is not valid for exactly 24 hours. On the other hand, the age of a cached page is determined from when it was first cached. So if a page is cached for 24 hours (or more), it allows the possibility for a nonce to expire and thus become invalid.

For example: a page is cached at 10:01 AM on 18/06/2012. The “tick” of used for the nonce at this time was 31019. 24 hours from that time, at 10:01 AM on 19/06/2012, the server calculates a “tick” to be 31021. But as the cached nonce was based on a “tick” of 31019, any attempt to use it for data submission would fail.

To avoid this, a page should be cached for at most 12 hours, provided the life-span for a nonce has not been changed from its default 24 hours. The author of WP Super Cache also provides an alternative solution, though that may not be a suitable solution in all cases (ie., in AJAX that uses nonce on all pages).

Cache garbage collection

In WP Super Cache’s case, by default a cached page becomes stale after an hour, which is well less than the 12 hours. But for the stale page to be refreshed using its Garbage Collection feature (see the Advanced tab), the collection has to be done in time as well. For instance, if the cached page has become stale after an hour, but garbage collection is done every 24 hours, the stale page will still be used for up to 23 hours.

This is further complicated because the WordPress Cron (the scheduler for performing tasks) usually checks its schedule whenever a visitor accesses the website. On low-traffic websites, this could give large variations between the scheduled time versus actual time a task is performed (such as the garbage collection). In these instances, it would make better sense to use a UNIX Cron Job to call wp-cron.php, or to reduce the garbage collection time as much as possible.

(Update: A rather annoying bug was introduced in version 1.1, which has been remedied in 1.1.1. If something can go wrong, it most certainly will).

It includes a large number of new features, which I will outline below. Please note that there are a few changes that could potentially affect the layout of the background, so keep these in mind before upgrading.

Theme Customizer

WordPress 3.4 introduces a theme customizer, allowing you make adjustments to your theme and see them in a preview. It’s a welcome addition to WordPress, making it a lot easier to customise a website and Background Manager takes full advantage new feature.

All the visual options found in the Background Manager’s Settings screen can be accesses directly from the theme customizer, allowing you to change image sets, background colors and overlays, select between full-screen and normal display modes and more.

All these changes are non-permanent until you save the settings, allowing you to test various options, like the new image transitions, to see which ones work best for your website.

New image transitions

Version 1.1.1 increases the number of available transitions to 19 with the introduction of Fade-in and Zoom transition and 8 CSS3 transitions based on the hard work of Joe Lambert’s Flux Slider.

Heads up! The new transitions required a few changes in how the background images are displayed. Prior to version 1.1, it used an <img> element to display the background. Now it will us a <div> element with a background image, unless the browser does not support the “background-size” element (Microsoft Internet Explorer 8 and below) — such browser will still use the <img> element, and fall back to the “Crossfade” transition.

Better full screen images

Previously Background Manager relied upon CSS to adjust the background image size according to the browser window. This worked well for images that were smaller than the browser window, but larger images were not resized and this lead to some confusion, particularly in what size the background image to use.

In version 1.1 this is now managed with JavaScript, which allows you to use any size image. Large, and small, images will be resized to fit the entire background, whilst maintaining the ratio (preventing stretching or squishing). If after resizing the image is larger than the width or height of the browser (due to maintaining its ratio), it can optionally be centred.

Heads up! Because large images are now resized too, make sure that this is okay for your website before upgrading.

Sequential image selection

One of the most requested features was the ability to display images in the order they appear in an Image Set, as well as the ability to re-order those images.

This feature has been added to version 1.1, and allows you to display the images in random, ascending or descending order. When editing an Image Set, highlighting an image will provide to option to move it left or right. You can also double-click to select images, and move them in one go.

Additional Image Set improvements

Another improvement when editing Image Sets, is the ability to remove an image from an Image Set. This differs from deleting an image, as it will remain in the Media Library for later re-use.

The window showing the images within an Image Set can now also be resized (and it will remember the size for next time).

Background Impression and Click tracking

The ability to make backgrounds click-able since version 1.0.6 has proven rather popular, and another frequently requested feature is the ability to track the impressions and clicks of such click-able background images.

Version 1.1 introduces the option to do so with the help of Google Analytics and will trigger Events whenever a click-able image is shown or clicked on. These events can also be used as part of Goals.

And More!

In addition to the above, version 1.1 also introduces the following new features:

• Detects 3rd party category taxonomies, such as those created by WP e-Commerce, and override the background image based on those categories.
• The option to override the link for the [ + ] icon
• Override the background color per post, page, category or tag
• Select which WordPress Roles are permitted to override the background for a post or page
• Optionally disable the ease-in of the first image
• Longer transition times and faster background change frequencies (down to 1 second)

As well as numerous bug fixes, including the “blocking” during a background change as well as the “flicker” noticeable on certain browser.

Photo by cessemi

Here I will provide an example for a simple, unobtrusive alert at the bottom (or top) of a page, with an option to opt out of receiving cookies. This is a commonly used method for implied consent across major websites in the United Kingdom.

It also shows how to use Cookillian’s API to make an AJAX call, yet provide backward compatibility with browsers that do not use JavaScript.

Setup

This styling is divided in two parts, one that provides the HTML code, and another the CSS styling. We first need to access the Settings screen (Settings -> Cookies) and set both Alert Content and Alert Styling options to Custom. This will provide us with two new large fields where we can add the code necessary.

As this alert style is geared towards implied consent, you may also want to tick the box Implied Consent, which will hide the alert if the visitor accesses any other page (by opting the user in). And under the heading Advanced Options, you have the option to delete cookies if the visitor specifically opts out.

CSS Code

For the Custom Alert Style we use the following code:

.cookillian-alert {
  position: fixed;
  bottom:0;
  left:0;
  z-index:10000;
  width:100%;
  border-top:1px solid #000;
  color: #000;
  background-color: #eee;
}
.cookillian-alert-inside {
  padding: 5px;
  text-align: center;
}

This will ensure that the alert will “stick” to the bottom of the screen, above all other content. If you find that the alert is still covered, you need to increase the z-index value. And if you’d rather wish to have the alert appear at the top of the screen, replace “bottom: 0;” with “top: 0;” and “border-top” with “border-bottom”.

Heads up! Cookillian always wraps the HTML code inside a <div> element with the class cookillian-alert.

HTML Code

Under the heading Content, you can add the following HTML code in the large Custom Alert Code field:

<div class="cookillian-alert-inside">
Just to let you know, this website uses cookies and you can read more about them <a href="#">here</a>. If you'd rather not want this, <a href="?cookillian_resp=0" onclick="try{cookillian.optOut();jQuery('.cookillian-alert').fadeOut('slow');return false;}catch(e){}">Click here</a>.
</div>

Obviously you are free to change the text to meet your needs. Just be sure to change the link to the information about the cookies (currently a hash [#] sign).

The “Click Here” linke contains an onclick attribute that executes a little JavaScript if its available:

1. In the background, it first opts the user out of receiving cookies – so that the visited page does not need to be refreshed.
2. It hides the alert in a fading motion.

If JavaScript is not available, then it will use Cookillian’s ability to opt a visitor out by URL. This will ensure that anyone can opt out, regardless of their browser capability.

This is the preferred method, as it gives greater control over the cookies set by third party scripts. As mentioned, Google Analytics is one such script that should be moved, and is probably easiest to accomplish. But there are some that require a bit more work, like the Twitter Tweet button and Google AdSense, which I will explain next.

I will also provide a sample code that with the help of Cookillian will delete local cookies set by existing JavaScript, to help ease the transition.

Tweet Button

The original code provided by Twitter for the Tweet button is the following:

<a href="https://twitter.com/share" data-lang="en">Tweet</a>
<script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0];if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src="//platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");</script>

This bit of code is in fact two parts: a regular link with the word “Tweet” to share a URL on Twitter, and a script that replaces this link with a pretty button and a share counter.

Because the JavaScript only needs to be called once for all such links, we can simply remove the <script> portion from the code above, and place it in the Footer field of Cookillian’s JavaScript section. It should not be placed in the Header field though, as it would otherwise be run too soon by the browser.

When cookies are blocked, the script by Twitter is not permitted to run and the regular “Tweet” link will remain as-is. When cookies are permitted, the script is allowed to run, and the simple links are transformed into the more familiar buttons with counters.

This also works for other scripts that replace a simple link with buttons, such as Facebook’s “Like” button. However, some scripts must be run at certain locations. Google AdSense is one such example, and will require a bit more work still.

Google AdSense

The following is a sample of the code provided by Google AdSense. It is to be placed where the advertisement should be displayed:

<script type="text/javascript"><!--
google_ad_client = "ca-pub-xxxxxxxxxxxxxxxx";
/* 160x600, created 11/1/08 */
google_ad_slot = "000000000000";
google_ad_width = 160;
google_ad_height = 600;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

When this code is run by the browser, it will add the advertisement where this code is located. For this reason, it cannot be moved into the Footer or Header fields of Cookillian’s JavaScript section. Instead, one needs to use one of Cookillian’s API methods to accomplish this.

Selective text insertion

One API method available in Cookillian is cookillian.insertString(), and can be used to insert text, including JavaScript, at a specified location. It takes 4 parameters:

• where - the CSS selector where to insert the string,
• true_string - The string (text) to use when the 4th parameter (tf_value) is true,
• false_string - The string to use when the 4th parameter is false,
• tf_value - An optional boolean value (true or false) or name of a Cookillian variable, used to indicate which string to use. If this is omitted, it will use Cookillian’s blocked_cookies variable by default.

Using it is very simple, and it automatically handles any asynchronous AJAX calls made by Cookillian. Here’s an example:

Cookies are currently <span id="insert_here"></span>.
<script type="text/javascript">cookillian.insertString("#insert_here", "disabled", "enabled", "blocked_cookies");</script>

This will check the cookillian.blocked_cookies variable when it is ready, and add will “disabled” to the text if cookies are blocked (true), or “enabled” if they are not (false). As the text can also include JavaScript, we can use this function to add the Google AdSense code when cookies are permitted.

Heads up! Any text needs to be enclosed in a single or double quote. The JavaScript code may already contain single or double quotes, and therefore need to be “escaped”.  Freeformatter.com provides a quick and easy to use tool to perform the escaping.

The following is what the code will look like for Google AdSense:

<span id="google_ad_1"></span>
<script type="text/javascript">
cookillian.insertString(
"#google_ad_1", // Where
"",
"<script type=\"text\/javascript\"><!--
google_ad_client = \"ca-pub-xxxxxxxxxxxxxxxx\";
\/* 160x600, created 11\/1\/08 *\/
google_ad_slot = \"000000000000\";
google_ad_width = 160;
google_ad_height = 600;
\/\/-->
<\/script>
<script type=\"text\/javascript\"
src=\"http:\/\/pagead2.googlesyndication.com\/pagead\/show_ads.js\">
<\/script>"
);

This code will insert nothing if cookies are blocked. You could perhaps use that to display an alternative advertisement. If cookies are not blocked, it will run the provided Google AdSense code as usual. As you may have noticed, I left out the 4th parameter, as this is the cookillian.blocked_cookies variable by default.

Heads up! An ID attribute, as seen in the <span> tag, can only be used once on a page. For each ad, you should use a different ID (you could increment the last number, for example).

Periodic Clean-up

The following is an example using the Cookillian API, which periodically checks if new local cookies have been set and delete them (unless they’re required). It will also skip this periodic clean-up if cookies are permitted.

(function($){
    $(document).on('cookillian_ready', function() {
        function cookiesSqueakyClean() {
            // Check if cookies aren't allowed but present
            if (cookillian.blocked_cookies && document.cookie) {
                // If we haven't "seen" these cookies before, try delete them
                if (typeof document.last_seen_cookies === "undefined" ||
                    document.last_seen_cookies !== document.cookie) {
                    cookillian.deleteCookies();
                }

                // Anything left is likely to be "required",
                // and we save these for the next check
                document.last_seen_cookies = document.cookie;
            }
            setTimeout(cookiesSqueakyClean, 1000);
        }
        cookiesSqueakyClean();
    });
}(jQuery));

The periodic clean-up will handle cookies that are “local” only, that is, cookies that belong to the same domain as the visiting website. Cookies for other domains cannot be handled (and is not a limitation, but a security feature implemented by browsers).

Again, the preferred method is to use the selective insertion of Javascript using the API or in the provided fields, as this gives greater control over 3rd party cookies.