-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Display name content rules? #593
Comments
What kind of content restrictions do you recommend? Is it to restrict to certain text encoding such as UTF-16, etc.? |
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. |
For some additional context, the current description of the
|
@jcjones will review this with engineers at Mozilla. There doesn't seem to be a need to add any restrictions. |
After consulting with a Mozilla wizard (@zbraniecki), the current definition of these (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:
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. |
You could also do |
Although https://tools.ietf.org/html/rfc8266 might be overkill here, it addresses some of the core issues and challenges with display names... |
7 March 2018 WG call: @equalsJeffH agrees with @stpeter. @jcjones to write a PR that references RFC 8266's nickname profile for the relevant |
The RP provides 'PublicKeyCredentialUserEntity/displayName' and 'PublicKeyCredentialEntity/name', both of which are intended for display by User Agent. As DOMString objects, these could be manipulated by a malicious RP to try and confuse the user about what is being displayed, so User Agents should be careful in how they display these fields. This PR points to RFC 8266 for its guidance on showing those fields. This is guidance that browser vendors already follow for other specifications, so it's nothing new -- it merely codifies what should be.
Ok, it seems there are two facets to this issue:
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? |
this was addressed by PR #951 |
…#951) given #951 (comment) where we decided on the 11-Jul webauthn call to go ahead and merge this PR as-is, and @stpeter's nominal ok of the presentation warning #951 (comment), I'm merging this. if anyone feels there are problems with it, please submit specific new issues. * employ PRECIS RFC8264 et al for 'name'-ish domstring values * address emlun's review comment * remove reference to 'preparation', 'enforcement' includes it * re-do section references per selfissued * client-side normativity to SHOULD * add presentation admonition wrt name-ish strings
… 'name'-ish domstring values (#951)
… 'name'-ish domstring values (#951)
[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?
The text was updated successfully, but these errors were encountered: