global password strategies

[Harriet Riddle]

> One problem is indeed that some smart keyboards will alter text
> themselves.  I had a keyboard that enabled one to enter much NFC Latin
> text.  I switched keyboard interpreter (from corrected fcitx to
> ibus) when 32-bit operating systems were discontinued, and now for the
> same M17N keyboard definition it generates NFD at least some of the
> time.

Of course, then you come to CJK input methods.  My favourite go-to 
example is (depending on both vendor and locale) that some will generate 
U+301C 〜 while others will generate U+FF5E ～ for what is supposed to be 
the same character.  Normalisation doesn't help here: U+FF5E NFKCs to 
U+007E, while U+301C NFKCs to itself.

Another example is U+2212 − and U+FF0D －, which was causing enough 
problems that they had to be explicitly written into W3C/WHATWG 
standards as converting to the same JIS, even though the WHATWG Encoding 
Standard doesn't normally include one-way mappings like that, since 
Apple Japanese IMEs were entering U+2212 and Microsoft ones were 
entering U+FF0D.  Although there are multiple other examples where the 
two vendors map the same Shift JIS character to different Unicode, and 
this also affects codepoint choice by their respective IMEs, apparently 
this particular example was causing problems with systems expecting 
Shift JIS postal codes or something like that.  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28661

Again, normalisation doesn't help there, since U+FF0D NFKCs to U+002D 
and U+2212 NFKCs to itself.  These inter-vendor issues are not unique to 
Japanese either.

Suffice it to say, you don't want your password to fail to match because 
you typed it on a different operating system.

-- Har.