Summary of Core Privacy Office Hours, Sept. 18th 2019

Below is a summary of the discussion from this week’s Core Privacy chat (agenda, Slack Transcript).

Agenda Item: 5.3 Enhancements

The following tickets were flagged as enhancements for 5.3 privacy component;

  • #43890 – Allow Admin to Skip e-mail confirmation for Export/Anonymization.
  • #44133 – Should the Data Export indicate when we have no information on the user.
  • #44135 – Have Erasure button workflow follow Export button workflow replacing with static link.
  • #44588 – Denote the Copy action is complete by updating the Copy button to state ‘Copied’.
  • #46303 – Update wp_privacy_send_personal_data_export_email to provide the same filters as _wp_privacy_send_erasure_fulfillment_notification.
  • #46895 – Personal Data Export Report: A way to display the group count.

#44133, #44135, #46303 and #46895 are all nearing completion but will need another set of eyes and review/testing before they can be marked commit.

#43890 and #44588 will need some work either a refresh or initial patch.
#43890 needs discussion but @garrett-eclipse is leaning towards the use of checkboxes instead of dropdown.
#44588 has site health example to follow and just needs coding.

@pputzer graciously offered to review some of these tickets.

Agenda Item: Privacy Data Request Form

Feature Plugin Proposal –

Not much feedback has been received yet so will let it gestate a little more. Initial feedback is pointing towards plugin territory over a core merge.

@audrasjb indicated it would be nice to test as a featured plugin so will determine how that can be accomplished.

Agenda Item: Consent and Logging Mechanism for User Privacy

Feature Plugin Discussion –

@garrett-eclipse asked if the effort needs to be setup like the WP-Notify #feature-notifications team and meetings.

Neither @idea15 nor @garrett-eclipse have capacity currently to spearhead the effort so decided to collect names of interested parties to create a working group. If anyone is interested in working on the consent/logging mechanism please feel free to comment on this thread or reach out in #core-privacy on Slack.


Privacy Office Hours Agenda: Wednesday September 18th, 2019

The following is the agenda for the privacy weekly office hours meeting. The meeting is held every Wednesday at 19:00 UTC in the #core-privacy room of the Making WordPress Slack.

  • Announcements / Housekeeping
  • Upcoming Release (5.3) Discussion & Planning
    Note: We have 6 enhancements pending for 5.3, they will need to be committed or punted by Sept. 23rd, 2019.
    • #43890 – Allow Admin to Skip e-mail confirmation for Export/Anonymization.
    • #44133 – Should the Data Export indicate when we have no information on the user.
    • #44135 – Have Erasure button workflow follow Export button workflow replacing with static link.
    • #44588 – Denote the Copy action is complete by updating the Copy button to state ‘Copied’.
    • #46303 – Update wp_privacy_send_personal_data_export_email to provide the same filters as _wp_privacy_send_erasure_fulfillment_notification.
    • #46895 – Personal Data Export Report: A way to display the group count.
  • Feature Plugin Proposal: Privacy Data Request Form
  • Feature Plugin Discussion: Consent and Logging Mechanism for User Privacy
  • Discussion / Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

#core-privacy, #privacy

Feature plugin proposal: Privacy Data Request Form

As part of the core-privacy team’s 2019 roadmap, the team has begun a discussion on the possibility of creating a front-end forms feature to handle Privacy Data Requests introduced in WordPress 4.9.6, most likely as a feature plugin.

We welcome all thoughts on this proposal, which you are welcome to leave as comments on this post, or share with us directly in the #core-privacy channel on Making WordPress Slack.

Introducing this feature plugin proposal

In 4.9.6, the ability for an administrator to initiate a data export or data erasure for a user by email address was added.

While this provided sites with the tools to be compliant with new laws and regulations, site owners are still left to find a way to accommodate those requests.

Adding a way for users to initiate this request on their own would prove a more “out of the box” experience and decrease the burden on site administrators to initiate these requests themselves.

Source: Core Privacy Team Roadmap

Creating a privacy front-end form mechanism –first as a feature plugin– presents an opportunity for the project to make a positive impact across privacy 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.

Integrated in the Privacy Policy page, this feature would help big websites administrators to automatize privacy requests management (exactly as in related page).

This feature would also help regulation organisms to directly verify the conformity of WordPress powered websites by creating privacy requests and checking the result directly.

Last but not least, using the feature in websites privacy policy pages would eventually made visitors more confident about the website owner as they could request their data by themselves.

