As a non-English speaker I can really relate to this. I think the real mistake was Apple allowing to enter a non-ASCII password in the first place. E.g. on macOS the password fields have been locked to English character set, and I'm not sure why it changed on iOS.
Regardless, why should a Vietnamese person be forced to restrict their password to ASCII? If you want to sell your devices in a country, the least you can do is to adopt to the local market. I get that Western cultural dominance makes this hard for some, but I think it should be the bare minimum.
It makes about as much sense to insist that everyone across the world use only US ASCII, as it makes to force everyone in the world to use only Cyrillic UTF-8 symbols. I.e. no sense at all.
I would also argue the counterpoint : why are the local markets adopting things that are barely functional to them?
As a comparison, if all Vietnamese people had three feet and three arms, would they all be walking around with two left and a single right Nike shoe while wearing a Champion shirt with an extra arm thrust through the sleeve?
At what point do customers and users realize they are responsible for giving consent?
You can use emojis as passwords, do you think that's a good idea? They work now, there's a good chance that they won't be the same forever. See what happened to the family emojis
I think there's a distinction to be made between 'is it a good idea for someone informed enough to know how these things go in the real world?' i.e. the HN audience and 'should this be a real worry in a sane world?' to which I say no, it shouldn't be a worry that if I was allowed to enter a password today I may not be able to tomorrow.
That's just excuses for moronic decisions of trillion dollar companies.
Passwords are more secure if they are higher entropy, so it makes sense to support a larger variety of characters, Czech or emoji.
It seems paramount that the OS should not allow password input of any characters which it theater takes away. At the very minimum if this is absolutely necessary to make this breaking change, the user should be warned several times that a character in the password is no longer valid and maybe even prevent the OS from upgrading before the password is changed to a forward-compatible one.
In my password, I have the Collectivity of Saint Martin flag emoji and United States Minor Outlying Islands flag emoji next to the French flag emoji and US flag emoji. For good measure, also the flag of Chad next to the flag of Romania. I am sure it's not going to cause any issues.
Well, alphabets change (especially emojis), rules change, etc, so keeping a single subset of stable and known characters is unlikely to be a bad idea :)
If you remember what was the encodings situation before UTF-8 became the norm... Let's say it was really ugly. E.g. there were at least two popular encodings for Russian Cyrillic letters — CP1251 and KOI8-R, and it was _very_ common for applications getting it wrong. Restricting things like passwords (and ideally even file names) to ASCII this was a practical necessity rather than an inconvenience.
Unicode was introduced to solve that very problem, and it largely does.
In the olden times, even ASCII wasn’t necessarily a safe bet, as many countries used their own slight variation of ASCII. For example, Japan had the Yen sign in place of the backslash. In a fictional ASCII world, Apple could have decided to remove the Yen key from the Japanese lockscreen keyboard.
> Unicode was introduced to solve that very problem, and it largely does.
What? Unicode doesn't address the problem at all. Your emoji password will look completely different depending on the encoding you use. We have multiple popular encodings right now... but instead of software that lets us specify which encoding we want to use to interpret a document, we have software that intentionally prohibits us from doing that because it's supposed to be a security risk.
UTF-8 wasn't introduced to solve the problem of there being multiple encodings of any given text, either. It was introduced to be another encoding.
> In a fictional ASCII world, Apple could have decided to remove the Yen key from the Japanese lockscreen keyboard.
That would have had no effect other than momentary user confusion. In that world, someone with a yen sign in their password would, after the keyboard update, have a backslash in their password, because their password never changed. Only the label changed.
In this world, though, it's still true that the password never changed. But what did change was that Apple implemented specific logic to prevent people from entering that password. The label didn't matter.
(And the article is ambiguous over whether the appearance of the keyboard changed or not. It's not ambiguous over whether the behavior of the keyboard changed -- it didn't:
>> Post-update, when entering the passcode, the keyboard now displays an identical accent mark in the háček's place, a feature Byrne described as "pointless; they're encoded the same."
There may or may not have been a cosmetic change to the keyboard, but there certainly was a change to the behavior of the password field.)
Unicode is the code points. Of course you have to normalize on one encoding for password hashing (and UTF-8 is the canonical choice for that, because interfaces to hash implementations are byte-based), but that’s not an issue of end-user input. The goal of Unicode was to be able to roundtrip the existing encodings through it, and it achieved that goal.
> That would have had no effect other than momentary user confusion. In that world, someone with a yen sign in their password would, after the keyboard update, have a backslash in their password, because their password never changed. Only the label changed.
No. The analogon to TFA would be that the old keyboard would have a Yen key and no backslash key, and the new keyboard would have no Yen key and still no backslash key. The point is that the Yen key would be removed because its character code is not part of the shared common subset of ASCII. ASCII doesn’t imply that you have a keyboard capable of entering all 128 codes. Just like Unicode doesn’t imply that your keyboard allows you to input arbitrary code points.
> No. The analogon to TFA would be that the old keyboard would have a Yen key and no backslash key, and the new keyboard would have no Yen key and still no backslash key. The point is that the Yen key would be removed because its character code is not part of the shared common subset of ASCII. ASCII doesn’t imply that you have a keyboard capable of entering all 128 codes.
Are you sure you read the article? The key is still there.
> Of course you have to normalize on one encoding for password hashing (and UTF-8 is the canonical choice for that, because interfaces to hash implementations are byte-based)
This is pure gibberish. All encodings produce bytes. UTF-8 has no relationship to the concept that isn't shared by every other encoding.
"Code points" isn't enough. Characters like ö can be represented in de-composed (¨+o) or composed (ö) form. Even Hangul supports decomposition.
Unicode defines rules you can implement to normalize these, but they change between Unicode versions and you can end up with a password that works in one Unicode version and not another.
Well yes, but you can process all passwords as UTF-8, as most of strings are in mac/iOS anyways, to avoid these problems. Then just don’t break an established standard like the keyboard layout. Is that too much to ask for in 2026?
> As a non-English speaker I can really relate to this.I think the real mistake was Apple allowing to enter a non-ASCII password in the first place.
As a non-English speaker (Czech, actually), it is clear to me to not use non-ASCII characters in passwords, or generally not use characters that are at different position on default English keyboard and locally used keyboards, i.e. use only ASCII alphanumeric chars except 'Y' and 'Z'.
As keyboard setting is per-user setting, keyboard may be different on login screen than on regular desktop (and once-login password prompts).
Also, most devices nowadays ARE single user. And most (all?) OSes allow you to use alternative keyboards at the user-selection screen.
Also, all orgs recommend special characters in passwords. Czech keyboards default to accented letters on the top row instead of numbers, so why wouldn't your average Czech use those?
