- From: Addison Phillips via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Jun 2018 20:52:24 +0000
- To: public-webauthn@w3.org
Display issues are complicated at best. I don't know that there is a good pointer per-se. As far as I know, no one has solved the problem of *both* general readability of arbitrary Unicode text *and* distinct display of strings that are encoded distinctly. That's certainly true across a myriad of platforms, display technologies, fonts, etc. Bidi isolation is one thing that is probably good to cite, since that helps solve the problem of using bidi characters/controls to cause text to "[swap places](https://www.w3.org/International/articles/inline-bidi-markup/uba-basics#isolation)" in an abusive way. WRT overall avoidance of spoofing, it boils down to: some characters/character sequences look like other characters/character sequences. Some applications try to make some of these differences visible (notably changing the background color or other decoration in the address bar when an IDNA address is shown), but none of these completely remove the possibility of confusables being used. As noted previously, PRECIS doesn't fix this. On some level, the byte- or code-point-level comparison of strings boils down to the code units used for interchange. PRECIS and Charmod are both about the need for namespaces to have reasonable, reliable, consistent rules for doing this--mainly to assist users with the problem of inputting the values in separate places at separate times and getting the match one expects. One last observation: W3C I18N used to promote NFC and the idea of really strict rules for namespaces and such. In practice, over 25 years or so, this hasn't turned out to be the problem we thought it would be. Permissive name spaces seem to work the majority of the time: they perform better, are simpler, don't disadvantage scripts/languages that need unusual encoding features, and don't try to solve problems no one is asking about--the main caveat being that you can't always see that the strings do/don't match (which, as noted, they didn't solve anyway). In namespaces, it often seems that it works better to put the health warning of "since you can't see the underlying bytes, be sure that they do match" and do little to "assist" users by mutating their input than to try to create complex rules that force the issue (or arcane display hoops to jump through). YMMV. -- GitHub Notification of comment by aphillips Please view or discuss this issue at https://github.com/w3c/webauthn/pull/951#issuecomment-400458246 using your GitHub account
Received on Tuesday, 26 June 2018 20:52:28 UTC