[policy] Consider username enumerations as security bugs that require Security Advisories

Changing queues as this is more a DST policy discussion impacting the entire D.O. ecosystem than it is a core issue.

It would have to be the formatter for usernames

Yes, \Drupal\user\Plugin\Field\FieldFormatter\UserNameFormatter() should be used everywhere and the getDisplayName() should be deprecated on the user entity.

The entire view's access could also include a check for that permission, right?

Yes, the user entity's access handler could make a decision based on any condition, like a site-wide permission or a state of a checkbox on the user entity that indicates whether the user gave consent for exposings its username on the site or not.

I would also add that one obvious location on every Drupal site for exposing usernames is the Author field on nodes that does not check whether the user gave consent for exposing their names or not (must be relying in an "explicit consent" which either given or not.)

Yes, \Drupal\user\Plugin\Field\FieldFormatter\UserNameFormatter() should be used everywhere and the getDisplayName() should be deprecated on the user entity.

Took a look at UserNameFormatter and template_preprocess_username() again and it just feels odd, misplaced and very much a D7-heritage that a template preprocess function tries to ensure proper access checking before rendering. Getting rid of this and moving things around could be tricky, but IMO the field formatter (and other username field formatters) should be responsible for checking access to the data before they pass that to the rendering layer. See 🐛 The entity link label formatter should check URL access RTBC and 🐛 StringFormatter always displays links to entity even if the user in context does not have access Needs work .

This worth a new child issue that can be tackled as a dedicated effort, am I correct?

@mxr576 yes any issues to improve core's username rendering/access should be separate core issues in the queue and can be worked on completely independently of this policy issue. I'd probably recommend a core meta issue (if there's not already one) related to this issue, then sub-issues under that.

One place usernames get rendered in a non-standard way is in the node 'submitted' template variable which should be moved to an extra field per ✨ [META] Expose Title and other base fields in Manage Display Active .

The steps laid out in the issue summary indicate the security team would get involved very late in this process. It's not a policy for the security team to decide separately from the core process.

@greggles Perhaps you meant this needed an IS update instead?

This is regarding DST policy, and would cover ALL modules on Drupal.Org not just core. Core does not set the D.O. security policy, the DST does.

It might need one, but I still feel it belongs in the core queue until/unless it finishes with steps like the product manager review.

What about user selection widgets with autocomplete? They use to show the username

What about user selection widgets with autocomplete? They use to show the username

Those are tricky ones indeed. Most likely they can only list usernames of users that the given user (current user) has view access to their usernames. For stored values, when the given user (current) user does not have access to view the other user's username it must display a placeholder (or just the user id, this is what we have in our solution).

Thank you to everyone following this issue and to those who join the conversation in the future!

We’ve just published a blog post that explains why we believe this topic is critically important. The post also serves as a release announcement for two contributed modules we developed in-house to address this challenge:

• View Usernames →
• View Usernames Node Author →

These modules do not require any API changes in Drupal core but aim to provide immediate, practical solutions. Ideally, a comprehensive solution would involve robust new APIs for managing personally identifiable information (PII), including but not limited to usernames.

We hope these contributed modules can help move the discussion forward and pave the way for the necessary enhancements in core.

... and now these modules are also available in Recipes.

https://www.drupal.org/project/user_privacy_core →
https://www.drupal.org/project/user_privacy_cms →

@claudiu.cristea #43 Those are behind a secret based on the salt. See \Drupal\Core\Entity\Element\EntityAutocomplete::processEntityAutocomplete and \Drupal\system\Controller\EntityAutocompleteController::handleAutocomplete $selection_settings_key argument.

Hm, reminder to me to check if there is missing entity access check
in \Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection::getReferenceableEntities() - because it seems it only relies on query level access checking... - and that could be a reason why the "Author" autocomplete works interesting in node edit form when View Usernames and friends are enabled.

@penyaskito but it's still username enumeration, right?

if there is missing entity access check
in \Drupal\Core\Entity\Plugin\EntityReferenceSelection\DefaultSelection::getReferenceableEntities() - because it seems it only relies on query level access checking...

Indeed, that is the reason.