Right now I feel like writing a program to crawl cooking
websites and scrape the euconsent-v2 cookies that get
stored when you click “Reject all” + “Object all” in the
OneTrust cookie banners.
It seems every site has a slightly different permutation of cookie that gets stored to record the fact that you have denied storage of cookies for any reason. It’s unclear to me currently why this is, but it might not be important.
What I’m imagining is that I can create an extension that will inject this cookie prior to visiting a site, preventing the cookie banner from showing up in the process.
This has a slight advantage over detecting the cookie banner and simply removing it: this way I also object to all tracking, in theory disabling the tracking that happens if no options are clicked.
This only works for euconsent-v2-supporting cookie
banners, which I think is implemented by OneTrust and backed
by a tech created by the IAB known as
TCF (https://iabeurope.eu/wp-content/uploads/2019/08/TCF-v2.0-FAQs-1.pdf, https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/Consent%20string%20and%20vendor%20list%20formats%20v1.1%20Final.md)
They found a way to get vendors to have to register in order to use this, so it seems similar in nature to how SSL certificates work, where IAB is an authority in this world of cookie consent (specifically set up for use in advertising). Essentially different vendors will register with the IAB as an entity that will receive data about a visiting user in order to correlate their data with any existing data already held. Each vendor registers any number of purposes for which they will use the data, e.g. “link different devices” or “create a personalised ad profile”. When the website admin implements their cookie banner, the total purposes are determined by the selection of vendors they have specified for their site. The purposes can then be opted-out by the user.
This is why each website could have a different way of encoding an “opt-out”, because the token includes data about which list of vendors was used, the ID and version of the cookie banner itself.
All of this is the entire reason it’s so difficult for a user to express their cookie consent.
There’s also a major legal issue with trying to consent to cookies “once and for all”, because the legal basis of cookie consent is designed to be specific to every vendor, cookie banner, publisher, language etc.
It’s all designed to work for the industry, and it does! And although users are better off from the point of view of legal transparency with respect to cookies and how they are used, the majority are also encumbered by awful awful experience of using any website for the first time on any device.
Luckily cookie consent cookies are not user-specific. That is, they do not encode the identity of the person who has consented. This is important because it means the same cookie could be used on some completely other device and would essentially prevent the cookie banner from ever appearing. Of course the user should still be able to control this functionality, and this remains possible although limited to copying the choices of a previous user who has already clicked certain options on the cookie banner.
And alternatively, the interaction with the banner could be automated such that the blocking cookie is collected by a crawler and distributed to users who wish to consent in the same way.
Anyway, I feel motivated to try this - it would be pretty simple to create an extension that enables recording of cookie consent, making the cookie public to anyone else using the same extension. To begin with the extension could have a single option of “always opt-out”.
It might even be possible to do this in a way that is agnostic to the data stored in the cookie that prevents the banner appearing. The extension should simply record any changes to the user’s cookies whilst they interact with the cookie consent banner.