MiniCookie and Joe Workmans Agent stacks can identify the browser language. That is not enough to identify if someone is sitting in Germany and needs to be warned about cookies. That would come more accurately from their IP address. Is there an easy way of using the IP address to control the display of the cookie popup
Dont have it but might be worth a look to see if it can all mesh together
Mayb Iâm reading your post incorrectly, but you need to show a proper cookie consent banner/popup/whatever to more than just people in Germany.
And be careful with Mini Cookie. In some circumstances, in particular when using it in multi-cookie mode, it has a âquirkâ whereby itâs very easy for users to install cookies before the give consent.
In short⌠In multi-cookie mode cookies are installed when the user selects a checkbox, NOT when they click save settings. So, if they select a cookie checkbox, then deselect it before clicking save itâs too late, the cookie is now installed.
I discovered this issue a few weeks back and made a demo page, but forgot to do anything with it. So here it is, with more details of the issue and how to replicate it.
I have raised this âissueâ with the dev, but no resolution was come to, so I stopped using Mini Cookie.
Demo: minicookie | My Website
2 Likes
Iâd forgotten completely about that stack - itâs just what I need. Many thanks.
Good to know! Iâve also just found that although it shows the Matomo cookies, you cannot delete them through the stack interface.
Yes, I found that too, although being able to remove cookies via a cookie manager is not a part of GDPR, only that there is a simple method for removing them. Which all browsers offer.
I moved over to using Privacy Manager by @kennerty. It initially took a while to get my head around how it worked, but the dev (Kennerty) was on hand on email with fast and helpful replies to questions, so in the end I got it all setup nicely.
As the dev himself said when I asked a particular question⌠âIt has a lot of moving parts, but it all comes togetherâ and that, for me, sums Privacy Centre up. Yes, there is a lot of options and it does take time to get set up, but once that is done itâs really good. It does add a bit of lag to RW in edit mode as there are indeed a lot of moving parts, so I found it best to get it all setup and working on a dedicated page, then put it into a partial and add to the main site pages. But overall Iâm very pleased with it and would recommend it.
Itâs the same price ( I think) as Mini Cookie but does much more.
You can see it in action on the Template Repo site: https://www.templaterepo.com/
I do plan to make some styled versions of it and make them available via Template Repo, but Iâve just not had the time lately. Soon though, hopefully.
1 Like
Privacy Center can do that.
Also, Privacy Center can detect the browser language and show a multilingual version.
5 Likes
This looks really well thought out.
1 Like
Thanks for all the info. I looked at the Privacy Center when I was first released and it looked good, but by then I had already implemented MiniCookie. I might swap them out in a few months.
1 Like
Impressing!
1 Like
Itâs a nice demo, as it allows to look behind the curtain to see the actions. You are correct, the cookies are immediately written or deleted as the user checks or unchecks the respective options. However, I donât really disagree with this behavior. I interpret it in a way, that the settings are immediately reflected by the cookiesâ presence or absence.
The possibly confusing part is calling the button âSave settings,â which implies the activation of your choice, whereas it is simply closing the modal window.
The question is whether the âimmediate actionâ could result in unwanted behavior. I can only think of a situation, where the modal window is kept open with the wrong options selected, while one continues to use the website underneath it - possible, but not very likely.
It is well known that default settings are often used without further reflection (âtyranny of the defaultâ), hence having all cookies allowed per default is a bad consumer choice, but might serve the website ⌠In such a scenario I could imagine that all cookies are written, and if some code is loaded afterwards, the damage would potentially be done before the user can even deselect the options.
If that were the case then things would be great, but itâs not.
Cookies are installed when you click the checkbox, but they are not deleted when you uncheck it. That is the crux of what I see as the problem.
Right, that is what I feared when reading your description. However, when I tested it with your demo page (MacOS Monterey, Safari), I saw the cookies appear and disappear based on the status of the respective checkbox.
I had opened the web inspector and there the cookie list. When I checked a box the cookie appeared, when I unchecked it and refreshed the cookie list, the cookie was gone again. I needed to refresh the cookie list to see the update, though. Maybe I was mistaken and the ârefreshâ deleted the cookie and not the website ? The ârefreshâ of course is not a âdeleteâ as the refresh indeed showed the selective presence or absence of any combination of the three cookies.
Thatâs interesting, as it isnât the behaviour I see when using Chrome. Ticking the box installs the cookie. If I then unclick it, the cookie is still installed.
1 Like
When I tried it on Chrome here, it behaves like what I saw with the Safari browser. All seems to come down to refreshing the cookie display in the browser to see the current status:
1) Calling the testsite, selecting two cookies, but not yet updating the cookie list
- The same situation after refreshing the cookie list - now the cookies are shown, i.e. they have been written as soon as the checkboxes have been selected:
3) Changing the selection, but not yet refreshing the cookie list - the old cookies are still displayed
- Finally refreshing the cookie list again, and the list reflects the new choice, i.e. the cookies have been written or been removed as the checkboxes are changed:
Above screenshots were taken with Chrome (V99.0.4844.51). I see the exact same behavior with Safari (V15.3 (17612.4.9.1.8)). I very much appreciate all the extra work done to demonstrate and discuss this topic - one of the strengths to have such an independent forum available. It is not my intention to argue for one or the other stack, just trying to avoid that we accidentally make wrong claims about a stack or doing injustice to any developer out there. ⌠and all with the disclaimer, that I am not a developer and have no expertise in browsers. It is merely an observation and my interpretation ;)
You are correct. It does seem to depend on a page refresh. As you say, if you tick, then untick the cookie remains installed, but a refresh clears it.
Iâve updated the test page to use a conditional stack that installed some tracking code from matomo, itâs connected to the âWebsite Analyticsâ option in the cookie manager. And this does work. In that, even if you click the option, then unclick it, the tracking code isnât installed.
So contrary to my initial findings/thinking the multi-cookie option does work, of a fashion. Iâm surprised the dev didnât tell me the crucial bit about the page refresh to clear the ticked/unticked cookies.
There is still the outside chance someone will click the website analytics option, then refresh the page before clicking save, at which point the tracking code is installed, then unclick the website tracking option, then click save. Whereupon the tracking code will still be there. But this really is a corner case, and really, Iâm splitting hairs!
I suppose from my point of view, though, I have to say, I still feel the way it works is a bit wonky. Surely itâs far better to have nothing installed until the save button is clicked? But great work @GKs at getting to the bottom of this for me, and possibly others. This is definitely one of those instances where Iâm pleased to be found wrong.
Iâll update the page to reflect the new findings.
Page updated, with a final caveat that occured to me as I was writing. Many thanks for the clarity on this one @GKs itâs been really helpful.
And apologies to @AndrewP for somewhat stealing your thread!
The credit belongs to you ! You have created the test page and weâre willing to dig much deeper into it, than most people care. This exchange will help others to become informed and make their decision.
As for the developerâs response. They might have a bad day or become slightly defensive, when their code is criticized, and they donât understand why. As often, some slight misunderstanding can prevent us from coming together.
Thanks again to everyone, thatâs why I like this forum very much - always a place to learn from others.
3 Likes
All good - itâs been a great discussion :-)
Iâve updated Reef Image-Stories - Help save our reefs! to display the MiniCookie popup in all EU countries and Brazil. Country detection is by using Joe Workmans Geotargeting stack. Iâve also created a cookie explanation page here Reef Image-Stories: Cookie Management
If you agree to basic web statistics being created, and go to the cookie management page, youâll see the two pk cookies from Matomo(you might have to Reload the cookie list). The _pk* cookies cannot be deleted in the minicookie webpart, though all the other cookies can. (Tried in Edge and Safari). Does anyone have an idea why the pk* cookies cannot be deleted?
FYI, I am in Wales, which is in the UK, (regretably not part of the EU anymore), and visited your site for the first time. I didnât get any cookie message, which I believe I should have.
I donât see this is an issue, but I canât help thinking that you are vastly overcomplicating this whole cookie thing and that a better solution would be a one cookie message in English, for the whole world.