django-cookie-consent icon indicating copy to clipboard operation
django-cookie-consent copied to clipboard

Remove Third Party Cookies When Cookie Group Declined After Originally Accepted

Open 9mido opened this issue 5 years ago • 4 comments

When accepting a cookie group, the cookies for that cookie group get loaded into the browser normally. Then for that same cookie group, declining right after accepting will keep those same third party cookies from that cookie group loaded in the browser.

The user might not know how to go into their browser settings and delete the cookies themselves. They might think that declining them will get rid of the cookies.

Perhaps adding in logic to do the deleting of the third party cookies from that cookie group automatically when declined (must be originally accepted - not declined on the first time visiting your site) would help the untechnical user and lawyers from taking action against you because the users are still technically being tracked via the previously accepted cookies.

Maybe you could loop through all of the cookie names from that cookie group in the database and if that cookie group is declined, delete those same cookie names from the database that are in the browser. The only problem I see with this is if the third party's cookies change themselves automatically in the future or more are added by the third party over time without you knowing and not all of the new third party cookies are added in the database. The django-cookie-consent admin might not add the domain to the database either.

There are lots of Google results for javascript deleting cookies by domain or just deleting cookies in general but I am not sure which method is best. There are even ways to delete cookies via django instead of javascript.

Would adding a setting like COOKIE_DELETE_ON_DECLINED = True|False or COOKIE_DELETE = True|False work? Maybe instead of tying this feature to each group's decline button, have one separate button called "Delete" (so you will have "Accept", "Decline", "Delete") for each group or all groups to delete all of the cookies used on your site (separate group buttons for deleting would probably be more personalized for the user since they might not want to accept/decline each cookie group - otherwise additionally adding to the top of your cookie page one button to delete all cookies from all groups would need to do the same exact thing as clearing cookies in your browser which would reset the accept/decline buttons all together).

Maybe someone else has a better idea / vision how to handle this? I defer to the maintainers/authors. @MrCordeiro @bmihelac @andreasnuesslein @JonHerr @Jasper-Koops

9mido avatar Oct 27 '20 02:10 9mido

I'm against adding a 3rd button. More choices, and more specifically, more uncommon choices are likely to confuse the user.

Isn't this scenario a very rare edge case? Do other cookie managers, like OneTrust, delete all previously accepted cookies if the user changes their mind? For now, I think you should add a PR adding a little warning on the documentation about this particular gotcha.

MrCordeiro avatar Oct 29 '20 17:10 MrCordeiro

Thanks for the feedback @MrCordeiro. That is why I left it to a discussion for now to see what everyone thought and come up with a better way to handle this type of thing if you all wanted to do it. I don't use other cookie management systems so I am not sure if they actually do that - but we could test each one and find out. But I doubt they do any kind of deletion of cookies from the website itself and most likely rely on the user to do it themselves inside their browser's settings/inspect tool. I have not seen this type of thing anywhere else. I thought it would be a cool feature to have and would put django-cookie-consent in a league of its own (better than the other cookie management systems since they do not seem to have this delete feature).

Lots of websites just put links to directions or write out directions on how to manage cookies for that particular browser. So I thought why not have an automated method to deal with deleting cookies for any browser instead of having the user waste time figuring out how to do it? Yes it gives the user more choices but I believe it would give them the same exact number of choices plus a lot more reading if there are directions on the page outlining how to delete the cookies anyways (it would also save space on the page if this were implemented and there would be no need for directions for each browser and it would just work for all browsers).

If you do not want to use this feature then a custom django setting for it might be appropriate instead of having it forced on everyone who uses django-cookie-consent. Or maybe tie it into the decline button to get rid of the extra choice (but that may defeat the purpose of having separation of duties where you have 1 thing that does that 1 thing well and instead you would have 1 thing that does multiple different things which would confuse coding efforts by others in the future and might introduce bugs). I think having separation of duties would be best - "accept", "decline", "delete" separate from each other. Plus who knows the laws might change in the future and deleting from the website's cookie settings/preferences page may be a requirement down the road.

9mido avatar Oct 30 '20 00:10 9mido

The middleware seems to solve a lot of this.

some1ataplace avatar Mar 05 '22 04:03 some1ataplace

This will indeed be handled by the middleware via #80 (originally #54).

Keep in mind that it's not possible to delete third party cookies, and the user still have to manually delete those. Only first-party cookies can be cleaned up. This is added to the documentation in the above mentioned PR.

sergei-maertens avatar Sep 24 '22 14:09 sergei-maertens

Given the middleware fixes and this discussion not being active anymore, I'm going to close this issue to clean up the backlog.

If there are new insights, feel free to open a new issue (I'd really like to use the Github discussions for that too, but I'll have to contact someone to enable that).

sergei-maertens avatar Jun 11 '23 15:06 sergei-maertens