Before you start reading about the CookieShredder you can learn more here about Consent per Service, Category or Cookies. And why Consent on Cookie Level is technically impossible
The CookieShredder will be introduced in the following weeks for Complianz users. It will be a user-focused clean sweep of cookies without consent during website visits. A real-time reporting mode will check individual browser cookies after each interaction and page-load with cookiedatabase.org to check if the user’s consent level is in accordance with the set cookies. If not, cookies are shredded immediately.
How our Cookie Blocker works
Our current Cookie Blocker effectively cleans and blocks third-party cookies and scripts from plugins and services that need consent before initialization. There are, however, some limitations specifically to PHP cookies and WordPress plugins.
The Cookie Blocker now available in Complianz manipulates script files to block and initialize on consent level. These scripts set cookies and thus a “Cookie Blocker.” This is how a script file might look before and after consent:
Limitations concerning PHP & Javascript
To control consent for WordPress plugins, we need to integrate with PHP and manipulate the functionalities before they get triggered. These integrations are available in Complianz but can change for any plugin update, and maintenance is very time-consuming. This is why we proposed the Consent API for WordPress core and communicated with many popular plugins to integrate with Complianz fully. This, however, is not a maintainable standard. Without broader adoption, we have to rely on individual integrations for each plugin and service. 100% coverage is hard to achieve with +50000 plugins and services. A more general approach is needed.
Why not block the plugin?
It is possible to block and reinitialize plugins fully from the back-end, but we can’t predict how a website might behave when a plugin is fully blocked or when it’s initialized on consent. It’s possible in Complianz to block plugins in the front-end for some control, but it is still a brute force option to block scripts.
Not all Javascript is the same.
Blocking or integrating with javascript can have some challenges. The main challenges we face are minified javascript or combined, concatenated javascript. Although most manipulated javascript can be blocked and integrated, some Javascript is impossible to block without causing issues.
Take, for example, a YouTube widget from Elementor. This widget is loaded in a combined javascript called ‘front-end.js.’ The front-end.js also initializes menus, other widgets and might load different CSS files depending on the design choices. Blocking this script means crashing the website or breaking functionalities. To overcome this issue, we integrate fully with Elementor. You can even build a Cookie Banner with Elementor Pro and use our Consent Management in the background.
Cookie Blocker + Cookiedatabase.org = CookieShredder
We started looking at a way to work toward a general approach without relying on the Consent API, costly integrations, or developers from 50.000+ plugins conforming with different Consent Management plugins. This became CookieShredder which is a combination between our current blocker and communicating with your detected cookie list from cookiedatabase.org. This is done locally.
This is how CookieShredder works.
On page load, the Cookie Blocker will do the heavy lifting. Due to the limitations shown above, some cookies might be set with PHP or highly optimized or combined javascript. When these cookies are set, they will be checked against your cookie list, which is updated regularly with Cookiedatabase.org. If these cookies do not meet the consent level of the user, they will be removed or shredded almost instantly from the user’s browser.
This means that current ‘static’ website visits from a privacy standpoint will now become a dynamic, isolated website visit where every page load and interaction is weighed against the user’s privacy settings.
Removing cookies from third-party domains is not possible, e.g., facebook.com. This would pose a security risk if anyone could manipulate data on other domains. All scripts are again set to text/plain on a revoke and can no longer connect to the third-party domain. The website user can clear cache in the browser to remove these cookies thoroughly, as explained in the cookie policy.
Soon, we will see more and more third-party services migrate to first-party domains to circumvent the issue with third-party domains; more and more browsers, devices and cookie blockers from Consent Management Tools are effectively stopping tracking and advertising in its tracks.
Recently for example; Facebook cookies can now be set on facebook.yourdomain.com with a DNS setting and domain validation. These cookies can be shredded, thus removing the final challenge for deleting cookies of third-party services, independent of which domains they use to track users.
An example with a WordPress Login Cookie (Don’t try this at Home)
The CookieShredder is connected with your cookiedatabase.org results on the Cookie Policy. It’s also possible to assign other categories to services, or cookies and therefore change how the CookieShredder works.
If you have a member or account area for your customers you will also need to show the WordPress cookies on your cookie policy. Although functional, they are set on your customer’s computer, so you will need to describe and mention them on your cookie policy. Complianz will take care of this and it looks like this:
Under Cookie Descriptions in the wizard you can, for whatever reason decide the “wordpress_logged_in_*” cookie is a Marketing cookie by desynching from cookiedatabase.org and using the dropdown to select the category.
At this point, you have declared the login cookie a Marketing cookie! Don’t do this. On your cookie policy you will now find that the category has changed.
You can now find a session cookie named cmplz_cookie_data with the cookies stored and ready for shredding if consent is revoked. One of these cookies is now your logged-in cookie from WordPress set to “Marketing”.
{statistics: {google-analytics: ["_ga", "_ga"]}, marketing: {,…}}
marketing: {,…}
facebook: ["_fbc", "fbm", "xs", "fr", "act", "_fbp", "datr", "c_user", "sb", "_fbm_", "_fbc", "fbm", "xs", "fr",…]
wordpress:["wordpress_logged_in_*,]
statistics: {google-analytics: ["_ga", "_ga"]}
google-analytics: ["_ga", "_ga"]If you revoke consent from the category Marketing, or the service “WordPress” you will be immediately logged out!
Why CookieShredder is unique
Cookie Banners for WordPress are plenty, but not all Cookie Banner plugins or services are Consent Management Tools. Because you will need (much) more than a Cookie Banner, we always recommend using a WordPress plugin to seek compliance instead of a cloud service. A Cloud service will not be able to integrate neatly into your WordPress platform and can only do so much “from a distance.”
A WordPress plugin will be able to handle plugin behavior. Still, only Complianz and its CookieShredder has the added benefit of a growing and maintained Cookie Database to shred any cookies set by services and plugins that do not conform with the website visitor’s consent level.
You want to know what happens with consent in a cookieless age? Read more
