Cancel

Justin Tadlock

Proposal to Add a Consent API to WordPress, Feature Plugin Available

On Wednesday, Garret Hyder announced a feature proposal for a WordPress Consent API. The proposal is one step on the larger privacy roadmap for core. If merged into WordPress, it would establish a standard method for core, plugins, and themes to obtain consent for various privacy-related features. The idea is to create a consistent experience for developers, site administrators, and site visitors.

The WP Consent API plugin is available via the WordPress plugin directory. Development is currently happening on the plugin’s GitHub repository.

Hyder identified several areas in which an API for handling consent could help in bringing a site into compliance with various privacy laws:

  • Consent management plugins cannot prevent other plugins from placing a PHP cookie.
  • Plugins that integrate tracking code on the client-side could break the site if blocked by a consent management plugin.
  • Minified URLs in JavaScript files may not be detected by automatic blocking scripts.
  • Using a blocking approach to handle privacy requires a list of all types of URLs when dealing with cookies and other types of tracking.

“Primarily this API is aimed at helping to achieve a compliant use of cookies or other means of tracking by WordPress websites,” wrote Hyder in the proposal. “If a plugin or custom code triggers, for example, Facebook, usage of this API will be of help to ensure consent. If a user manually embeds a Facebook iframe, a cookie blocker is needed that initially disables the iframe and or scripts.”

The goal is not to create functionality that would block third-party scripts, such as tracking from a site like Facebook. Because different jurisdictions have their own laws across the world, the actual management of blocking functionality would be best suited for a consent management plugin. This would be outside of the scope of what WordPress does out of the box. By providing an API directly in core, it would allow plugin developers to build consent management plugins that are needed in different locations. The API would merely be a means for all plugins to talk the same language. That standardization would allow consent management plugins to work as they should.

Furthermore, adding a front-end user interface would place additional scripts, styles, and functionality on all WordPress sites. These types are things are best handled by plugin developers.

The API proposes allowing the creation of consent categories. Such categories might be preferences, marketing, or statistics. They would be filterable by plugins. The API has two indicators to determine consent for a category: a region-based consent type, which can be opt-in or opt-out, and the visitor’s choice.

The team working on the project has put together a Consent API Demo to see how this plugin would work along with consent management on a website’s front end. The demo makes use of the Complianz plugin and an example plugin for showcasing how the API works.

Consent management is a tough area to handle in terms of web design and development. On the one hand, respecting the privacy laws of various jurisdictions is necessary for many people around the world. On the other hand, cookie notice popups on websites often create a poor user experience for site visitors, and that experience may only get worse before it gets better.

However, a standard API is past due in core WordPress. This will at least provide plugin authors with a means of working with consent management plugins. In time, maybe we will find a front-end interface that creates a nice experience while maintaining privacy.

The team is currently looking for feedback on the proposal and plugin. If the feature proposal is accepted, authors of consent management plugins should be prepared to begin integrating with the API.

Category:
12

12 responses to “Proposal to Add a Consent API to WordPress, Feature Plugin Available”

  1. This is actually a fantastic idea; I really hope they integrate it into core.

    A standardized API for this would really help consolidate everything for my own plugins, especially since, for example, consent is only needed if the site owner enables certain features.

    Create forum topic from comment

  2. Like Dylan says above, this is indeed a fantastic idea.

    Right now, we need to roll out our own consent method or mess up with plugins to enforce that setting… Depending how it is implemented in each case.

    In any case, having a single option that can be checked for this would make life easy for everyone.

    Create forum topic from comment

  8. So ironic. A consent API coming from core who doesn’t care about consent when it comes to forcing new features that considerably change core without a site owners consent such as auto-updating core (opted in by default since 3.7), the recent large image dimension restriction (opted in by default since 5.3), and forcing of the new editor to be full screen (opted in by default since 5.4) as if these were in high demand by people other than core contributors who…let’s be honest here, mostly wanted accolades to place under their names for notoriety.

    All of these should be feature plugins or opt-in only features, not forced by default requiring one to opt-out after the fact. Do you know how many pro photoblogger websites I had to patch to allow hi-res images, not cool!

    Yeah, “consent”, but only when it’s on OUR terms. Now this will likely be enveloped into core as well, most likely… without anyone’s consent.

    It’s like we forgot the core concepts behind how open source works. When I share something with someone and give it to them 100% to do with as they please, I am sure they will appreciate I do it without keeping one-hand on it and forcing my future desires on them even if I believe it’s what’s best for them.

    Create forum topic from comment

    • Developers do not need consent from end-users to continue developing new features or making changes to the software. That’s not how the process works. If that were the case, WordPress would have never advanced to the point it is at now. We can’t all point to our particular dislikes and say they shouldn’t be in the platform because we didn’t consent to them.

      As for auto-updating old installs without consent, I vehemently argued against doing that. Software should never be updated without consent (either through terms or an option). If the software says it’s an opt-out feature, that’s fair. Just don’t do it retroactively for installs where it was previously an opt-in feature.

      Create forum topic from comment

      • Agree, with varying degrees of consent severity, such as “in principal”, that which we should never stray vs generally just being kind to one’s user base and how it impacts them, hopefully weighing for better or for worse if it should be – the new default.

        “Like” function seems to be bugging atm. +1 like

        p.s. I recall your points.

        Create forum topic from comment

  9. I realize I forgot to balance my comment with some of the positives as I was overcome with shock that “consent” was at the forefront of the topic while ignoring what seemed to me the most obvious of recent scandals regarding consent that anyone can see simply skimming the core comment threads where many voice the same concerns I did.

    Thanks for the article Justin and I am glad we are considering this Consent API provided it is implemented in a way a site owner can choose to take advantage of it – i.e. they give “consent”. Otherwise (to some) the name implies that which it is not.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.