[wp-trac] [WordPress Trac] #64996: Allow non-ASCII (Unicode) usernames

[WordPress Trac]

#64996: Allow non-ASCII (Unicode) usernames
--------------------------------------+-----------------------------
 Reporter:  dmsnell                   |       Owner:  (none)
     Type:  feature request           |      Status:  new
 Priority:  normal                    |   Milestone:  Future Release
Component:  Charset                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-----------------------------
Description changed by dmsnell:

Old description:

> WordPress currently transforms usernames and potential usernames into a
> restricted set of ASCII characters. It attempts to remove HTML,
> diacritics, and transform other characters to ASCII equivalents,
> stripping away anything that remains.
>
> This prevents storing usernames that correspond to someone’s name or
> chosen identify, if that name falls outside the restricted range. For
> example, the username `北斎` is unusable because `sanitize_user( '北斎',
> true )` returns the empty string.
>
> WordPress should relax its restrictions on usernames to be more inclusive
> and permit locale-specific sites and users to express themselves as they
> are, not having to make concessions for latin-based technology.
>
> == Complications
>
> - Not all restrictions should be removed, but it would be important to
> double-down on the original intent of those  filters; notably, to limit
> confusable characters such as non-printable and non-visible characters.
> Unicode defines considerably more complicated text rules, so an update to
> the system should improve the Unicode compliance surrounding these
> issues.
> - Given the higher probability of multiple representations for non-ASCII
> usernames, it would be important to normalize all inputs using an
> appriate algorithm, such as NKFD.
> - Existing code and plugins are going to assume ASCII-only usernames and
> unlocking more complete naming should not introduce any more backwards
> compatibility breaks than are absolutely necessary.
> - Some installations will be running on non-UTF-8 database tables which
> cannot represent all possible Unicode-based usernames. For these
> installations, it must be clear that extended username support is
> unavailable.
>
> == Help
>
> Unicode provides ample guidance here which can help WordPress to:
>  - avoid known security issues
>  - implement these behaviors in harmony with expectations from other
> software
>  - how to best display these characters in interfaces
>
> == Warnings
>
>  - [https://unicode.org/faq/security Unicode Security FAQ] and
> [https://www.unicode.org/reports/tr36/tr36-7.html Security Considerations
> Technical Report]
>  - [https://engineering.atspotify.com/2013/6/creative-usernames Spotify
> shared about some security issues] with Unicode usernames.

New description:

 WordPress currently transforms usernames and potential usernames into a
 restricted set of ASCII characters. It attempts to remove HTML,
 diacritics, and transform other characters to ASCII equivalents, stripping
 away anything that remains.

 This prevents storing usernames that correspond to someone’s name or
 chosen identify, if that name falls outside the restricted range. For
 example, the username `北斎` is unusable because `sanitize_user( '北斎',
 true )` returns the empty string.

 WordPress should relax its restrictions on usernames to be more inclusive
 and permit locale-specific sites and users to express themselves as they
 are, not having to make concessions for latin-based technology.

 == Complications

 - Not all restrictions should be removed, but it would be important to
 double-down on the original intent of those  filters; notably, to limit
 confusable characters such as non-printable and non-visible characters.
 Unicode defines considerably more complicated text rules, so an update to
 the system should improve the Unicode compliance surrounding these issues.
 - Given the higher probability of multiple representations for non-ASCII
 usernames, it would be important to normalize all inputs using an appriate
 algorithm, such as NKFD.
 - Existing code and plugins are going to assume ASCII-only usernames and
 unlocking more complete naming should not introduce any more backwards
 compatibility breaks than are absolutely necessary.
 - Some installations will be running on non-UTF-8 database tables which
 cannot represent all possible Unicode-based usernames. For these
 installations, it must be clear that extended username support is
 unavailable.

 == Help

 Unicode provides ample guidance here which can help WordPress to:
  - avoid known security issues
  - implement these behaviors in harmony with expectations from other
 software
  - how to best display these characters in interfaces

 == Warnings

  - [https://unicode.org/faq/security Unicode Security FAQ] and
 [https://www.unicode.org/reports/tr36/tr36-7.html Security Considerations
 Technical Report]
  - [https://engineering.atspotify.com/2013/6/creative-usernames Spotify
 shared about some security issues] with Unicode usernames.

 == Related

 - #62948 Non-ASCII slugs need comprehensive transformation and inspection
 as well.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64996#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform