Comment by userbinator
7 hours ago
after Apple removed a character from its Czech keyboard
I wonder what the thought process (or perhaps lack thereof) at Apple was. Did no one of the likely-somewhat-large team who did that think "wait, this could lock out our users who may have used that character"?
In the immortal words of Linus Torvalds: "WE DO NOT BREAK USERSPACE!"
Now one of the ways in might be those companies who claim to be able to break iPhone security for law enforcement and the like, but I'm not sure if they'd be willing to do it (at any price) unless you could somehow trick them into thinking you had some "interesting" data on there...
It’s wild that "verify existing passcodes remain inputtable" isn't the absolute first item on the QA checklist for any keyboard layout change. The Czech layout isn't exactly an obscure edge case.
The USB keyboard suggestion mentioned in the other comments likely won't work either because of USB Restricted Mode. After an hour of being locked, iOS disables data over the Lightning/USB-C port until the device is unlocked. It’s a perfect, recursive failure: you can't unlock the phone because the character is missing, and you can't plug in a hardware keyboard because the phone is locked.
Treating the passcode keyboard as a transient UI element that can be "cleaned up" rather than a hard security dependency is a massive architectural oversight. If the OS allows a character to be used in a passcode, that glyph needs to be permanently accessible in a fallback mode, no matter what the localization team decides to prune.
> The Czech layout isn't exactly an obscure edge case.
From what I understand, the problem wasn't with typing characters actually used in the Czech language such as á, ř or ů. The problem was with typing the ˇ character by itself, which is normally encoded in Unicode as U+02C7 (CARON), but there also is a combining version (U+030C, COMBINING CARON), which is what gets printed if there is no precomposed character (e.g. š is both U+0161 and U+0073 U+030C). There is a thing called Unicode normalization that makes "identically looking" strings actually use the same codes, so maybe it was that thing that changed a bit (maybe even somewhere else and not in the lockscreen/keyboard logic), or they could have just removed the ability to type ˇ by itself altogether since it's not something actually used in any language or writing style and most often comes up as a result of a typo.
If I'd get a dollar for every annoying bug that Apple misses due to being hopelessly Bay Area brained, I'd probably get at least a free official Apple cleaning cloth every couple of years.
This is a good comment
I agree with you and don't really get what Apple gets from removing a valid Czech character, but how would you test if all existing passcodes remain inputable without knowing the passcodes of all iPhone users?
The one way to do this that I could see is to include both the new keyboard and the old one and if someone fails to unlock with the new one auto report that to Apple (not the code, just that the unlock failed and that the keyboard might be the problem), then auto revert to the old keyboard on the next unlock attempt...
You can guarantee it by not removing characters from the keyboard used for password entry. If the set of characters available before the change is a subset of or equal to the set after the change, then all existing passwords must still be enterable.
If allowing that character in the first place was a mistake, then Apple has pushed the consequences of their mistake onto the users instead of owning the mistake and keeping that character available forever on existing devices.
> how would you test if all existing passcodes remain inputable without knowing the passcodes of all iPhone users?
You basically can't ever remove an available character.
That includes emojis if they're allowed in IOS passwords.
7 replies →
You assume the worst case: every character that could ever have been entered is in use.
1 reply →
Phased roll-out. You first introduce a version that still accepts all extant inputs but will actively warn that there are characters that will be removed in a future release.
Then you wait. Then you roll out a version where the new functionality is flipped on by default, but where you still allow to explicitly toggle to the old one. Then you wait some more.
And then - only then - you roll out a release where the old functionality has been removed entirely.
5 replies →
If passwords are Unicode then you need a way to input arbitrary Unicode (e.g. a Character Map dialog).
There is a list of valid characters accepted for a passcode. That list was created, the characters debated, and a consensus reached by Apple engineers (I hope, for all our sakes. I don't want to imagine a world where this bare minimum level of engineering diligence wasn't done by a trillion dollar company)
Just have an automated keyboard test for every new release to ensure those characters aren't broken.
1 reply →
It's literally a matter of an automated test that sets a password using every character on every possible keyboard type, then tries to type that password in on the lock screen. There's not even that many keyboards, that test would take what, an hour to run?
2 replies →
A very simple alternative also would have to have provided a way to do a rollback to previous version until first complete boot after update at least. Would probably also cover for other kinds of problems.
People have had the same issue with broken screens (and not just on iPhone).
Your touch screen stops working. You want to dump the data by plugging it into the computer. To do that, you need to click "approve" or "trust" or whatever on a touch screen. A touch screen which.... stopped working.
We have definitely moved much, much too far towards security on the security vs. convenience tradeoff. We need a "I am not a human rights activist, I neither understand nor need all of this stuff" mode.
In my book this is proof that Apple has lost control over QA, which is a massive failure, not just some minor hiccup. This has degraded the iPhone from an important tool you rely on to a toy you can afford to lose any second. Everyone needs to draw their own conclusions from that.
AI slop bot go away
The team is even larger if you consider that any past member counts - you only need to think about it once and add a test
Honestly of the big companies sometimes I feel like Apple is the worse offender in i18n questions
Sure they have most of their stuff translated but some rough edges make me feel they do the bare minimum:
- Their ISO keyboard sucks. Sure their overall quality makes it good but of the major brands their Enter key is the most flimsy attempt at it
- Some long standing bugs https://discussions.apple.com/thread/250299816?sortBy=rank (which I had the impressions they were made worse in localized version or at least if you used a non American date format)
- General weirdness with translation missing sometimes
I remember switching to English, decades ago, after running into misaligned/cut-off localized text in the UI. I'm still using English to this day.
And from what I've seen, Apple's always supported fewer languages and input methods than Google/Microsoft, like they simply cant be bothered.
> Did no one of the likely-somewhat-large team who did that think "wait, this could lock out our users who may have used that character"?
I don't think we can assume the team is large.
While user base is well into billions. There are bound to be niche exceptions like this.
Many people here are discussing a phase out. Just add an obscure key combo that won’t be triggered via normal use, and leave it there forever.