If a user picks a presentation layer that displays å from noncomparable alphabets, but has them look identical - that's a choice they can and should be able to make. I think it's dumb but I'm not here to hold anyones hand.
It's the users choice whether 43616665CC81 == 436166C3A9, same for Café == Café. But they are distinct and separate choices. Text and bytes are separate things.
We accept that case sensitivity exists and whether a user/business/program treats them as identical is and should always be their choice to make.
There is abstract complexity in the problem, but the context in which text is used solves most of that.
If I have handwritten notes and I make a copy but write the second one in cursive and ask someone if they say the same thing - the correct answer isn't "we need to create a standard to normalize the presentation of text" - it's "be more precise in what you are asking".
Whether Café == Café depends on if it's written on a road sign, or a network packet with a fixed byte size.
Unprintable characters are not text and should not be stored in text fields. Neither are control characters, and as far as I'm concerned should not be included in any text encoding standard. Formatting and terminal processing should never be stored in-band, that's an obvious design flaw that should be corrected.
We already deal with ambiguity within ASCII re I vs l vs 1. Some fonts render those identically - Using those fonts in a passport is bad design. Saying we should avoid having to compare those characters at all because some people/systems might confuse them is misguided.
This isn't a true rebuttal of what you were saying but some of my next thoughts.
>This isn't a true rebuttal of what you were saying but some of my next thoughts.
I feel it's a rebuttal enough, and it provides a clear answer to the parent's question:
· is Café == Café ?
· C + a + f + e + '́ ' vs C + a + f + é
· Utf8: 43616665CC81 vs 436166C3A9
When we're talking about username/password fields, what we're really talking about keystrokes, or the input sequences that the user makes to identify themselves.
Android lock screen patterns are passwords, and the answer is blatantly clear there: the same shape drawn in a different way is a different pattern.
The context here isn't "are these two strings saying the same text".
It's "is the person typing this text who they say they are", boiled down to "can they repeat the input sequence provided at registration".
So, we get the answers:
* C + a + f + e + '́ ' != C + a + f + é if either can be intentionally produced by the user at the log-in screen (i.e., if these Unicode sequences can be produced by different keystroke sequences, and the user knows which output they're producing)
* C + a + f + e + '́ ' == C + a + f + é if either can be obtained as a result of the same keystroke sequence (i.e., if virtual/physical keyboard + OS combinations may represent the same keystroke sequence with different character sequences provided to the program).
* If both are true, neither should be allowed
The case of not all input devices having the keys requisite for reproducing the input sequence would boil down to either deciding based on context, or asking the user if they are sure they want to limit themselves to the particular hardware/software combinations to log into the service.
For example, a username like БДЖІЛКА is perfectly fine if you only ever want to log into the service from devices where a Ukrainian keyboard is available.
Which would be an appropriate assumption for e.g. Ukrainian government systems, where Ukrainian language support is required by law, but not in an general context (what if user travels outside Ukraine, and wants to log in from a device they don't own and can't enable Ukrainian input on?).
One can't hit the "Ж" key if their keyboard lacks it.
Same goes for the concern raised in the article:
>I see and type my username hundreds times a day, people use it to address me in written and spoken conversations with it, etc.
Good. That means that @БДЖІЛКА is only appropriate where everyone can be assumed to be able to write and speak Ukrainian, which doesn't even hold universally true in Ukraine, unless it's a government office.
That's to say, most people reading this comment won't be able to address me as @БДЖІЛКА in neither a spoken conversation, nor a written one (copy-pasting is not writing).
At the same time, if I can type "БДЖІЛКА", it should be my choice to have that as a username/log-in name, since only being able to log in from devices with a Ukrainian keyboard would be a security feature for me. I know that I will have that on my devices, but an adversary may not.
Similarly, a log-in name like @СІРНІК should be acceptable if I wanted it.
Note that it's not the same as @CIPHIK - the former uses Ukrainian character set. @СІРНІК != @CIPHIK for authentication purposes because I typed in different input sequences to produces these glyphs on the screen.
This is not a Unicode issue either; ASCII with codepages for internationalization had the same problem. Homoglyphs aren't limited to accents or complex Unicode sequences.
With Unicode, СІРНІК is not a problematic username - there's only one way to type that particular byte sequence in. Before Unicode, it was, because the letters were encoded as different bytes in KOI-8 (Unix) vs. Windows-1251 character sets, and the user didn't necessarily have a choice about which one is being used to record their input.
The problem wasn't limited to log-in screens, of course; it resulted in hilariously unreadable words which have since been enshrined in memes, like "бНОПНЯ" for "Вопрос" ("question", a common first word in a chat message asking about how to make text readable).
See, бНОПНЯ (KOI-8) == Вопрос (Windows-1251); same bytes. Whether to allow that as a log-in or password (e.g. on a Linux machine) depended on whether you wanted to allow the user to log in from Windows devices too.
Obviously, for local accounts on Windows 95 machines, it was not an issue, as Windows encoding would be the only one available on a Windows log-in screen. The context gives all the answers.
All of this directly follows from the "not a true rebuttal" you typed, and I frankly don't see what else there is to say on the matter, or how else to say what you said to get that point across.
It's the users choice whether 43616665CC81 == 436166C3A9, same for Café == Café. But they are distinct and separate choices. Text and bytes are separate things.
We accept that case sensitivity exists and whether a user/business/program treats them as identical is and should always be their choice to make.
There is abstract complexity in the problem, but the context in which text is used solves most of that.
If I have handwritten notes and I make a copy but write the second one in cursive and ask someone if they say the same thing - the correct answer isn't "we need to create a standard to normalize the presentation of text" - it's "be more precise in what you are asking".
Whether Café == Café depends on if it's written on a road sign, or a network packet with a fixed byte size.
Unprintable characters are not text and should not be stored in text fields. Neither are control characters, and as far as I'm concerned should not be included in any text encoding standard. Formatting and terminal processing should never be stored in-band, that's an obvious design flaw that should be corrected.
We already deal with ambiguity within ASCII re I vs l vs 1. Some fonts render those identically - Using those fonts in a passport is bad design. Saying we should avoid having to compare those characters at all because some people/systems might confuse them is misguided.
This isn't a true rebuttal of what you were saying but some of my next thoughts.