Build privacy advanced recipe

This MR is now available for testing by the privacy track team. It only configures the data protection framework in a very basic way.

What it does so far:

• A new tab "All your data" is shown in the user profile where users can request a data export or data removal.
• A task management is available for admins at /admin/config/gdpr/tasks where they can work on those requests. Note: the cron needs to run several times during that process
• The SQL Dump is being configured to anonymize some data
• For the reports, removal and SQL dump only these 4 fields in the users_field_data if being anonymized: name, mail, password and initial email.

This is working fine and if we want to go ahead with this, we can then discuss which other fields needed to be included into the list of sensitive data.

A downside that comes with this setup: the GDPR config section at /admin/config/gdpr comes with 3 items that we don't need/want but that can't be disabled. Those are: Checklist, Summary, Content Links

Another issue may be the name GDPR, as it is misleading for most users, in fact, all users outside the EU.

Still, let's give this a try and then discuss how we want to proceed.

Honestly? Can't see a problem here so far. Just had one question.

One small change requested. The MR is still in draft, though; should that be changed? There also seem to be merge conflicts against 0.x that need to be resolved.

@phenaproxima I've provided some more explanation in the thread to the MR.

Although I have rebased the advanced privacy branch upon the latest 0.x branch, the recipe did not apply automatically when running ddev drush si --yes. After ddev composer require drupal/gdpr, ddev recipe-apply recipes/drupal_cms_privacy_advanced and ddev drush cr I was able to find all the above mentioned functionality.

1. The recipe sets the export directory to private://forget. However, the private path is not set, which leads to the following error:

   file_exists(): Unable to find the wrapper "private" - did you forget to enable it when you configured PHP? GdprTasksSarWorker.php:223
   [notice] The data could not be saved because the destination private://gdpr-exports/9230fad6-f1ef-4f92-ac86-bad2b04a7496.zip is invalid. This may be caused by improper use of file_save_data() or a missing stream wrapper.

   After setting the private file path in settings.php manually, the data export works.

2. The password hash is exported along with the user data. I'm not sure if that is a good and necessary thing.
3. It is possible to request and process the removal of user 1 data. This should probably be made impossible.
4. In Content links config the link to the Privacy policy page from privacy basic recipe could be set by default.

I think the GDPR module is suitable with a few modifications.

Configure entity fields by marking those with personal data as sensitive

Would be a real invention! Usernames should be marked as sensitive by default. See: 🌱 [policy] Treat username enumerations as security bugs that require Security Advisories Active

@mxr576 thanks for the link to the other issue. I'll also link ✨ Add User Privacy CMS recipe to Basic Privacy recipe Active as that may become part of this advanced recipe.

We've discussed this in the privacy track meeting earlier this week, and we've had a chance to talk to @yanniboi who maintains the fields and the task sub-modules in GDPR → .

We came to the conclusion that it would be great to extract those 2 sub-modules out of the GDPR module and turn them into first class citizens.

The GDPR-fields module should become a stand-alone module that acts as a kind of API for other use cases. It will allow site builders (or recipes) to define, which fields are sensitive (PII = personally identifiable information), and how that data should be processed in various contexts/use cases. Use cases will be implemented in their own stand-alone modules as well, each of which will then require this API module and build upon it. A potential name for this module could be "PII API".

Use cases, that should be built on top:

• Reporting about stored PII data and deleting that data on request: this is what the GDPR-tasks module currently does
• Altering JSON API responses: this is what the hide username modules are doing in part and should be generalized
• Altering Drupal's render output to protect PII
• and maybe others in the future

This would be a generic approach that breaks components down into logical pieces and ensures maintainability for each of them, as they have clear scopes and APIs so that components don't interfere with others when moving forward.

Looking for feedback on this approach, so that we can fine tune and then start executing this plan.

jurgenhaas → credited yanniboi → .