Display name content rules?

[r12a]

[This review was done against https://www.w3.org/TR/2016/WD-webauthn-20160531/#iface-account, and the comment was raised by Addison Phillips. The i18n WG agreed to forward as a WG comment.]

There are no rules (other than that they are DOMStrings) associated with display names. Should there be any content restrictions?

[AngeloKai]

What kind of content restrictions do you recommend? Is it to restrict to certain text encoding such as UTF-16, etc.?

[AngeloKai]

All browsers have some form of policy regarding how they deal with international DOMString. If we agree on something, we can all take a bug fix to address. Assigning the issue to PR milestone.

@equalsJeffH @nadalin @YubicoDemo for tracking.

[emlun]

For some additional context, the current description of the user.displayName field is:

displayName, of type DOMString A human-friendly name for the user account, intended only for display. For example, "Alex P. Müller" or "田中 倫". The Relying Party SHOULD let the user choose this, and SHOULD NOT restrict the choice more than necessary.

[selfissued]

@jcjones will review this with engineers at Mozilla. There doesn't seem to be a need to add any restrictions.

[jcjones]

After consulting with a Mozilla wizard (@zbraniecki), the current definition of these displayName fields will prohibit browsers from including them in UI that does not have clear boundaries. E.g., not in notification or permission boxes. E.g., we could include the displayNames in a management interface where there are grids/borders/graphical elements, but not run it together into a compressed-space like a prompt.

(Note: Firefox is not including anything but the origin in any of its prompts in its first release for these reasons.)

@zbraniecki suggests that if we want to let browsers use this information for prompts, that we should write / refer to some guidance on how to present the strings, given that the attacker can do three major things with a DOMString:

play with position and directionality (so the string may appear on the far right of the field rather than left, or in the middle), make things invisible within the string or confusing (emojis), or may the string contain characters that look like other characters.

My poor synopsis of some sample guidance would be advice to always use UI elements to provide a clear boundary around these strings, and not allow overflow into other elements, etc.

[zbraniecki]

You could also do simpleDisplayName (ASCII, min 3 characters long?) and fullDisplayName (unicode, any non-empty string) and provide separate guidelines for those and suggest that if only one is provided the other is casted onto it (with stripping in case of unicode->ascii)

[stpeter]

Although https://tools.ietf.org/html/rfc8266 might be overkill here, it addresses some of the core issues and challenges with display names...

[jcjones]

7 March 2018 WG call: @equalsJeffH agrees with @stpeter. @jcjones to write a PR that references RFC 8266's nickname profile for the relevant DOMStrings.

[equalsJeffH]

Ok, it seems there are two facets to this issue:

1. corralling the unicode content of the "name"-ish domstrings
2. providing implementer guidance regarding how to display/present these string values in order to mitigate effects of possibly malicious string content.

PR #951 is an attempt to address (1) and is an alternative to pr #878.

I have done some modest searching around WHATWG and W3C specs regarding how one might specify guidance per @jcjones's suggestion above of "[advise] to always use UI elements to provide a clear boundary around these strings, and not allow overflow into other elements, etc...", but have been unable to find anything useful -- does anyone have any clues?

[equalsJeffH]

this was addressed by PR #951