The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
Feature plugin discussion: a consent and logging mechanism for user privacy
As part of the #core-privacy team’s 2019 roadmap, the team has begun a discussion on the possibility of creating a consent and logging mechanism, most likely as a feature plugin. This is a working document to assemble our thoughts on what the initiative would involve; this document is not the formal proposal.
We welcome all thoughts on this document, which you are welcome to leave as comments on this post, or share with us directly in the #core-privacy channel on Making WordPress SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
Consent capture refers to creating a means for users to express their consent to data capture and usage, and to change their opt-in or opt-out status at any time, through easily accessible means such as front-end user settings or account information areas.
Consent logging refers to creating a means for administrators to collect a history of how users have opted in or out of various means of processing their data across coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., themes, and plugins, to view the current status of that consent, and to make that history (and present state) available to users.
A standard way for WordPress core, plugins, and themes to obtain consent from users should be established to provide a consistent and stable experience for administrators, developers, and users of all kinds.
This initiative will likely require long term research, especially since it will be heavily influenced by pending regulations, such as the ePrivacy Regulation revamp, as well as user testing to ensure a positive experience for all while preventing “consent fatigue” or dark patterns.
Existing consent and logging projects, such as Joomla’s consent system, will be studied and emulated (where possible) for both functionality as well as potential applicability as a pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party rather than a core feature.
Work on consent and logging is a considerable opportunity, and a challenge, for frontend and UXUXUser experience design. Thought should be given to how users are prompted for consent, how and where they change consent, and how this experience could be consistent across WordPress sites regardless of plugins or themes. Creating an open sourceOpen SourceOpen Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. pattern library of designs for consent and choice while collaborating with other projects and organizations is advisable. Some existing pattern libraries have been developed for IAPP (International Association of Privacy Professionals) and by IF London, working with Open Rights Group (whom Automattic sponsors).
Although this work is independent of any specific regulation or law, it should be done with mindfulness of the new privacy laws coming into play in early 2020. Making a “head start” will allow an effective solution to be deployedDeployLaunching code from a local development environment to the production web server, so that it's available to visitors. well in advance of the eventual compliance deadlines.
While there are a range of privately produced plugins available in the repository to deal with user consent and logging, no work has been done to date evaluating these issues from a core perspective. We also know that many administrators have deployed these solutions without really verifying that they are useful, effective, or meet the regulatory compliance requirements applicable to them. Additionally, we know that everyone – users and administrators alike – will be fully aware of the obtrusive, confusing, and almost entirely incorrect cookie and consent windows which appeared across the web as a result of a misunderstanding of GDPR’s requirements. Where these are based in plugins, they can occasionally do more harm than good.
Creating a core-centred consent and logging mechanism, as a feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins., presents an opportunity for the project to make a positive impact across all these areas. It will empower administrators within the ecosystem to better comply with privacy-related requirements, while contributing to a better standard of protecting user privacy across the open web.
Is this a legal thing?
As a team, we work from the perspective of placing user privacy first and foremost, regardless of any particular legal compliance obligation, or indeed, any lack of one.
This mechanism would look ahead to the upcoming consent and compliance requirements of CCPA (US, January 2020) and the ePrivacy Regulation overhaul (Europe, spring 2020), while also looking back at GDPR. Recent developments including updated guidance on GDPR cookie consent from the data protection regulators in the UK and France, as well as Nevada’s data rights law taking effect on October 1, have brought forward the need for the mechanism.
That being said, this feature plugin would not be built specifically as a legal compliance package, as our V1 GDPR tools were, nor will it be depicted as a compliance solution. Indeed, a responsible approach to user privacy will mean having conversations along the lines of “well, X law says users do not have to be prompted to grant consent for Y thing, but should we give them that option and build that functionality regardless?” Working from this proactive user-centric approach, rather than taking a reactive legal compliance view, will help to future-proof the work and, perhaps, continue to protect users who may find that their legal privacy rights are being stripped back.
