The Consent API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.:
The Consent API is the oldest of the privacy initiatives currently under active development, not yet merged into Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
It was created in response to the following ticket Created for both bug reports and feature development on the bug tracker.: https://core.trac.wordpress.org/ticket/44043 (Framework for logging/retrieving a user’s consent state)
The proposed feature plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. can be found here: https://wordpress.org/plugins/wp-consent-api/
The code is extremely light-weight (13KB, excluding the readme.txt and the licence).
The Consent API could greatly benefit from a wp_set_cookie(); function in WordPress Core, which would make adoption by plugin A 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 and theme developers more likely than the current has_consent(‘type’) approach.
These two items have natural synergies and would do well scoped together.
In its current form, the Consent API does not have any User Interface.
However, it would be more valuable to allow registered users to save their consent (functional, preferences, anonymous statistics, statistics and marketing) more permanently under their profile page for when they are logged in. There could also be settings for whether or not to make the profile visible to search engines, etc.
Logged out users, or users who are not signed up for an account, would not have a UI User interface in Core, but instead their UI would be provided via a cookie banner or comprehensive consent management plugin.
The Disclosures Tab:
Compiling a disclosures.json file for Core would be a significant undertaking, as, among other things, it is intended to disclose any external references (calls to other sites, available APIs, feeds, etc.)
The intention of the tab is to help site owners and admins to understand what information their site collects, where it is stored and where it is sent.
This will help site owners / admins to make more informed privacy-related choices and understand their privacy risk profile.
Any actual “controlling” (the Permissions Tab) is likely more suited as an optional plugin.
The Disclosures tab would require creating a JSON schema and writing a function (first in a plugin and then in core) to validate the schema.
The UI would most likely exist as a new tab under the Settings tab.
Enter the Local Avatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. Project:
CNDs have privacy considerations in that, at least in theory, it is possible for the CDN to track users across sites. Some CDNs do use data obtained this way as a source of marketing analytics data. Furthermore, the hashing that is used can be brute-forced, which may lead to unwanted disclosures of someone’s identity.
The Local Avatar Project has tremendous value as a case study in best practices.
Avatars are a highly relatable way to explain complex privacy concepts to users and developers like.
Furthermore, it has tremendous persuasive potential for achieving developer buy-in, as a common refrain includes “But avatars do the same thing!”
The UI for registered users would be located on the user’s profile page.
This UI would allow a registered user to upload an avatar (and could be extended by plugin to allow for more options, like selecting from a pre-set).
The UI for authorized users would be located as a new tab under the Media tab.
The UI for site-level settings would be located where the avatar settings are currently located, as this would most likely be the most intuitive for users.
Each of the above projects can be developed in a modal way in order to achieve a cohesive privacy-by-design vision.
This would require distinct, but complimentary education drives for developers and for site owners / admins.