Proposal: Treat FLoC like a security concern

Google is rolling out Federated Learning of Cohorts (FLoC) for the Chrome browser.

TL;DR: FLoC places people in groups based on their browsing habits to target advertising.

Why is this bad? As the Electronic Frontier Foundation explains in their post “Google’s FLoC is a terrible idea“, placing people in groups based on their browsing habits is likely to facilitate employment, housing and other types of discrimination, as well as predatory targeting of unsophisticated consumers.

This is in addition to the privacy concerns of tracking people and sharing their data, seemingly without informed consent – and making it more difficult for legislators and regulators to protect people.

So What Now?

WordPress powers approximately 41% of the web – and this community can help combat racism, sexism, anti-LGBTQ+ discrimination and discrimination against those with mental illness with a few lines of codeLines of Code Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses.:

function disable_floc( array $headers ) : array {
	$permissions = [];
	if ( ! empty( $headers['Permissions-Policy'] ) ) {
		// Abort if cohorts has already been added.
		if ( strpos( $headers['Permissions-Policy'], 'interest-cohort' ) !== false ) {
			return $headers;
		}
		$permissions = explode( ',', $headers['Permissions-Policy'] );
	}

	$permissions[] = 'interest-cohort=()';
	$headers['Permissions-Policy'] = implode( ',', $permissions );
	return $headers;
}
add_filter( 'wp_headers', 'disable_floc' );

What About Admins Who Want FLoC?

Those websites who want to opt into FLoC are likely to have the technical know-how to simply override this proposed filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

When balancing the stakeholder interests, the needs of website administrators who are not even aware that this is something that they need to mitigate – and the interests of the users and visitors to those sites, is simply more compelling.

Furthermore, for WordPress versions that support privacy settings, we can easily add an on-off toggle to enable websites to opt in. This would only require a few more lines of code and only a couple of new strings.

What Do You Mean By “Treat It Like A Security Concern”?

  1. Include the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. the next minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality., rather than waiting for the next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.;
  2. Back-port the patch to previous versions of WordPress.

Why Treat It That Way? Why Not Just Wait For The Next Major Release?

Well, keep your eyes peeled, because there is a ticketticket Created for both bug reports and feature development on the bug tracker. for future releases on its way!

While it is indeed unusual to treat a new “feature” this way, there is precedent in that something that was not strictly a security vulnerability in comments was back-ported to previous versions for the good of the community as a whole.

Currently, 5.8. is only scheduled for July 2021. FLoC will likely be rolling out this month.

Furthermore, a significant number of WordPress sites only update to minor versions. By back-porting, we can protect more sites and more visitors to those sites – and amplify the impact.

Request For Comment

Please join the discussion below!

Whether want to show support, disagree vehemently, or just want to make the implementation the best that it can possibly be, please have your voice be heard.

I’m aware that there is a lot of discussion on other platforms, including Twitter on this matter, but we won’t see all of it, so in addition to spreading the conversation there, please comment here too, so that it can be considered when this is discussed at development meetings and when the ticket is created (consensus building first – and that is done here 😉 )

YOU DO NOT HAVE TO BE A DEVELOPER TO PARTICIPATE. There will be a ticket on core.trac.wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ where we will discuss all of the technical stuff. I’m tremendously grateful that there are so many developers, Core, MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and others, around, but blogblog (versus network, site) posts on make.wordpress.org are the places that are accessible to techies and non-techies alike 🙂

Version Control:
1. Edited to add clarification that treatment like a security concern refers to the process / procedure (accelerated development and back-porting).
2. Code snippet updated based on suggestions below. Thank you to Tom for the snippet and to everyone who suggested conditionally appending, rather than replacing.
Added some more info to the Request for Comment.
#core-privacy

X-post: Protecting Children’s Privacy On WordPress (through the lens of COPPA)

X-comment from +make.wordpress.org/meta: Comment on Protecting Children's Privacy On WordPress (through the lens of COPPA)

Request for Input: Consent Preferences for Logged In Users (Consent API)

The coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-privacy team are currently working on three modular, but complementary initiatives, with the aim of merging into 5.6.
These are: The Consent APIAPI 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. (website visitor level privacy); the Disclosures Tab (site-level privacy) and collaborating with the core-media team on the Local AvatarAvatar 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.

The Consent API in its current form does not distinguish between consent preferences for users who are registered and logged in, vs. those who are either not registered, or registered, but not logged in.
This means that all consent preferences are currently saved in cookies.

This means that there are two approaches available to the team. Either we can use the wp_set_consent() function from the user’s profile page to allow them to manage their preferences and prevent unnecessary API calls (proposal 1 – status quo), or we can let the database be the ultimate source of truth to provide a more robust API, rather than an interface for an analytics opt-out (proposal 2).

There has been a lot of discussion in the channel lately. I will post a separate P2P2 A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and other workgroup blogs. post for discussions such as prompting logged in users who previously opted in for consent again if new cookies are added – or at the very least least providing the necessary hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and filters for plugins to do so. Those are concerns can be realistically and effectively addressed in the UIUI User interface design requirements.

This is a fundamental design choice and while the window is wide open now, it will not remain so for long, as 5.6. approaches.
For purposes of this discussion, we please need input on the following, so that we can take the matter to dev chat:
1. Should consent preferences for registered users (applicable when logged in) be saved in cookies, or should they be saved in the database?
If consent preferences are saved in cookies, these could be displayed (and updated) in the user profile, but the choice would be transient and would effectively need to revert to site defaults every time the cookie is cleared.
2. If they are saved in the database, should the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. be used to expose the logged in user’s consent preference on the front end?
3. If the REST API is used, should a new REST endpoint be created, or should register_meta() be used instead?
4. Should the consent preference be exposed on the front end using wp.data? The trade-off being that this provides nicer abstraction and makes it easier to move towards object-oriented, rather than event-orientated programming, but adds a few KB to the front-end?
5. If wp.data is used, should only this be used, or should the consent preference still be exposed to the front end by a method in point 3?

Thank you for everyone who has participated in this discussion on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. so far. I intentionally did not include who made which proposals for this P2 post, in order to focus on the merits of the alternative solutions, but will credit participants in tickets if those need to be created.
Participants in the Slack discussion are of course very welcome to express their opinions here! 😀

Your inputs are appreciated!

#consent-preferences, #consent-api, #core-privacy, #privacy, #request-for-comment

Minutes: Core Privacy Meeting 19 August 2020

The Consent APIAPI 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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..
It was created in response to the following ticketticket 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 pluginFeature 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 pluginPlugin 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 UIUI User interface in Core, but instead their UI would be provided via a cookie banner or comprehensive consent management plugin.

The Disclosures Tab:

The Disclosures Tab is intended to aggregate the information collected from individual disclosures.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. files in individual plugins, themes and Core.
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 AvatarAvatar 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.

Vision:

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.

#consent-api, #core-media, #core-privacy, #disclosures-tab, #local-avatar-project, #minutes

Agenda: Office Hours 19 August 2020 at 18:00 UTC

@paaljoachim has asked what the UI needs to look like for a Privacy screen in Core. You can read the conversation here: https://wordpress.slack.com/archives/C9695RJBW/p1597418745430800 (a Slack account is needed)

  • Site-level privacy
    Initiatives: 1.) Disclosures and Permissions Tab; 2.) Local AvatarAvatar 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 (in collaboration with the #core-media team)

    The DPT would require writing a JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. schema, as well as a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. function to validate it (hopefully in collaboration with the #core-restapi team).
    The UIUI User interface would most likely be under Settings -> Privacy.
    This interface should help site owners / admins understand what information their site collects (by means of individual plugins, themes, as well as Core), where it is stored and where it is sent.
    Ideally, this would provide a mechanism for the site owner to prevent data from being transmitted off-site / make choices with regards to third party access.

    Part of the Local Avatar Project would overlap with site-level privacy in the following areas: Settings, Permissions and Library.
    There is currently still a discussion as to whether a fully-fledged library is needed (defined as that image metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.-data needs to be edit-able).
  • Website-visitor level privacy
    Initiatives: 1.) Consent APIAPI 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.; 2.) Local Avatar User Upload Screen

    The Consent API in its current form is not intended to have any UI.
    This is due to the fact that website visitors who are not registered / not logged in still need to be able to exercise privacy choices.
    However, it may be nice to allow logged-in users to save their privacy choices on a more permanent basis, perhaps by making use of user_meta. In this case, there would need to be a UI on the user’s profile screen to support this.
    There would presumably still be no UI for users who are not logged in. A UI could be provided by means of a consent management pluginPlugin 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.

    Additionally, the Team needs to discuss which filters / functions may be necessary in Core in order to convert the Consent API feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. into a more fully-fledged API, e.g. wp_set_cookie();

    Part of the Local Avatar Project would overlap with website-visitor level privacy. This would mainly be in the following area(s): User Profiles. For example, users may want to indicate that they do not wish for their avatars to be indexed by search engines.

Please join us for this week’s office hours to discuss what these solutions may look like!

#consent-api, #core-privacy, #disclosures-tab, #local-avatar-project, #privacy

Open Agenda Item: #core-privacy and Gutenberg

The Difficulty: GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ development happens on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, instead of on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. (which allows for “needs-privacy-review” to be added to the workflow of any ticketticket Created for both bug reports and feature development on the bug tracker.). This makes it very difficult for other teams to keep up with changes that have a potential significant impact on their team. The Gutenberg repository is huge and it is simply not possible for those working on smaller teams to keep up with all issues / PRs while trying to run their own teams and dealing with other responsibilities.

Other Solutions We Have Considered: We have considered subscribing the #core-privacy channel on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. to GitHub. The rest-api channel did this, but it leads to some flooding and does not work when labels are added later on (which would usually be the case with privacy).

So What Do We DO? All triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. volunteers on the Gutenberg repository on GitHub should please consider whether a particular issue touches on any of the following. If it does, the issue should not proceed / the PR should not be committed, before the Privacy team has been given a meaningful opportunity to consult. If you find such an issue, please post a link here, so we can have a look. Please also make use of the #core-privacy channel on Slack if you need our help. We rely on the Gutenberg triage volunteers’ assistance in this matter.

Issues / PRs that are considered to affect privacy:

1. If the issue / PR suggests that an external call should be made from the site owners’ WordPress installation to any other external site (whether PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher / JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. / CSSCSS Cascading Style Sheets.), even if this site is WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/;

2. If an account with a third party would be needed in order to utilize any functionality (basically SaaS – I do not expect that this is likely to happen, but I am including it here for the sake of completeness);

3. Calls to any APIs (including, but not limited to calls to external APIs for the purposes of updates);

4. Use of any remote assets (e.g. images / JavaScript libraries / fonts hosted elsewhere);

5. Any cookies are proposed / use of local browser storage, or similar;

6. If the editor proposes to write any information to the DB (other than content like posts explicitly generated by the user);

7. If new Custom Post Types are proposed;

8. If new custom tables are proposed;

9. If any PPI (Protected Personal Information) may be stored;

10. If any e-mails will be sent by the code;

11. If there will be any advertisements in wp-adminadmin (and super admin) (again, not something I think is likely, just including it for completeness);

12. If any backlinks are requested (again, probably unlikely for Gutenberg).

Please also report any items not listed here, which you think may affect the privacy component.

Thank you for your co-operation and transparency in this matter.

Privacy Office Hours Minutes 14 May 2020 Plans for WCEU Contributor Day

Mission for WCEU Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/.:

Make Privacy Actionable.

Working groups:

There will be two working groups:
– Coding working group (coordinated by @garrett-eclipse);
– Non-coding working group (coordinated by @carike).

Pre-event office hours:

– 3 June 2020 at 10:00 UTC;
– 3 June 2020 at 19:00 UTC.

Pre-event office hours are to help onboard new contributors.
This primarily involves making sure that they have access to the tools necessary for the day.

Tools:

SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.:
Privacy Policy: region-specific at https://slack.com/intl/en-us/privacy-policy
Terms of Service: region-specific at https://slack.com/intl/en-us/terms-of-service/user

StreamYard:
Privacy Policy: https://streamyard.com/resources/docs/privacy/
Terms of Service: https://streamyard.com/resources/docs/tos/
We will be using StreamYard, as a number of experienced contributors in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-privacy have expressed an unwillingness to use Zoom due to privacy considerations.

YouTube:
Privacy Policy: https://policies.google.com/privacy
Terms of Service: https://www.youtube.com/t/terms

Core TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. (coding working group):
Privacy Policy: https://wordpress.org/about/privacy/

GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ (coding working group):
Privacy Policy: https://help.github.com/en/github/site-policy/github-privacy-statement
Terms of Service: https://help.github.com/en/github/site-policy/github-terms-of-service

How to participate:

As a host:
If you are interested in hosting one or more topics, please comment below.
You can contact @carike on Slack if you would like more information.

As a guest via StreamYard:
You DO NOT need to register a StreamYard account in order to enter the stream as a guest.
You DO NOT need to download any program in order to use StreamYard. It is an in-browser solution.
You DO NOT need to appear on-screen if that is not something you are comfortable with. An audio-only option is available. We’re going to be using a very practical approach, so I’m going to be screen-sharing most of the time anyway.
We will provide new contributors with instructions on joining StreamYard as a guest via e-mail.
Instructions can also be found here: Guest Instructions: https://streamyard.com/resources/docs/guest-instructions/
We will provide new contributors with a link to join the stream via Direct Message (DM) on Slack, as there can only be six contributors “onscreen” (or via audio) at any one time (i.e. two hosts and four new contributors), with up to four additional new contributors in the “waiting room”.

As a guest via YouTube:
You DO NOT need to register an account with YouTube in order to watch the stream.
You DO need to register an account and be logged in to YouTube in order to participate in the live chat.
StreamYard supports integrating live chat messages from YouTube.
This will allow for more real-time input and also allow participation among those who do not want to use audio, or appear onscreen.
We are trying to recruit experienced contributors to help moderate the YouTube live chat to ensure compliance with the WCEU Code of Conduct, as well as to highlight any questions, comments and suggestions to the hosts.
Please comment below if you are able to help with YouTube live chat moderation.
You can find a copy of the WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. Europe Online 2020 here: https://2020.europe.wordcamp.org/code-of-conduct/

Via Trac (coding working group):
You DO need to register an account with WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ in order to comment on Trac tickets.

Via GitHub (coding working group):
You DO need to register an account with GitHub in order to create / comment on issues or to create / comment on Pull Requests (PRs).

On the day:

Coding working group:

13:00 – 16:00 UTC (coding working group)
Garrett will be available on Slack during this time.

The coding working group will participate via Slack, Core Trac and GitHub.
@garrett-eclipse is going through the list of privacy-related tickets to mark them with the “good first bugbug A 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.tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) where applicable.
For the more adventurous, there is the option to contribute to “help wanted” tickets for the next major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. (WordPress 5.5.).
An overview of current privacy tickets can be found here:
https://make.wordpress.org/core/components/privacy/

Non-coding working group:

The non-coding working group will have two two-hour sessions.

13:30 – 15:00 UTC
How to market without destroying user privacy (working title only).
Hosts: @carike and @jonoaldersonwp
During this session, we hope to identify online marketing best-practices that can be implemented even when users have opted-out (or not opted-in, depending on the jurisdiction) to being tracked with the view of creating actionable Trac tickets and / or to provide a resource for content marketing.
Topics will include:
– What is informed consent in a marketing context?
– Which digital marketing strategies were employed pre-the-ability-to-track-across-platforms and how may we able to adapt these?
– Which data points may still remain available for analytics if a user opts out of / does not opt in to the collection of their PPI.
Jono is “special ops” at Yoast SEO and we are very excited to have him participate.

16:00 – 18:00 UTC
A case study in the application of the Privacy Workflow Document and the Disclosures and Permissions (DPT) tabs.
Hosts: @carike and @pepe
In this session, we will be attempting to harmonize the Privacy Workflow Document and the Disclosures and Permissions (DPT) tabs and apply them practically to the WP Job Manager pluginPlugin 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.
The desired outcome for this session is an action plan for an education drive among plugin and theme authors regarding the proposed disclosures.json file.
Pepe has previously presented at WordCamp, is very involved with the #core-privacy team and was helped to create the draft Privacy Workflow Document. His insight will be invaluable to this session.

License:

We will be using the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license for the non-coding work group:
https://creativecommons.org/licenses/by-sa/4.0/legalcode

Contributions to the WordPress.org code are licensed in terms of the General Public License (GPLGPL GNU General Public License. Also see copyright license.) version 2 or later:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

Slack logs:

You can view the Slack logs here:
https://wordpress.slack.com/archives/C9695RJBW/p1589396619341400
In order to view the logs, you will first need a WordPress.org account: https://login.wordpress.org/register
You will then need to register a Slack account: https://make.wordpress.org/chat/

Change log:
14 May 2020 at 14:15 UTC – @carike added GitHub information.
14 May 2020 at 17:45 UTC – @carike updated formatting in the Slack links.
16 May 2020 at 11:35 UTC – @carike switched out the non-coding session starting at 16:00 UTC, as Pepe has agreed to co-host.
18 May 2020 at 18:05 UTC – @carike added the times Garrett will be available on Contributor Day.
1 June 2020 at 13:55 UTC – @carike changed the start time for the first non-coding session in order to accommodate the WCEU introductions.
3 June 2020 at 19:40 UTC – @carike added details for the workgroup sessions and removed the third session.

#contributor-day, #privacy, #wceu-2020, #wordcamp-europe-online-2020