Add User Privacy CMS recipe to Basic Privacy recipe

Thanks for your suggestion @mxr576, I've also followed the discussion over at 🌱 [policy] Treat username enumerations as security bugs that require Security Advisories Active about this topic.

What I'm wondering:

• Isn't it important to e.g. disclose the author name of e.g. blog posts? I see lot's of cases where the missing author name on blog posts is an issue when someone else wants to give credit when quoting them.
• Same thing may apply to many other scenarios, where attribution may be relevant and the username not being perceived as PII.
• Where would the username of a non-author being ever exposed to non-admins?

I'm all up for the idea, I just want to understand the implications.

And if we move on with this, as the user_privacy_cms recipe is fairly simple, would you mind if we installed and configured the 2 extra modules directly from one of the existing recipes rather than adding yet 2 more dependencies?

@jurgenhaas I believe the key features address some of your concerns:

• Only usernames of content authors are visible to others, and only if those users have access to any of the author's published content.
• Usernames of non-authors are never visible to others.

As to where would usernames of non-authors be exposed to non-admins: In JSON:API mostly, which is why it is a concern especially in the context of credential stuffing attacks.

Chris arrived here sooner than myself :) I was also syncing with my CISO @akosh about your questions,.

So we believe access to the username should be denied by default and only gracefully opened up on a need-to-know basis.

Where would the username of a non-author being ever exposed to non-admins?

Yes, JSON:API as a default answer in Drupal as we explain that in our blog post with @akosh.

Isn't it important to e.g. disclose the author name of e.g. blog posts? I see lot's of cases where the missing author name on blog posts is an issue when someone else wants to give credit when quoting them.

Yes, in certain cases, such as blog posts, displaying the author's name can be useful, especially to enable proper attribution and give credit. However, this functionality should be configurable to suit different use cases and privacy considerations. Additionally, any configuration related to author name visibility must be consistent across all interfaces, including user interfaces (UIs) and APIs, to ensure clarity and alignment with permissions.

View Usernames Node Author → module addresses this challenge effectively. It works alongside View Usernames → , which modifies Drupal Core's behavior to a deny-by-default approach for username visibility. This extension explicitly ensures that when you author content on the site, your username becomes publicly available for attribution purposes, aligning with the principle of controlled, use-case-specific access.

Same thing may apply to many other scenarios, where attribution may be relevant and the username not being perceived as PII.

When attribution is necessary and usernames are used for that purpose, it is important to recognize that usernames are considered personal data if they can identify an individual, even if they are not strictly classified as PII in all contexts. As with the previous point, ensuring configurability and maintaining consistency across all interfaces (UIs and APIs) remains critical to appropriately handle such scenarios.

And if we move on with this, as the user_privacy_cms recipe is fairly simple, would you mind if we installed and configured the 2 extra modules directly from one of the existing recipes rather than adding yet 2 more dependencies?

Sure, it’s relatively small for now, and since we don’t yet know how it might evolve, it could make sense to install and configure the View Usernames modules directly without adding a dependency on the recipe.

Assigning to the privacy track lead to arrive at a decision and/or implementation.