-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cookie consent #2
Comments
I'll use https://www.richeyweb.com/documentation/10-eu-e-privacy-directive instead |
Thanks for the JED review! I took your 85% ease-of-use as a feature request, and implemented a template override for the ribbon output. Version 3.9.0+ has the feature. |
Yay! I love you!
Do you have a repo where I can PR a feature to not block the login cookie? There is an elegant way to do that in code and I believe it’s a good default (his kind of cookie is still allowed without consent).
|
I've been resisting that change because of GDPR Recital 30 - the Joomla session cookie (once a user has logged in) can and is used to identify an individual person. Many have asked for it (since 2012). I resisted it for EU e-Privacy Directive because the only assurance against enforcement came from bureaucrats (who have never been trustworthy). GDPR is more strict. I am looking at setting up a more granular acceptance mechanism. Like the mechanism used by cookiebot.com (except mine will actually work) |
I believe you are wrong.
The recital refers to tracking cookies such as those set by Google Analytics. Joomla’s session cookie falls under the category of necessary cookies which do not carry tracking. They become personally identifiable only if the user EXPLICITLY logs in at which point there is no reasonable expectation of anonymity.
Furthermore, starting 2019 it will be illegal to decline providing service if the user declines cookies. This creates an obvious impossibility with the way you have written your software.
Finally, I’d argue that you are currently doing is illegal. If the user doesn’t accept ALL cookies (including tracking) they can’t log into the site. So the only way for the user to consume our services is to accept being tracked by Google Analytics.
Do you see my point? All I’m asking is give me the option to allow Joomla session cookies. If you don’t I’ll have to fork your code and include my copy in Data Compliance because I can’t hack core every time you push an update and I can’t tie my services to accepting being tracked by a third party either.
|
One thing is for certain - GDPR Is a can of worms. The first tests in court will be interesting. The people I speak with are split regarding how that first test will play out. Some believe a small company will be taken to court to test the framework of the law, others believe it's about money and a large company will be taken to court to extract maximum penalty. My plugin doesn't force tracking on anyone, so I'm not breaking any laws. Additionally, it's possible to use GA without cookies. As I said before, I'm working on a more granular acceptance mechanism to allow users to choose which cookies they will allow. I'll make it so the administrator can choose if the session cookie is optional. It's something I want to have ready for testing sometime next week. |
So, there is no chance of adding a simple switch and a 3 line if-block? Just because your interpretation of the law is different than your users' since 2012 per your admission? I can understand this if we're talking about a massive, complicated feature which takes time to develop and maintain. But this is a boilerplate switch code in the XML file and two lines of code (three if you count the closing brace of the if-block). I don't understand why you don't want to it. Anyway, I guess there is another feature I need to implement in Data Compliance then. I hate having to fork off code but if that's what it takes... |
That's exactly what I'm doing - adding an option to force session cookies. It defaults to no, so it maintains the current behavior. |
Oh. I understood the exact opposite, that you are NOT adding that option. My apologies. |
In the next version, the ACL feature is being extended to each individual cookie. Users will be presented with a list of cookies they can choose to enable (similar to what Cookiebot.com does). If the session cookie setting remains off, the session cookie option in the list is checked+disabled because it is core functionality. Other cookies which are marked "required" will also be checked+disabled. The rest, when selected, add users to the associated access levels so plugins/modules can be allowed to load. If an admin chooses to force the session cookie, it's delivered automatically, and the session cookie option does not present in the cookie list. Here's a screenshot of the config: |
3.10.3 is out now, after identifying a couple of bugs, implements the granular control as well as an option to allow the session cookie to pass while still blocking everything else. |
Revised: we will have to fork off ePrivacy Directive and add an option for whether Joomla session cookie should be blocked. Moreover, we can use the same DOM adoption trick we use in Akeeba Backup's modals to have the HTML generated server-side instead of client-side.
Until we do that we have to hack core every time we update ePrivacy Directive on our site to prevent blocking of Joomla cookies.
The text was updated successfully, but these errors were encountered: