Background
To date, the Drupal project has largely been reliant on the community and contributed modules to implement privacy standards, most notably those required by the EU’s GDPR privacy legislation. However, with privacy becoming a front-page issue, the need for closer attention to privacy standards is at the stage where it needs to be a core initiative. Additionally, with new privacy regulations on the way in the United States and elsewhere, addressing privacy on the core level will become imperative.
Problem
The overwhelming majority of sites built on Drupal are subject to some sort of privacy regulation, either currently enforced or which will be enforced in the next 2 years. Laws such as the EU’s GDPR and California’s CCPA, as well as issues such as the Cambridge Analytica disclosures, have proven that privacy can no longer be looked at as an issue affecting an isolated part of the community.
Proposed resolution
We have 2 proposed resolutions:
#1: Core Privacy Initiative
Taking queues from the core privacy work done in WordPress, we propose to create a core privacy initiative tasked with implementing a similar feature set as to what the WordPress project has done, and is represented by several well used community created modules. By bringing these modules into core, and giving them a general privacy name (instead of being a compliance issue for GDPR specifically), it will alleviate much of the confusion and doubt around what tools to use to help build a foundation towards compliance.
During Drupal Europe there were several discussions amongst the maintainers for the current GDPR module along with other contributors to the privacy modules in Drupal on how we can keep compliance specific code/features in the GDPR module while migrating the basic framework to core.
#2: Open Web Privacy Working Group
The idea is that through collaboration, the open source community can help shape the online community into one that values the user’s data and privacy through a positive and proactive approach to building guidelines, policies, and tools, rather than a negative and responsive approach to compliance as a legal obligation. The origin of this group is based on the work by Heather Burns found here:
https://github.com/webdevlaw/open-source-privacy-standards
In order to build the community necessary to take on this task, it is proposed that each project would nominate a handful of representatives to meet on a regular basis and to work to implement the guidelines and outcomes from the group into their project. By synchronizing efforts and sharing tooling across common code libraries, a broader basis for security and privacy focused features can be created in the open source community.
By taking a stance alongside WordPress, Drupal has the ability to be part of shaping privacy in the open web. The combined reach of the two projects alone is immense. Setting a foundation for privacy in the project will help to continue to the message of a free and open web that Drupal was built on.
Process and where to find it
It's proposed that this be a new experimental module that will not be part of any existing module in core. Currently there are several fractured groups/contrib projects but no where yet for the initiative to live.
Proposal roadmap
Since it would be a larger set of work that isn't currently based in core, it is proposed that this be part of the Drupal 9 release, which provides a great opportunity to introduce new functionality without having to be as concerned with backwards compatibility. However the experimental module could potentially make its way into a future Drupal 8 release as a way to test the functionality prior to moving to official core status.
In September 2018, there were discussions amongst privacy module maintainers and advocates on how we can proceed and this kickstarted the movement.
By Spring 2019 we're hoping to convene our first meeting of the open web privacy group, meeting with representatives from WordPress and other open source projects.
In the meantime, we will work with the GDPR module maintainers to create a new branch that implements the GDPR specific code and at the same time migrate the core framework to a new module named, Privacy. This module would provide the ability to flag personal content on entities, aggregate them into a view, and allow for basic reporting of what data is being stored. It would also create a new API allowing contributed modules to declare their custom entities and fields as containing private data (or potentially containing it). Additionally, the Privacy module would provide an API for modules to declare any privacy information that may need to be included in privacy policies on the site. By allowing module maintainers to declare what data is collected and transmitted to third parties, it will help site builders have a better grasp on what the modules they're using implement and can make informed decisions on how to include them in their site privacy policies.
Similar functionality to these features exist in WordPress core and serve as a good example of what would and would not be included in the functionality and what would be left to contributed modules to implement.
Not in scope
What the core privacy initiative would not do is attempt to make core itself “regulatory compliant”, as that is an unattainable goal. No project can make any site “compliant”; we can only provide the tools, resources, and functionalities for site administrators to achieve a healthy standard, which is very nuanced due to uses, localities, and legal obligations. Instead, the goal is to build a foundational toolset that can then be extended to the specific needs of each project and each use, while raising the bar on how user privacy is handled globally.
Related work
To date, the most comprehensive core privacy work has been done in the WordPress project, which created tools to allow for compliance with GDPR and then shifted to continue its work on a general privacy approach. Their roadmap for future work includes enhancements in UX, functionality, and developer tools to achieve a best practice standard in privacy not pinned to any one piece of legislation or legal requirement.
More information on their work can be found at: https://make.wordpress.org/core/components/privacy/ and https://make.wordpress.org/core/tag/core-privacy/
Existing core features
Currently no privacy features as proposed exist in core.
Open core issues
There have been several ideas/issues open that tangentially work around the issue and would be resolved by work on this initiative.
https://www.drupal.org/project/drupal/issues/2971794 →
https://www.drupal.org/project/ideas/issues/2895197
✨
Add support for encrypted field api field storage in core
Active
Contributed projects
Much of the work for how the core framework would be implemented is already present in the GDPR module, however the focus of the module on GDPR compliance would not be migrated to core.
https://www.drupal.org/project/gdpr →
Team and resources
I am volunteering to act as the initiative coordinator as I've been involved in much of the discussion and planning to date. I have been coordinating with Heather Burns from WordPress on how we can collaborate amongst the teams and led the discussions in Drupal Europe around the plans for the initiatives. Additionally, I'm now involved in privacy advisory committees for the US Government and have a goal to represent the various views of the open web community into the government decision making and the policies created which will effect our communities.
Additional team members will likely be made up of contributors to the GDPR module and other privacy advocates. I won't speak for them directly here yet, and they can edit the topic to add their names to the list as the discussion grows.
Signoffs
During Drupal Europe we had a brief discussion with Dries on our goals and plans for the working group and initiatives which were met with agreement on the concerns, and that the plan was progressing in the right direction. Additionally I've discussed with Mike Giffords, who maintains core accessibility and has been a vocal advocate in the issue queues and groups for GDPR compliance. He agreed with the initial plan for the initiative and supported the efforts.
Signoffs needed
This may touch various subsystems and is a product decision as a whole so there are likely signoffs necessary at all levels from maintainers, product managers, and finally Dries
Signoffs given
No official signoffs yet.
