Support » Plugin: Complianz | GDPR Cookie Consent » Seems powerful, but frighteningly heavy-handed and inflexible

  • I tried installing this plugin because my existing GDPR plugin has apparently been abandoned by its developers. I was intrigued by the cookie scanner and the prospect of automating some of the functions I’ve had to do by hand.

    Unfortunately, its implementation looks to be a horrendous uphill battle likely to confuse and frustrate visitors and webmasters alike.

    This plugin starts adding banners and new top-level pages to your site (with weird, misleading titles like “do not sell my personal information”) BEFORE YOU EVEN COMPLETE THE SETUP WIZARD. There’s no allowance for review, testing, or approval before it goes live, and if you have other GDPR or cookie compliance plugins already in place, it will break them — it won’t deactivate them, but it will cause them to malfunction. (For example, I have Google Analytics Germanized and it removed the “reject/dismiss” button from that plugin’s banner.)

    For GDPR compliance tools, it’s really important for webmasters to be able to set up and review the settings and tools before going live with them. I wanted to be able to poke around in the options and settings and see what functionality it provided so that I could decide whether it seemed workable and what would be involved in integrating it with my current privacy policy and cookie lists. Nope! You go live NOW, as soon as you open the wizard; just hope that no users come to your site in the interim to be confused by the new pages and banners, and hope no regulators ask to know how these pages interact with your existing privacy privacy policy.

    The only way this approach would be practical is if you had the opportunity to test it on a sandbox site or subdomain, or if you were willing to use .htaccess rules to limit public access to your site before going live (which would involve effectively taking your site offline for a while). That doesn’t work for me.

    Also, while the cookie scanner is a useful feature, it doesn’t register all cookies, even WordPress core administrative ones like the wp-settings cookies. It showed a message indicating there were other, unrecognized cookies, but when I tried to expand the list, there was nothing there. It did list some that I don’t recognize, which is singularly alarming, but probably not the fault of the developers of this plugin.

    An intriguing package, but I can’t deal with the stepping-off-a-cliff approach to setup.

Viewing 13 replies - 1 through 13 (of 13 total)
  • Wow, Thats a detailed review. I can tell you that I have checked EVERY popular cookie plugin on a SANDBOX environment and by all counts, this one was the best. It does take a little fiddling to get perfect but thats why you should test ANY plugin before you go live.

    • This reply was modified 1 month, 3 weeks ago by djbtcs.

    Well, sure, but that’s exactly my complaint: This plugin doesn’t give you any opportunity to even kick the tires before it goes live. Given the number of settings, the amount of fine-tuning involved, and for many organizational users the need to get approval for sensitive wording, that’s a substantial and honestly prohibitive flaw.

    I see your point. What I have always done is duplicate site to sub domain to test and configure anything new. As you know, plugins can often have conflicts and mess everything up. The developer of this is very proactive so I am sure they will take your comments on board.

    Privacy policies, cookie policies, and terms of use are legal documents — that is their entire point. In many jurisdictions, if you post a privacy policy and/or cookie policy, you’re legally required to abide by it, and failing to do so can carry heavy penalties and/or civil liability.

    For a plugin to start generating LIVE LEGAL DOCUMENTS before you’ve even finished going through the checklist (much less had a chance to double-check it or show it to anyone) is pretty berserk. That goes a couple of steps beyond the common sense precaution of testing your changes in a sandbox environment first; it may create actual legal hazard for unwary webmasters.

    Plugin Support Aert Hulsebos

    (@aahulsebos)

    Hi @ate-up-with-motor,

    Thanks for your feedback. And @djbtcs as well. We will discuss these points shortly with our team and will come back with a more detailed reply soon.

    regards Aert

    Plugin Support Aert Hulsebos

    (@aahulsebos)

    Hi @ate-up-with-motor,

    Let me start by saying we appreciate any feedback. We’d love to hear and learn from our users, especially in making a difficult subject more accessible for users, like compliance for websites.

    We have cut your review and feedback in relevant parts, so our reply is as specific as possible. Please let us know if anything is unclear or we forgot something.

    “About complexity and inflexibility.”

    Our main goal of this plugin is to present a fully-featured, out of the box solution for one of the most misunderstood subjects of the last couple of years. And for many years to come.

    Creating the tools to assist you in being compliant and take away the ambiguity of most resources is exciting and challenging in itself. Let alone trying to keep the complexity to a minimum, while being flexible enough for most users.

    We are always working on lowering the threshold for our users to create a compliant website while offering complex functionalities.

    For example, more editing possibilities in the auto-updated legal documents after the documents are generated through the wizard. This is coming soon!

    “Adding a banner and a page called Do Not Sell my Personal Information.”

    Complianz will add a banner when the wizard questions and cookie scan result in the need for a Cookie Banner / Notice, in your case for the USA. It will also create a DNSMPI page, based on the wizard and cookie scan to comply with the Californian privacy law CCPA. The naming of this document might be weird but is not misleading according to the CCPA and is required as is.

    This URL of this page is live, but will not be published on the front-end in any way, other than a link on the Cookie Notice. The page itself should be in a menu item as well, which is possible in the second-to-last step in the wizard.

    We will have a look if we can delay generating the pages and banner, before a possible double-check.

    “About breaking Google Analytics Germanized.”

    For other plugins, with overlapping functionalities, our next release will categorize functionalities, which can be enabled/disabled when and if needed — for example; controlling analytics. Sometimes, in more complex matters, you will need to ask support to help you with integration and compatibility with your website — especially when using multiple plugins that add the same features.

    “Configuring and testing the plugin.”

    Configuring and testing the plugin is only possible when the banner and pages are live; if you want to test the plugin with different configurations, we would suggest a sandbox or staging environment.

    The wizard and the following cookie banner settings should comfortably set-up most users. If any regulators see the page during the configuration, we can not decide what would be better, no banner at all. Or the necessary pages and banner, almost configured.

    But as we said prior, we will have a look at how to approach the configuration.

    “About our cookie scan…”

    The cookie scan works best, as stated above the scan in the wizard and in our documentation, when in incognito mode (empty cache) and with extensions like AdBlocker disabled. Otherwise, there might be a false-positive or unrelated cookie in the scan, because of the extensions mentioned above and browser caching.

    The scan will register cookies that are present in your browser during the scan. It might take longer to find cookies that are triggered by specific actions. That is why the automatic, scheduled scan will notify you of any changes in cookies, plugins, etcetera.

    The scan will not register cookies set on third-party domains, like facebook.com. For this, we created questions in the wizard for social media and third-party integrations to complete this process and add the cookie description and block the service when needed.

    Finding unknown cookies, without description, will be a rare occurrence hopefully from release 4.0 on when we will sync the cookies with our new cookie database.

    Please let us know if you have any follow up questions or feedback. We would love to hear it.

    regards Aert

    I recognize and appreciate your desire to offer a complete solution. My central objection is that generating the pages and policies during the setup process is extremely troublesome. I’m also not sure why it’s necessary; most other WordPress plugins at least provide a “Save Changes” button in their settings.

    It’s also important to give users the ability to decide, for example, where to place the applicable links and how to integrate the additions with existing privacy policies or other notices.

    I want to be compliant, but I also don’t want to break my site, confuse visitors, or present embarrassing typos or other technical errors in the process. Your plugin makes that intimidatingly difficult.

    I must emphasize also that I was not looking to go live at all — I was hoping to look at the available settings and features of the plugin to compare them to other compliance solutions. So, I was very alarmed that it insisted on moving forward immediately.

    With regard to the cookies, I understand that there are technical limitations, but I found it very peculiar that the tool did not correctly identify all the cookies that are set by WordPress itself. For me to be able to even install the plugin, I needed to be logged into the administrative dashboard, so the site had actually added the necessary cookies to my browser, meaning that they were not blocked by any privacy settings or add-ons.

    Plugin Author RogierLankhorst

    (@rogierlankhorst)

    Hi @ate-up-with-motor, three things to note about the cookie scan:

    • Only the front-end will be scanned. This means that cookies placed on the wp-admin path won’t be found. These are not relevant for front-end users.
    • Some cookies, like wp-settings, or save-post, will get filtered out because these are also not relevant for front-end users.
    • Not all pages will be scanned in one run, to limit memory impact. Each scan a new set will get parsed.

    If you have cookies that are stored on the front-end, but not found, let me know which one and I’ll check if I can reproduce it.

    As for the pages: to enable a user link a page to a menu, a page has to be published. This makes it necessary to publish pages before step with the menu’s has been reached. We could add an extra step to makes this explicit.

    What is possible, is to prevent the cookie banner from showing up before the wizard has been completed. When finishing the wizard, a notice can tell a user that finishing will set the banner live.

    I recognize that there’s a sequence that has to be completed for the menu items and links to work — I just had to do this manually this afternoon. However, I feel like it would be significantly safer and more comfortable for users if you allowed the user to enter and check all the information and then provide a series of clearly delineated triggers to make the information live: generating the pages; adding menu items; enabling the banner; and so on.

    Given the sensitivity of this process, it would also be very prudent if the plugin gave the user the ability to save currently entered data during this process, prior to beginning the publication steps, and go back to previously completed portions of the setup process to double-check and amend that data if needed. Since this data is presumably stored in the WordPress database anyway (it appears that the generated pages just contain a shortcode to retrieve the appropriate data from the database), this does not seem technically infeasible.

    The contact form plugins I use, which also require the placement of a shortcode in a published page or post, provide ample opportunity to edit and revise the code before making it live. Contact forms are, in most cases, considerably less legally sensitive than compliance functions.

    Regarding the cookies, I think that it might be beneficial to provide the ability to run the cookie scanner without going through the rest of the setup process; from what Rogier is saying, it may take several runs to recognize everything, which the current setup doesn’t seem to easily allow. It would also be helpful to note the caveats Rogier mentions in the user interface, since it’s not readily obvious.

    I have some reservations about the logic of ignoring cookies in the wp-admin path. First, it does seem to register certain of them, but not others. Second, the user interface doesn’t make clear that it’s only looking at front-end cookies, which may confuse some users.

    Third, some plugin users are likely to have multiple administrators or contributors who have access to the dashboard, or portions of it, and there are some security plugins that place cookies on the login screen as part of mechanisms to limit brute-force attacks (temporarily blocking people who enter the wrong login information more than a certain number of times). The latter type of cookie should probably be disclosed to front-end visitors, since they may access the login page accidentally (or maliciously!) even if they aren’t registered users. For registered users, the admin cookies should probably be enumerated so that they can be disclosed to new contributors/admin users when they register. If the cookie scanner is capable of distinguishing front-end cookies from ones on the admin path, you might consider having a separate list that specifies, “These cookies may be placed if you’re a registered user with an account login” or something to that effect.

    Beyond that, I think it’s very important to give users the ability to review and edit the generated documents. Many users already have privacy policies and other disclosures, which may have been the subject of a great deal of scrutiny to make sure they correctly reflect the user’s actual practices. While the ability to generate complete documents is a very useful feature for users who have not dealt with any of these issues, others will be wary of creating contradictions and confusion with their existing documents and notices.

    Again, I understand and appreciate the desire to create a comprehensive tool, but that entails a series of assumptions that may not work for all users, which makes the all-or-nothing setup approach troublesome.

    A possibility you might consider for future releases is allowing the setup wizard to run in two modes: simple/easy, where it assumes you’re starting from scratch and provides you everything you need, and advanced, where you can go through the available functionality in stages and edit or skip the parts you intend to handle in a different way (e.g., integrating an existing DNSMPI page rather than generating a new one). That, combined with the ability to run the cookie scanner in a standalone mode, would seem like the optimal way to accomplish what you’re going for while addressing the problems I’ve raised here.

    Plugin Author RogierLankhorst

    (@rogierlankhorst)

    Thanks for your input, we’ll discuss it internally with our UX designer and legal advisor, and see how we can integrate your suggestions. The first release, coming next week, will be about the UK as separate region, a new design, and fine grained integrations tool, which allows a user to enable or disable blocking of consent requiring services.

    After that, we’ve planned the cookiedatabase.org release, a community driven Cookie Database, which will sync more detailed cookie descriptions to the cookie list.

    Your suggestions seem valid, and will be taken into account after the Cookie Database release.

    Plugin Author RogierLankhorst

    (@rogierlankhorst)

    Hi @ate-up-with-motor,

    We have done some tests, but couldn’t find any missing wp admin cookies. Is there a specific cookie you were missing?

    All cookies seem to get found without any issues, but if you have found one which isn’t there, and which is relevant for users, be it logged in or not, would be great to know which one that is.

    Rogier

    Ate Up With Motor

    (@ate-up-with-motor)

    IIRC, the core cookies it didn’t detect for me were the wp-settings-time-[user ID] and the wordpress_test_cookie. It also didn’t seem to pick up the wp-saving-post cookie, although I didn’t do any detailed testing on that.

    An additional concern was that it didn’t detect itsec-hb-login-[hash], which is a cookie the iThemes Security plugin places any time someone accesses the login page, to limit brute force attacks. (Placing the cookie allows the plugin to determine if someone has made more than the specified number of failed login attempts within a set period.) The cookie detector did not recognize that cookie, even though it’s placed in the browser of anyone who’s logged in or attempts to log in.

    I hope that helps.

    Plugin Author RogierLankhorst

    (@rogierlankhorst)

    @ate-up-with-motor ok, thanks. The test cookie, settings-time, and saving-post are currently ignored, as these do not apply to websites where users are not logged in. We will add a question in the wizard for 4.0 if a website has logged in members, and leave the cookies in the policy in that case.

    As for the itsec cookie: I use iThemes on all my sites, and don’t have this cookie on any of them, so I can’t reproduce this issue.

    I do see some other WordPress cookies on the wp-login.php page, so I’ll add this page to the scan in case of logged in members.

Viewing 13 replies - 1 through 13 (of 13 total)
  • You must be logged in to reply to this review.