Technical scope of the feature plugin

The feature plugin should at least handle the following scope:

  • PHP functions to generate privacy data requests front-end forms
  • PHP filters to handle forms customizations like editing wording and choosing either to use data removal action, data export action, or both
  • Privacy Request Widget
  • Privacy Request Shortcode
  • Privacy Request Gutenberg Block
  • PHP documentation for both functions and filters
  • CSS classes documentation

Introducing the existing base plugin

During previous meetings, the #core-privacy team discussed about an existing plugin reported by @garrett-eclipse and @xkon.

This existing plugin is already managing some parts of the feature:

  • PHP functions to generate front-end Privacy Requests Forms
  • PHP filters to handle forms customizations (like choosing either to show remove request, export request, or both)
  • Privacy Request Widget
  • Privacy Request Shortcode
  • Privacy Request Gutenberg Block

It has 5000+ active installs and the idea is to use this plugin to prepare and test a potential core merge of the Privacy Data Request Form feature in WordPress Core.

As the initial author of the plugin, I already made some changes:

  • The plugin’s SVN repository is open for core privacy team contributions (current contributors: @xkon and @audrasjb).
  • The plugin’s GitHub repository is open for contributions as well.
  • The plugin is not displaying anymore my employer’s logo.

What’s next?

Once the plugin is confirmed as a feature plugin, the next steps would be:

  • To increase the number of users of the feature plugin.
  • To change the display name of the plugin from “GDPR Data Request Form” to “Privacy Data Request Form” (though we must keep the actual slug, I guess we could edit the plugin Display Name).
    – Plugin Review team validation needed on that point.
  • To add other interested privacy team members and core developers as contributors of the plugin.
  • To keep an eye on the feature plugin’s support questions and ratings.
  • To iterate on the feature plugin development.
  • To audit some specific aspects of the feature plugin:
    • wording/copywriting
    • accessibility
    • design/theme compliance
    • security
    • coding-standards and documentation
  • To create a Trac ticket to handle a potential future merge proposal – if the feature plugin deserves it.
    Note: I already created a GitHub repo and generated a core diff file to test the feature directly against WordPress trunk (though it doesn’t contains the Gutenberg block nor AJAX validation)


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 Slack.

What is in scope?

Our roadmap notes

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 core, 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 plugin rather than a core feature.

Work on consent and logging is a considerable opportunity, and a challenge, for frontend and UX 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 source 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 deployed 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 plugin, 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.

How to build effective user controls

The core-privacy team draws on previously produced research, studies, and documents on best privacy practice. For user controls, the definitive source is: A Roadmap to Enhancing User Control via Privacy Dashboards (pdf), a study by the Privacy Bridges Project at the University of Amsterdam.

This diagram within the report explains the elements of a good consent and logging mechanism: 

Diagram of the elements in a user control mechanism: agency (users), architecture (technology and design), attitude (providers and platforms), and authority (privacy regulators).

The mechanism must provide users with the agency to exercise true and meaningful control over their personal privacy; it must be built on an architecture that has already enabled optimal user privacy by default; and it must be used to its fullest extent, by site administrators, from an attitude of responsibility and respect to users. A fourth element is authority, the interplay of legal obligations to user privacy; this sits alongside, rather than within, the main mix, as not all countries and systems have privacy laws in place. Users who do not have privacy regulations or safeguards protecting them therefore rely on agency, architecture, and attitude even more.

The report collated best practice advice on consent mechanisms (dashboards) offered by UK, Australian, Canadian, New Zealand, US (the FTC), and EU data protection bodies, and this list offers us quite a bit of food for thought:


  • Make the consent dashboard easily accessible for all users (for example, linking from the first screen);
  • Make the consent dashboard available to authenticated users, but also incorporate tools for passive and unauthenticated users, where their personal data is collected and used;
  • Link to this consent dashboard in the privacy policy of partner websites or third parties receiving personal data;
  • (We would add here that “accessible” should also mean the WordPress sense of a11y.)


  • The consent dashboard should be comprehensive to manage all services and privacy settings in one place;
  • Manage not only the processing, but also the collection of their personal data; and
  • Allow the exercise of data subject rights, e.g., access to copies of personal data (linking to our existing data export and erasure tools).


  • Default-settings have to comply with the applicable law (also including regional variations);
  • Default-settings to be specific to each product/service with privacy-friendly defaults, and
  • A feature to ‘restore to default settings’ could also be added.


  • Provide granular controls and upfront permissions, as well as giving the user ongoing control over their consent;
  • Provide information and control over which third parties receive personal data; and 
  • Offer a Do Not Track (DNT) mechanism that allow consumers to choose to prevent tracking by ad networks or other third parties.


  • The consent dashboard should be easy and straightforward to use;
  • Create a clear user interface that works to convey messages and draw attention;
  • Use design elements such as graphics, colours and layers to create hierarchies and user action;
  • It should be as easy to revoke consent as it was to provide it;
  • Ensure that users have a way to modify their information, have control of any tracking and delete their profile entirely if they wish;
  • Avoid making the dashboard unwieldy or too complex; and
  • Avoid dark patterns and any deceptive UX which compromises user privacy.

Information and transparency

  • Present information about the collection and use of personal data in an open, fair, and comprehensive way (as with our existing privacy notice tool); and
  • Instead of just using an on/off button, explain the consequences of making a choice to provide data so users can make an informed decision.

Support from other projects

As part of our participation in the cross-CMS privacy working group, we would be working closely with Joomla’s equivalent of the core-privacy team, which has already launched a consent management mechanism. They have offered to support us with practical advice and assistance. We also have support from the privacy initiative at Drupal, which has a consent and logging mechanism within a GDPR module (not in Core); Umbraco is looking to all three projects’ work to hopefully follow.


We have the benefit (right now) of a few months of leadup time, and our previous work together as a team means we have a good sense of how we work as a unit. What that means is that unlike our V1 GDPR work, we have a bit of breathing space to plan, iterate, design, test, and reflect.

That being said, CCPA’s deadline is 1/1/20, and its requirements are clearly defined. It may be practical to look at a V1 launch of the plugin with the functionality and options required for GDPR and CCPA, and then iterate for a V2 update containing the functionality required for the ePrivacy Regulation revamp; by that time we will know what its requirements will be.

It would therefore be logical – and more than a bit fun – to aim to build something for Rian Kinney to be able to show during her CCPA talk at WordCamp US (1-3 November); it would be a natural fit for a team table at WCUS contributor day as well.

What we will need

Our work on a consent and logging mechanism will need participation and expertise from a range of contributors:

Developers who can create the functionality needed to hook a range of consents and data rights into a single dashboard. As consent and logging requirements impact larger and enterprise clients at scale, we would love to see participation from agencies and teams working at this level in particular;

Designers and UX specialists who can integrate existing design research from CNIL, IAPP (member-only content available in Slack), and IF, as well as user testing, to make the back end interface simple and attractive, while making any front-end interfaces both effective and within healthy compliance; 

Policy experts who can advise on upcoming legal and regulatory changes which will impact what functionality might need to be built in (I handle this for Europe, @riankinney handles this for the US, and we’d love to expand our policy knowledge base with experts from other regions);

Project managers who can keep a complex, multidisciplinary initiative like this on task; and finally;

Conference speakers from the team who can speak about the initiative, and our work in general, at future WordCamps.

It should be noted that no members of the core-privacy team are funded or sponsored to contribute to privacy in WordPress, so we will need to be very realistic about what we will be able to accomplish within the time availability that we have; or indeed, if an initiative of this scope will be possible on a purely voluntary basis.

Next steps

Please join us in our #core-privacy office hours at 1900 UTC on Wednesdays to discuss this, or any of the other activities of the team’s work.


Privacy Office Hours Agenda: July 24th, 2019

The following is the agenda for the privacy weekly office hours meeting. The meeting is held every Wednesday at 19:00 UTC in the #core-privacy room of the Making WordPress Slack.

  • Announcements
  • Upcoming Release (5.3) Discussion & Planning
  • New ICO cookie guidance –
  • Data Request Form feature plugin and direction
  • Open Floor

If you have anything to propose for the agenda or specific items related to those listed above, please leave a comment below.

#privacy, #core-privacy

Dev Chat Summary: May 29th, 2019


@chanthaboune announced that since 5.2 has been successfully released, work will be resuming on the Team Leadership training. A blog post on will be published for anyone wanting to help review the training materials or otherwise indicate they are interested in learning more about how leads lead in WordPress.

WordPress 5.2.2 Updates

5.2.2 co-lead @marybaum updated the agenda with the following proposed dates for bug scrubs and releases:

Bug Scrub: Wednesday, May 29, 2019, 14:00 UTC
Bug Scrub: Thursday, May 30, 2019, 18:00 UTC
Release Candidate 1: Monday, June 3, 2019, 19:00 UTC
Bug Scrub: Thursday, June 6, 2019, 20:00 UTC
Release Candidate 2: Monday, June 10, 2019, 16:00 UTC
Final Release: Thursday, June 13, 2019, 16:00 CDT

Special thanks to @desrosj, @karmatosed, and @audrasjb who led bug scrubs in the past week!

Finally, requesting release packagers be available for the scheduled RC1 release on Monday, June 3, 2019.

WordPress 5.3 Updates

Owners of tickets currently milestoned for 5.3 are encouraged to triage them appropriately. If, as a ticket owner, you are unable to volunteer any time to your tickets in this cycle, please unassign yourself. I’d much rather know for sure that I have spots to fill/tickets to move than let anyone feel unnecessary guilt.

A few components are still assessing potential features to focus on. Once those are settled and focus leads have volunteered, then a finalized timeline for the release can be set. A mid- to late-August timeframe was hoped for, but maintainers were clear that expected features/focuses should be decided upon before more firmly committing to a final timeline. There’s no official, rigid requirement of an August release of WordPress 5.3.

@spacedmonkey asked if any key features have been announced for 5.3. @chanthaboune indicated that nothing is solid yet, and more confidence from maintainers about features that can reasonably completed for 5.3 is needed.

@spacedmonkey also inquired about what Gutenberg features should be expected for 5.3. @aduth pointed to a previous #core-editor chat that laid out the expected goals for Gutenberg updates in 5.3.

One of the aforementioned goals was a navigation block in Gutenberg. @spacedmonkey asked whether the new block will use existing menus from WordPress core. This spawned some debate between contributors about how menu data should be stored and the various admin interfaces used to interact with them. No decisions were made, and continuing discussion is encouraged on the relevant tickets at and See the Slack conversation for more of the debate.

Updates from component maintainers

Tickets were to be discussed, but time ran short, so they are included here for some additional visibility.


General Announcements and Open Floor

@sergey asked to open a conversation around changing the invalid and worksforme ticket resolutions in Trac to something more neutral and less confusing for users. The suggested change is: invalidnot-applicable and worksformenot-reproducible. @chanthaboune suggested a Make post for that discussion to allow for a more in-depth discussion.

@desrosj raised a flag for the current, expected size of the upcoming 5.2.2 release. At the time of the chat, there were only 13 tickets in the milestone. Based on past precedent, the release seems to be a bit under the threshold of what usually warrants a minor release. No decision was made, and a make/core post will be created to prompt more discussion of the topic.

Finally, @xkon announced that #core-privacy code has been split into its own files, adhering more to the WordPress Coding Standards and helping with maintainability. Given the better code organization/separation of concerns, now’s a good time to get involved with #core-privacy.

Thanks to all the attendees and everyone else that contributes to WordPress! These notes were taken by @davidbaumwald and proofread by @chanthaboune.

#5-2-2, #5-3#devchat#summary

#core-privacy April update

This is a cumulative update for #core-privacy office hours and bug scrubs held in April 2019.

Office hours are held every Wednesday at 19:00 UTC in the #core-privacy channel on Making WordPress Slack. Bug scrubs are Mondays at 15:00 UTC.

5.2 release

5.2 has been a monumental team effort by core-privacy. The team has shipped all 24 of its tickets earmarked for the release. These included 15 bugfixes and 9 enhancements.

Special props go to @garrett-eclipse for being the driving force behind the team’s 5.2 ticket success.

The “biggest win” was #44005, introducing the new privacy policy page helpers.

General fixes include:

#46098 – The Privacy Policy guide help notice is now displayed on both the classic editor and the block editor.

#44707 – Users are now able to make additional requests when identical previous requests are in a complete or archived state.

#44644 – The ‘Download Personal Data’ admin action no longer triggers a completion of the request.

Also in 5.2 some privacy nags were removed; post-4.9.6, these notifications had served their purpose:

#45999 – Remove the Privacy Pointer

#46819 – Remove the Privacy Bubble

Some i18N-Privacy wins were:

#44721 – The Personal Data Erasure Fulfillment email is now in the User’s Locale

#46056 – The Personal Data Export email is now in the User’s Locale

Tickets shipped since the March team update included #44175, #44644, #44047, #46819, and #46098. Props @knutsp, @desrosj, @joshuawold, @birgire, @mechter, @subrataemfluence, @xkon, @saimonh, @audrasjb, @dejliglama, @ianbelanger, @iandunn, @pento, @sergeybiryukov.

@earnjam wrote a post in Make/Core on the developer-focused privacy updates in 5.2.

@williampatton wrote a dev note in Make/Themes on the new privacy policy page helpers coming in 5.2.

5.3: export and erasure

For 5.3, @xkon would like the team to focus on finalising all outstanding issues with export and erasure requests. @audrasjb has given @xkon access to his repo for the front-end forms for export and erasure, with a view to using this as our first team feature plugin. (#44013)

5.3: privacy notice updates

The team has discussed #44538, #44669, #46687 as an opportunity for collaboration with the #design team.

Plugin privacy audit

@idea15 has finished writing beta version 1 of the plugin privacy audit workflow, with the help of feedback from many team members and plugin developers. Please feel free to test the workflow on your plugin and provide the team with feedback in #core-privacy.

WordCamp Europe

@idea15 has signed up for a slot for the team at the WP Cafe at WCEU. This will be a friendly hangout and chat space with no set agenda.

As with last year, #core-privacy will have a team table at the WCEU contributor day. As with last year, @idea15 @xkon @pputzer @postphotos will take turns secretly disconnecting the wi-fi.

Cross-project privacy cooperation

Members of the #core-privacy team who participate in the cross-project privacy initiative will be participating in the Mozilla Global Sprint in May to standardise file formats for data portability exports and imports across our CMSes, and to identify the export and import functionality which may need to be created within each project. All are welcome to join in. Dates TBC.

Conference talks

New on WPTV:

@rhyswynne at WordCamp Edinburgh 2018: How to integrate the 4.9.6 privacy features into your plugin

@mainplus at WordCamp Belfast 2018: Follow the data

@riankinney at WordCamp Rome 2018: The differences between U.S. and EU privacy law

New talks:

@idea15 participated remotely in a privacy BOF at Drupalcon Seattle on behalf of the #core-privacy team.

@pputzer gave an outstanding talk at WordCamp Vienna on 27 April focusing on active #core-privacy tickets from a developer/site owner perspective. The slides are available here.

Other matters:

@javorszky started a review of the privacy policies which is currently active and available for discussion & review here.

Developer Focused Privacy Updates in 5.2

WordPress 5.2 brings several improvements for developers working with Privacy Policy pages and data exports.

New Privacy Policy Page Helpers

Four new features have been added to make customizing and designing the Privacy Policy page easier:

  • A new function, is_privacy_policy(), can be used in conditionals to identify whether the current $wp_query is for the Privacy Policy page.
  • A new theme template file, privacy-policy.php, is used for rendering the page assigned as the Privacy Policy.
  • .privacy-policy has been added as a body class and is inserted when the currently rendered page is the Privacy Policy page.
  • .menu-item-privacy-policy has been added as a menu item class to specify the menu link that points to the Privacy Policy page.

Backwards Compatibility

The only backwards compatibility concern with using these new helpers is with the is_privacy_policy() function, which would trigger a Call to undefined function fatal error.

Themes and plugins that would like to support the is_privacy_policy() function in older versions of WordPress can use the following shim:

if ( ! function_exists( 'is_privacy_policy' ) ) {
    function is_privacy_policy() {
        return get_option( 'wp_page_for_privacy_policy' ) && is_page( get_option( 'wp_page_for_privacy_policy' ) );

For more information, see #44005.

Loosened Tag Restrictions in User Data Exports

User Data exports no longer use a hardcoded list of allowed tags, limited to just <a> and <br>. They will now use the default list of allowed tags in wp_kses().

Furthermore, the code facilitating the export now passes a personal_data_export context to wp_kses(), so that the allowed tags and attributes can be filtered using the wp_kses_allowed_html filter and checking for the personal_data_export context.

Here’s a filter example that adds support for the <sub> and <sup> tags to the personal data export:

function prefix_allowed_html_filter( $allowedtags, $context ) {
	// Only target personal data export.
	if ( 'personal_data_export' !== $context ) {
		return $allowedtags;

	// Add support for the sub tag.
	if ( ! isset( $allowedtags['sub'] ) ) {
		$allowedtags['sub'] = array();

	// Add support for the sup tag.
	if ( ! isset( $allowedtags['sup'] ) ) {
		$allowedtags['sup'] = array();

	return $allowedtags;
add_filter( 'wp_kses_allowed_html', 'prefix_allowed_html_filter', 2, 10);

For more information, check out the documentation for the wp_kses_allowed_html filter.

See: #44044

#5-2, #core-privacy, #dev-notes, #privacy, #themes

#Core-privacy March update

This is a cumulative update for #core-privacy office hours and bug scrubs held in March 2019.

Office hours are held every Wednesday at 19:00 UTC in the #core-privacy channel on Making WordPress Slack. Bug scrubs are Mondays at 1600 UTC.

We have welcomed several new members into our channel, and were also delighted to welcome back @xkon and @javorszky 🙂

Ticket and bug scrub update

The team has shipped all of its enhancements for the 5.2 release: #44005, #44044, #44707, #44761, #44822, #44833, #44901, #45136, #45999, #46041, #46254, #46369, #43438, #44233, and #44876.

Props @desrosj, @birgire, @garrett-eclipse, @tz-media, @xkon, @cc0a, @itowhid06, @mmuhsin, @arena, @duckdagobert, @dejliglama, @afercia, @mukesh27, @iandunn, @pbiron, @allendav, @azaozz, @jesperher, @davidbinda, @ocean90, @mikejolley, @Clorith, @pento, @ianbelanger, @jplojohn, @joostdevalk

The remaining 5.2 work will focus on resolving a few bugs which reside outside of the component but have a privacy feature. These are the two i18n issues affecting privacy notifications (#44721 and #46056) and an improvement (#37782) to the Menus which introduces the Privacy Policy page as an important page in the list.

@garrett-eclipse worked with Meta to update the Privacy Policy to link to the Data Erasure Request page (meta: 4223) and remove Quantcast verbiage (meta: 4216), and to start work on introducing the Data Export Request page (meta: 4224).

The team has begun to flag privacy-related tickets which should be built as feature plugins with the `feature-plugin` manual tag.

V2 Roadmap

The team’s 2019 roadmap has been published to Make. @postphotos wrote a blog post on Make announcing its publication and explaining how the team has structured the plan.

Github repo

@postphotos has gained admin access to the Github repo which we used for the V1 GDPR phase of our work. It has had no updates since 17 May of last year.

The team will now begin actively using the Github repo. The #core-privacy component maintainers have been given owner access to use it to build the feature plugins detailed in the V2 roadmap.

The existing pages on the repo from the V1 GDPR phase of the team’s existence will be retained on the repo and archived for reference.

Conference talks

  • Chris Wiegman – How to Improve Privacy of Your Site for You & Your Users at WordCamp Miami
  • Panel: What you need to know about Privacy and Security in 2019 at WordCamp Miami (no video yet)
  • Regina Dubinska y Jordi Sala: RGPD en la empresa y en WordPress at WordCamp Barcelona

Cross-project privacy cooperation

Please review and comment on the draft plugin privacy audit workflow drafted by @idea15 and Achilleas from the Joomla! privacy team.

The cross-privacy group will be participating in the Mozilla Open Leaders global sprint in May. It is essentially a virtual contributor day or days focused on something over and above the usual ticket scrubs and doc updates. The #core-privacy team participants should brainstorm something fun to do in cooperation with the Drupal, Joomla, and Umbraco privacy teams to advance global internet health.


Core Privacy’s 2019 Roadmap Published

We are super excited and proud to announce the #core-privacy team’s V2 Roadmap, which was published last week.

  • We’ve worked through the roadmap for the past few months, focusing on building for general privacy enhancements rather than specific legal obligations.
  • We intend to enhance our existing tools (the Privacy Policy generator, export tool, and the erasure tool we built for the V1 GDPR phase) while also developing extended support for things like Embed Privacy Controls and WP-CLI support. We are, of course, keeping an eye on legal developments in the privacy sphere to learn what tools and enhancements we’ll need to build a little later on as the needs change.
  • Where possible, we’ll work to build out plugins first, in order to make development easier for features, and then offer them as a merge to Core.

Let us know what you think of our roadmap! Share your feedback in the #core-privacy Slack channel.

As a friendly reminder, we are always looking for new contributors to our great little team. You can find our open Trac tickets here. We have bug scrubs on Mondays at 1600 UTC and we meet for office hours on Wednesdays at 19:00 UTC.