The Open Cookie Database is an effort to describe and categorise all major cookies. All cookie descriptions are saved in a downloadable CSV file. All contributions to the CSV file are welcomed.
There is a misconception that the German "DSGVO" or GDPR in general only need to consider cookie data. All external services and their tracking options are meant within the meaning of the law.
This would require listing not only cookies but also cookie-like techniques: "HTML5 Local Storage" or classic tracking images (Sometimes called: "pixels").
Providers such as Cookiebot etc. already do this.
Would it make sense to include this data here as well?
My tool reported some duplicated cookies, so I'll pass this info on (I can also fix this in a couple of days if nobody else has the time)
viewed_cookie_policy is contained twice, with the same information.
OptanonConsent is contained twice, with slightly varying information.
Additionally, these cookies are newly added with the same name of another cookie. This was bound to happen eventually (as nobody reserves cookie names), but either way, we might want to consider the implications of this for tools using the database - at least my tool currently searches cookies purely by name and will thus not see the second entry for this cookie.
tk_ai is set both by WooCommerce and Jetpack with the exact same purpose. Perhaps we could merge these?
dpm, served both by Adobe and demdex - unless one uses the other, this might not be able to be resolved
sp by Quantcast and Snowplow. The descriptions hint towards the same use case, which might suggest both services having some sort of overlap in whatever sets this cookie
My tool reported some more duplicated cookies, so I'll pass this info on. Happy to remove/fix them myself through a PR.
i (72ac111c-477f-484f-b97d-62870b65ae85 and 3b89dcd0-1da7-4382-8d20-a4c9eb614e00) - once Yandex, once OpenX. This seems to be a genuine double usage.
clientSrc (c3a9fc08-a42e-449c-8584-58580baa1e4f & a7d2b130-e322-4f4d-86c4-b2c86e8e7517) - both Salesforce, one 1st Party, one 3rd
autocomplete (6cd0e40c-9cfc-4ce7-b9c4-7a312003d1bf & 42219382-45ea-4f39-acfb-6da2df996eda) - as above
disco (abcdaa07-7021-4979-a521-2afe3a7f1de3 & 00396982-e60c-4713-aa0c-c00ade38ff8d) - as above
inst (461a5ae4-12cb-413e-8c06-3d899fdeb3b3 & 4a3c8234-e9b6-4f5f-bb2e-1943dfe3e95a) - as above
If we normalize Domain-field to be empty to indicate Websites set this cookie to their own domain, I think it's fine to have duplicate names. Just right now, automated parsing of cookies that could be set to anywhere is near impossible to be 100% reliable.
If you agree, I could continue #21 and write a script to replace Advertiser's website domain and similar with empty fields.
There are currently three non-cookie entries in the DB, starting with Line 163. I suggest removing them as they carry no actual usable information (except that these services use JS Tags?) and may cause unexpected behavior in software utilizing the database.
Hi, first of all thanks for the effort to make this useful database.
But when I was checking the csv I've noticed the last column "Wildcard match". I've seen in some cookies like ga that subintentend that in the end of the cookie name could get the code that vary for each client, but How can I know where to complete the absent part? Its not clear for me. Have any insights?
While checking the database I found some duplicates. Each of the following Name-Domain pairs exist twice, with the only difference being the description. Thus, I think that they should be merged.
Name Domain
__atuvc .addthis.com
__atuvs .addthis.com
loc .addthis.com
obuid outbrain.com
sb facebook.com (3rd party)
uvc .addthis.com
Anyway, thank you for your nice work in piling up the database, it is really helpful for making more sense out of some cookies.