I have a home network that contains a mixture of devices, some of which that receive a...
Version 1.1.13 of Cookillian has been released today, which addresses a number of reported bugs and adds a new option for cookie auto detection.
A major bug was related to erroneous use of the WordPress wp_print_script action in third party plugins or themes, which in turn cause the Pf4wp framework to behave incorrectly and output multiple copies of the same script. It overwrote previously set variables, causing strange errors as reported in the WordPress support forum. Updating the underlying framework should address this bug.
Another bug caused people to imply their consent without leaving the page they visited, and was limited to users of Mozilla Firefox. Although the problem could be replicated, the actual cause was very difficult to find. Nowhere in the Firebug debugger could I see that a cookie was set, yet there was a cookie stored (regardless of clearing all cookies).
Looking at the server logs, I noticed that for each page visited, Firefox actually made two calls to the server – one to the requested page, and one to a seemingly random page. This was the Mozilla Firefox Prefetch “feature”, that had been available for a long time — so long, that I completely forgot about it.
Cookillian thought of the prefetched page as a user interaction (moving on to another part of the website) and therefore set a cookie, indicating the user implied consent. As that is obviously incorrect, the prefetching is now filtered.
Two additional, minor bugs have been fixed. One is fixing the statistics screen, where the last (current) month could not be collapsed. The other is when PHP has not been compiled with Multibyte String support, which prevented the list of countries from being loaded and sorted. Most PHP distributions do have this support, however, Cookillian now accounts for when it does not and use an alternative method.
Cookillian also introduces the option to limit the amount of cookies it will detect (currently set to 30 by default, which is adjustable). This is essentially a stop-gap solution to a problem that I’ve noticed and has also been reported by Mr. Grill of Kred, who wrote a nice article about the EU cookie law and Cookillian.
The problem seems to be that a browser is sending back cookies that do not actually belong to the domain it is visiting – analogous to “supercookies”. I’ve seen cookies for BoCoDeals, CNet Australia, SocialTimes, Book Expo America and many others. Aside from the security implications of a browser sending cookies from other domains, it caused Cookillian to detect hundreds of new cookies.
I am still trying to find a better way of dealing with this, including if there’s a pattern with a certain browser. For instance, you can enable Debug Mode in Cookillian, and on the Cookies page, any new cookie added will now also include an identifier for the browser. So far, only one browser has emerged as a pattern, which appears to be an old one (we’re talking about 2008), and I suspect is in fact a bot.
If the “supercookie” issue concerns you – as in your privacy – I can recommend the Panopticlick tool by the EFF. It is quite revealing!