> During in-house testing, which involved taking an iPhone 16 from iOS 18.5 to iOS 26.4.1, The Register found that Apple has kept the háček in the Czech keyboard, but removed the ability to use it in a custom alphanumeric passcode. The OS will not allow users to input the háček as a character. The key's animation triggers, as does the keyboard's key-tap sound, but the character is not entered into the string.
Sounds more like an actual bug than a decision to change the keyboard layout, if this happens only in the passcode screen?
I think the biggest lesson here is to back up. The reason for losing access to the phone is amazingly dumb but it could have fallen down the stairs for basically the same effect.
And do your could backups cross-provider. You never know what the "big players" are going to pull, and your lifetime customer value is less than the cost of a single support call.
This is exactly the reason why I keep all my shit on an SD card despite Google deliberately making the external storage experience as painful as possible: slow access, broken writes, failed unmounts, no filesystem repair. Literally every time I restart my phone I need to put the card to my PC and repair the filesystem. Also, same card works extremely well when plugged into PC via random cheap USB card reader.
On PCs you still have Linux that resists enshittification and you can pick your own hardware, but it's a really sad state of affairs that there is literally no meaningful mobile system that isn't actively hostile to the user.
I just have a cheap second hand PC with a couple of good drives running LAN only Immich and a few other backup tools. This, in parallel to cloud backup, makes the setup both mobile and reasonably fault tolerant.
I'm quite wary of using SD card for backup. Too easy for me to lose.
The thing that bothers me about Android is the gimped file manager.
You wan't to access some files off your network using smb? Here install this third party tool and don't forget to give it full read/write access to your device.
Your case is obviously not this, but SD cards aren't a great primary drive, as Raspberry Pi power users sometimes discover. Their durability can be unpredictably spotty.
I’m all for a system that allows you to wipe the device to do a downgrade or upgrade (just like any PC with an unset bios password allows) but the idea that it’s a good design for someone without my OS password to be able to downgrade my OS or perform any operation on my OS is insane.
What’s even the point of setting a password if anyone can manipulate the system without entering it in?
The entire iPhone OS is on an encrypted volume and that is the right design choice. Not having the password means no access.
There is no general purpose encrypted volume operating system that allows unauthenticated users to perform OS manipulation. If you encrypt your FreeBSD, Linux, or Windows volume, the result is the same: no password, no access.
Your choice is to enter the correct password or wipe the disk.
The fact that Apple doesn’t allow you to set up a system without full disk encryption is not a user freedom issue, it’s a very sensible design choice especially for a device sold primarily to non-technical consumers who don’t understand the security implications of leaving the volume unencrypted.
The issue here isn’t that iOS security is designed wrong, the issue is that Apple broke basic password entry with an update.
Shame on Apple for having such lazy software development practices when it comes to implementing updates like this.
So don’t buy an iPhone if you don’t care about the security of your device and personal information. That would introduce a massive security hole that would negatively affect far more users than it would help.
I doubt that. The group of people you're talking about are those who have their phone maliciously stolen by people who are actively working to hack/exploit their way into the devices and then actively exploit the information stored on them. That is a utterly negligible percent of users, or even of users who have their phone stolen. The overwhelming majority of thieves of intent move the devices onto professional orgs that wipe them, jailbreak them, package them, and then ship them on to other entities that resell them.
The percent that might want to choose a different-than-latest version of OS would also of course be quite small, but I suspect it would be orders of magnitude larger than the other group we're speaking of just because that group of people is going to be so absurdly tiny.
In this world stolen iPhones are mostly worthless because they can’t easily be wiped without the password.
In your world, they could be.
I imagine iPhone thefts would go way up. They’re worth $1000 and we just carry them everywhere - if they were easily resellble it would be a very obvious quick-money theft opportunity.
iPhones are currently the primary target of thieves by an overwhelmingly wide margin. There are many ways to wipe them and its an industry in its own right. One of the most common, as always, is simple social engineering. They contact the victim posing as Apple, convince them to reveal their credentials in this way or that, wipe the device and away they go. If that fails they're stripped down and sold for parts, which is also reasonably lucrative.
I don't know for certain why thieves are generally not typically interested in abusing user data, but I'd imagine it's because the penalties if caught would go way up. That'd go from what is generally just petty theft, which carries a slap on the wrist, to wire fraud and a whole slew of other charges, which can leave people spending most of the rest of their life in prison.
Because a quick search for UK statistic shows that even though iPhones are minority of phones over here they are the overwhelmingly majority of all phone theft:
"In terms of smartphone models, the data also indicates who might be most at risk. Looking at the entirety of the UK, 68.6% of stolen phones are iPhones."
Not allowing downgrades is the biggest contributor to smartphones becoming e-waste.
Apple should be forced to do this by law, but only after they discontinue software support. If they're willing to continue making small, incremental patches when necessary (such as to fix this obvious bug) then it's fine that they can still block downgrades. But at EOL? They should be legally required to allow old software to be installed.
This also impacts software compatibility - any 64-bit device that is now EOL that got updated to iOS 11 or newer is forever barred from running 32-bit apps just because people are worried that someone might take that old device and downgrade it as an attack?
The average person should always stay updated to the latest version for security reasons. But the power users should be able to choose which version they run, at least on devices that aren't currently supported at all.
Daily reminder that the first two iPhones and the first iPod touch had zero firmware signing, and you could freely install any supported version at any time, and can still do so today. That being the case has probably harmed 0.00001% of people at most
I have heard many replace their phones due to dropping them and becoming unusable. But everyone uses a case now and the build quality is generally better that one mishap does trash the phone. Most people I know getting new phones now did so bc their old phone "got too slow to be usable." I believe that's a matter of new OS versions really are much heavier. Both my last 2 phones I had upgraded bc I went one version too far and had a nearly bricked phone.
> Steve Jobs would be rolling in his grave if he could see the software quality of the products that Apple releases today.
lol, nah he wouldn't. He would of upgraded his coffin to plush and got a big screen to watch the money roll in.
I recommend reading up on his 80/90's antics. All he cared about was money and that the world was crafted by him.
He was widely known for intense bullying, lacking empathy, and ruthless manipulation, combined with a "productive narcissism" that fueled his obsessive drive for perfection.
> I recommend reading up on his 80/90's antics. All he cared about was money
Incorrect. Read the David Pogue Apple book. For example, after the iMac was released, the Apple board of directors offered Jobs a million shares and six million options if he switched from interim to permanent CEO. Jobs continued to refuse. “This is not about money. I have more money than I’ve ever wanted in my life.”
Most of Steve's wealth came from Pixar, which he ultimately sold to Disney, rather than from Apple.
Yes, and "his obsessive drive for perfection" as you put it is what would make him "rolling in his grave if he could see the software quality of the products that Apple releases today" as the parent put it.
I am 100% sure that Steve Jobs could have shipped a broken Czech keyboard if that was in pursuit of some random abstract like purity or minimalism. "iOS keyboard has too many keys. Reduce keys make them larger. People should not use these obscure symbols anyway". (extrapolated from a couple of biographies and a couple of books on 1980s Apple I read, this is very consistent with his character).
As for iOS 26, no reasonable person would have let it ship. From one source (John Gruber -> "Bad Dye Job") the previous head of Apple's UI design team who lead the UI team was just not a UX designer, he was just a visual designer or something. I think it shows.
As much of a snob that Jobs was it's nonsensical to say that he would've knowingly insisted on changes that locked users out from their devices. That's just nonsense. At the very least there would've been a prompt to change the password phrase or some such in upgrade. And if it did happen as an oversight, it would've been patched on the first report and some heads would've rolled.
But that's the difference. Jobs might've done something like this for a reason. That's not what happened here. He probably wouldn't have tolerated it as a bug.
Jobs was a perfectionist and a minimalist. Part of minimalism is that sometimes you delete marginal features (arrow keys) that you still end up wanting back.
If you never delete too many features, you aren’t deleting enough features.
Doesn't this mean that no matter how securely your phone is locked, Apple (and probably the three-letter agencies) can always unlock it by installing an appropriate update?
Not necessarily. If the secret is protected in the secure element against something only you can provide (physical presence of RFID, password, biometric etc) then it is ok.
BUT you must trust the entire Apple trusted chain to protect you.
> If the secret is protected in the secure element against something only you can provide (physical presence of RFID, password, biometric etc) then it is ok.
But we already established unlocking is not possible, so going with the argument it's implied there is a side-channel. Nothing, but a secret in your brain is something only you can (willingly) provide. Especially not biometric data, which you distribute freely at any moment. RFID can be relayed, see carjacking.
If you can side-step the password, to potentially install malware/backdoor, that's inherently compromising security.
If the data you care about is encrypted with a token locked behind your passcode input, and it's not theoretically brute forceable by being a 4 character numeric only thing, then not easily, no.
Could they produce an update that is bespoke and stops encrypting the next time you unlock, push it to your phone before seizing it, wait for some phone home to tell them it worked, and then grab it?
Perhaps, but the barrier to making Apple do that is much higher than "give us the key you already have", and only works if it's a long planned thing, not a "we got this random phone, unlock it for us".
(It's also something of a mutually-assured destruction scenario - if you ever compel Apple to do that, and it's used in a scenario where it's visibly the case that 'the iPhone was backdoored' is the only way you could have gotten that data, it's game over for people trusting Apple devices to not do that, including in your own organization, even if you somehow found a legal way to compel them to not be permitted to do it for any other organization.)
> Perhaps, but the barrier to making Apple do that is much higher than "give us the key you already have", and only works if it's a long planned thing, not a "we got this random phone, unlock it for us".
The attack situation would be e.g. at the airport security check, where you have to part with your device for a moment. That's a common way for law enforcement and intelligence to get a backdoor onto a device. Happens all the time. You wouldn't be able to attribute it to Apple collaborating with agencies or them using some zero-day exploit. For starters, you likely wouldn't be aware of the attack at all. If you came home to a shut-down phone, would you send your 1000$ device to some security researcher thinking it's conceivably compromised, or just connect it to a charger?
If you can manually install anything on a locked phone, that's increasing the attack surface, significantly. You wouldn't have to get around the individual key to unlock the device, but mess with the code verification process. The latter is an attractive target, since any exploit or leaked/stolen/shared key will be potentially usable on many devices.
Keep in mind that everyone else is usually unaware (by design) of what all the intelligence agencies can do, but I doubt they would help in this scenario even if they could.
On the other hand, if this happens to a far more important person...
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.
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.
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...
Probably the better solution is to include some kind of special lock-screen keyboard that provides some fallback mechanism to input any character. Presumably there are similar edge cases where someone creates a password using one keyboard, then switches keyboard layout, and now can't re-enter it using the active layout...
Indeed. For example, most desktop operating systems have a keybinding for «search for any Unicode symbol by name and input it». That would make sense to have as a fallback button on a virtual keyboard too.
The iOS emoji selector is close in UI/UX already, but the search is restricted to the emoji range of Unicode.
You can but you have to tie it to actual devices and a point in time, not simply a specific OS version. Essentially, all devices that existed before the change must still support the old set of characters and devices produced (or sold or activated) afterwards can support the reduced set.
Or wait until a future OS version that will not support any device currently in existence.
This fails if they let you keep your password migrating between devices, though, so you probably need a version somewhere in the middle that flags it as an issue and flags it as not allowing migration without changing the passphrase.
You need to not just force the update, but also forbid using pre-updated ones in migration, since someone might conceivably have an off-for-many-years device they wake up and want to migrate.
The long tail of stupid edge cases is very long indeed.
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.
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.
Meh, I think you keep the old keyboard and set a password expiry. New passwords use the new keyboard. Or, if you're in a rush to remove the old code, _after_ next login you require password replacement and use the new onscreen keyboard from then.
And perhaps also introduce an upgrade blocker, as the keyboard app notifies the system of a situation that would be unsafe to upgrade to newer releases
That’s dangerous. Apple fooled me with the iOS 26 glass theme, it’ll be a while before I install another major update from them. I know many people still on iOS 18. I doubt many of them will update until either Apple fixes their UI/UX or they upgrade to an Android.
Yes, it really is that simple. They chose that responsibility the moment they allowed those characters. Any deductions done after that need to have a failsafe with the expectation they will break a clueless user's device.
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.
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?
Right, but this test basically means you can't ever remove a character if it was ever present. I was assuming that you still want to remove it (for some reason) and wondering how to safely test the change.
You create two keyboards and use them both and test them separately. Then you create a keyboard update flow. And you test that. Then you make sure you test that the old keyboard shows until the user changes their password.
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.
> 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.
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.
I used to have an emoji password for my Android phone, and had the exact same issue after a reset! It's an odd but pretty terrible failure mode for locking oneself out...
You say locking oneself out, but I decline to consider any situation where a password can be set but not later entered as one where the user bears even a modicum of fault.
I remember a website that silently removed everything but the first 8 characters from the "password" field upon registration but somehow didn't do the same on the login page. It took me several hours and several password resets to actually log in after registration, since for some reason the trimming happened client-side and only when typing the password manually (and I was pasting my password from a password manager).
In a similar vein, I remember encountering a site where the frontend enforced basic complexity requirements ala “use at least one number and one symbol” but the system would silently drop all non-alphanumerics when it saved (presumably in some kind of failed conversion on the way into the backend DB). So setting a password like “foo_bar4!” would become “foobar4” which was surprising. What blew my mind though was when I figured out the stripped password worked to log in, which was how I eventually figured out what was happening, escaped the reset flow, and generated a compliant password.
Since the beginning, iPhone keyboard is wrong in entering a character first, háček second. It has been the other way around on typewriters and then computers for decades. Then some smart guy at apple thought he knows better. One of those never-fixed-bugs.
> It has been the other way around on typewriters and then computers for decades.
On a typewriter, I would expect one to type the latin character, hit backspace, and then add the mark? Or if using a typewriter without the necessary mark, just type the latin characters, then add the marks with a pen to the full sheet.
Wait, really? I thought "dead keys" being diacritics prefixes, not suffixes, was pretty universal. At least that's how it works with ^, ´, and ` on macOS for me.
I assume you can use a physical keyboard on an iPhone like I can on Android via USB? Presumably you could buy a wired Czech keyboard to access the device?
Twice I have had the touchscreen fail on Android devices and been able to get what I needed off them using a USB mouse.
For the same reason, plugging in an external keyboard is also a no-go since freshly updated iPhones are placed in what's known as a Before First Unlock state, which prevents wired accessories from working until the passcode is entered.
This really should be escalated to the point where Apple engineers build a one-off / custom iOS so that this person can unlock their phone and change their passcode. I'm sure this is in the realm of possibilities. It is such a bad look.
That seems very unlikely if only because Apple probably has the equivalent of big flashing nuclear stockpile grade warning signs internally around anything that involves the phrase "one off firmware release", since they have every interest in convincing any nation-state or anyone else that it would be quite difficult and something they have no interest in to do if they ever try to compel them to make one.
Someone on twitter had the idea that he could use the camera to take a picture of the character (or his whole password) and copy/paste it using the built-in ocr feature.
I don't have a text password on my iphone so I don't know whether you can paste into that field.
Majority of California based companies employee English only or English and Spanish speakers possibly with some Indian language as well. This leads to lots of problems when you are bilingual or bilingual in other languages such as German in French. Neither Apple nor Microsoft under this sort of language swapping well. Never mind rarer languages like Czech or Greek.
> Majority of California based companies employee English only or English and Spanish speakers possibly with some Indian language as well [...] Never mind rarer languages like Czech or Greek.
That may be generally true, in this case Apple actually has an engineering team in Czechia that works on biometrics and authentication:
Guess what, they’ll do nothing. If Czech market is small enough for them to fix quotation marks, they’re not fixing Czech keyboard.
OTOH, if an American will whine enough on Internet, they may fix it for him. Maybe some other American should use standard Czech quotes as password to get it fixed also.
I'm a little impressed with Google. Recently the assistant started understanding when I speak Portuguese or when my wife switches to it in a text message. I hadn't had that experience before, the assistants would pick one language and mispronounce the other.
Alexa has an experimental bilingual mode but it's nerfed by its general failure to understand well.
Netflix can't even auto-translate subtitles (in the age of genai where we are close to generating entire movies from scratch). Let alone ever imagine that you'd want to see subtitles in two languages at once.
We run into this issue when watching Korean movies/dramas. My wife prefers Japanese subtitles and I prefer English/German.
I haven’t found a way to enable two subtitles in Firefox (via extensions). So in those cases I usually download a release which contains subtitles in both languages and use a script to extract them via ffmpeg and then combine them into a single srt.
Now the issue is that the lines of the different languages don’t always appear/disappear at the same time. This leads to text jumping up and down. I have tried to mitigate it by injecting white space where only one line is visible, but this again fails when the video player breaks long lines or when the location of the subs change to the top (because there is hard-coded text in the image).
I feel like there must be a better way…
Tangentially related, a relative bought a new Apple laptop a few weeks ago, and I was tasked with setting it up. The computer came pre-equipped with a Czech keyboard (apparently the US models weren't in stock and that relative needed a new computer as soon as possible, so they bought a Czech one).
Since the user doesn't speak Czech, I promptly removed the Czech layout and installed two other layouts, US English and Hebrew, for the languages that the relative uses to type on the computer.
For some reason, login screen just after boot still uses Czech layout, which means Z and Y are swapped and numbers must be typed with Shift (just pressing numbers outputs Czech letters like ěščř). So when booting up the machine (remember that you can't use fingerprint during first unlock), the user must type the password in whatever layout is physically printed on the keys, even though the rest of the OS doesn't even have a mention of that layout. Somehow afterwards the OS "can" see the list of the layouts and lock screen correctly chooses the English US layout.
Alongside of that, for some reason, the key that's supposed to type ` and ~ in the US layout types some nonsense instead (a plus-minus sign and a section sign), whereas the backtick key is for some reason located between left Shift and Z (good luck unlearning years of muscle memory typing ~/Documents in the terminal)
This feels like it's probably a stupid oversight chain like, keyboard layouts are user-specific data, so they're not decrypted before first unlock/set globally because the machine might have multiple users with different keyboard layouts.
Even if it is, why is there no way to change the system-wide settings? All other operating systems that I know either have an explicit button "Apply settings to login screen" or do it automatically (I'm sure 99% of the consumer-level computers sold worldwide never have more than one user on them, moreso with different keyboard layouts).
Evidently you can, though in traditional macOS fashion, you exploit Apple secretly changing the setting for you if you do a magic dance.[1][2]
I've never had a reason to try it, but there's also a remark that 99% of the Macs sold probably don't need to change the system-wide keyboard layout defaults, either...
Even if he did have a Mac with the continuity feature enabled, I suppose the lock-screen won’t accept a paste from the clipboard of a Mac.
(If it did, he could enter the correct passcode in any text editor on his Mac, copy it to the clipboard on the Mac, then paste it into the lock-screen on his iPhone)
This really reads like a modern Ancient-Greek story about inscrutable gods who suddenly decide to complicate your life for some unclear reason and don't respond to any prayers and rituals.
People are afraid of AI, but human organizations can be quite opaque as well.
That said, as a Czech, I wouldn't use any accentuated characters in my passwords. Anything beyond 7-bit ASCII is just asking for trouble.
there was a time when I used a simple "§" in my password. turned out, some Android keyboards don't have the "§". Since then I play it safe with my passwords, using only characters I don't need a specialized keyboard for
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.
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?
The side of my brain that manages organizational changes wonders: how does Apple, a 50 year old company of tens of thousands of engineers and over a trillion USD market cap, manage to keep feature velocity high while not making more of these types of errors?
The bug seems low likelihood but high severity for the few affected users. Other than simply never changing the login keyboard (or any of the keyboard code) or having nearly 100% test coverage, how does a company not accidentally have more of these types of issues?
They do. It’s just that the people using these devices won’t go public with it. I’ve seen so many bizarre bugs in my own experience but I’ve gotten zero articles on them by popular tech journals.
They do. Companies mess things up all the time. But only a fraction of bugs get discovered and then reported, so it appears that their quality is ok.
I have recently discovered several bugs in different products created by different companies. And none has been reported so far in my research despite the products' popularity. I am not surprised, since those bugs require specific combination of conditions to be triggered, which most people have never run into, like in this article.
And I don't even blame them -- the engineers probably could never think of such use cases and don't have those workflows themselves. You'd have to really go out of your way to use obscure workflows to discover them.
Although in this case Apple dropped the ball by locking user out and not providing any alternatives.
> how does Apple, a 50 year old company of tens of thousands of engineers and over a trillion USD market cap, manage to keep feature velocity high while not making more of these types of errors?
They don't. If you're anything other than an extremely casual user of iOS or macOS for a couple of years, you'll encounter things that really make you pull your hair out by shear magnitude of "how on Earth can anyone miss this!?".
Seems like a front-end bug? So just access the API directly, or ask someone who knows how to do that? Plenty of iOS-focused reverse engineers out there.
> For the same reason, plugging in an external keyboard is also a no-go since freshly updated iPhones are placed in what's known as a Before First Unlock state, which prevents wired accessories from working until the passcode is entered.
The user can't even enter their passcode, how do you expect them to perform code execution?
Plugging in a USB keyboard is way higher level than what I'm talking about. You can contact a digital forensics firm, and they'll do it for you. It'd be custom hardware. Cellebrite-type stuff.
It’s an annoying workaround, but could he connect a USB keyboard (via a USB to lightning adapter) with the ability to enter the character? Does the passcode screen accept input from attached keyboards?
> For the same reason, plugging in an external keyboard is also a no-go since freshly updated iPhones are placed in what's known as a Before First Unlock state, which prevents wired accessories from working until the passcode is entered.
I wish we could just have comments removed where it's clear the author didn't even put in the minimum effort of reading the article. It's disrespectful to the rest of us.
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
I feel bad for the guy and all the Apple users constantly sharing stories of being mistreated and abused. Stop giving these companies your money and consent.
I'm basically numb to it at this point though. Every few days we read on this site small permutations of the same story. Sometimes people here get a little extra backchannel support, but that's a token prize for the jester who made a king chuckle.
Then a few more days go by and everyone upvotes a new iWidget to oblivion because it has 0.1 new gigablahs or takes up a milliblah less of some bullshit nobody was asking for.
All while we collectively virtue signal that people are spending too much time and relying on technology too much.
Well, it's almost Monday let's see what new bullshit convinces everyone to keep getting fucked and pay for the privilege.
> I feel bad for the guy and all the Apple users constantly sharing stories of being mistreated and abused. Stop giving these companies your money and consent.
Here's a challenge: walk into a store and attempt to buy a smartphone that is not iPhone or Android.
This is the situation that consumers face. Some alternatives exist, but most consumers are completely unaware of them, because the alternatives have no advertising budget or retail presence.
I think it's quite similar to the political duopoly. Third parties exist, but they have no advertising budget, and moreover, in a Catch-22 situation, they get little or no news coverage, precisely because they have no advertising budget, and thus the news media considers them "not viable." That's a self-fulfilling prophesy. Actually the same situation exists in tech: Apple and Google get huge amounts of free news coverage in addition to their paid advertising. The media appears to feel no obligation to help people escape from duopolies; guess who pays for their advertising...
Yes, the phone market is bad. But, you know you don't have to do everything in a phone, right?
Want to take pictures? Use a camera. If it somehow auto updates your photos are still on an SD card.
I get convenience has led everyone to expect their phone to do everything for them, but it's not working. When you're in a pinch you will go to a 7-Eleven and grab food, but everyone would agree that buying everything there instead of real groceries is a terrible strategy. Just because something is convenient doesn't mean it's good.
> I get convenience has led everyone to expect their phone to do everything for them, but it's not working.
It's mostly working, though. For every story of someone experencing a severe problem, there are millions of non-stories of people not experiencing the problem.
Inconveniencing yourself every day just to avoid the rare situation is not necessarily a great life strategy. Furthermore, most consumers are not as aware of these problem cases as we are. They don't expect the worst until it's too late.
Admittedly, failing to back up is just dumb, and everyone should know that by now. On the other hand, nobody should be expecting that a software update will kill their passcode.
Well I only use alphanumeric US keyboard standards ever since I found out, that certain characters unique to a language different from yours causes you lock out or massive headaches on a used keyboard with almost no print ink left on the keyboard in a Internet cafe in an other country around 2002.
Be aware of characters not passwords. I feel bad for the guy but not really blame Apple here.
English is my second language and ANSI etc is following a basic character usage. Everything must boil down to 0 and 1 in the end or American English.
It is a de facto standard and maybe knowing about it is as crucial as recognizing the difference between the imperial and metric system before heading for the moon. It is a life saver.
I agree with the recommendation, but it's absurd to not blame Apple here. There is absolutely nothing acceptable about what Apple did in this case, it's a major fuck-up to break password input in this way, and for no reason whatsoever.
> During in-house testing, which involved taking an iPhone 16 from iOS 18.5 to iOS 26.4.1, The Register found that Apple has kept the háček in the Czech keyboard, but removed the ability to use it in a custom alphanumeric passcode. The OS will not allow users to input the háček as a character. The key's animation triggers, as does the keyboard's key-tap sound, but the character is not entered into the string.
Sounds more like an actual bug than a decision to change the keyboard layout, if this happens only in the passcode screen?
I remember something like 10 years ago there was an article here in HN, where someone created a user on macOS with password out of emojis.
Then he couldn’t login, because login screen does not have a special character keyboard.
EDIT: found it https://news.ycombinator.com/item?id=10742351 (apparently I remember it slightly wrong, but idea still the same)
Good on El Reg for doing some actual hands on fact finding.
I think the biggest lesson here is to back up. The reason for losing access to the phone is amazingly dumb but it could have fallen down the stairs for basically the same effect.
And do your could backups cross-provider. You never know what the "big players" are going to pull, and your lifetime customer value is less than the cost of a single support call.
> your lifetime customer value is less than the cost of a single support call
yes that is the pattern, pioneered by Google here in California
This is exactly the reason why I keep all my shit on an SD card despite Google deliberately making the external storage experience as painful as possible: slow access, broken writes, failed unmounts, no filesystem repair. Literally every time I restart my phone I need to put the card to my PC and repair the filesystem. Also, same card works extremely well when plugged into PC via random cheap USB card reader.
On PCs you still have Linux that resists enshittification and you can pick your own hardware, but it's a really sad state of affairs that there is literally no meaningful mobile system that isn't actively hostile to the user.
There’s a number of mobile Linux distributions around, some even run Android apps.
People need to wake up to the fact that Android has become iOS but worse.
I just have a cheap second hand PC with a couple of good drives running LAN only Immich and a few other backup tools. This, in parallel to cloud backup, makes the setup both mobile and reasonably fault tolerant.
I'm quite wary of using SD card for backup. Too easy for me to lose.
The thing that bothers me about Android is the gimped file manager.
You wan't to access some files off your network using smb? Here install this third party tool and don't forget to give it full read/write access to your device.
Your case is obviously not this, but SD cards aren't a great primary drive, as Raspberry Pi power users sometimes discover. Their durability can be unpredictably spotty.
GNU/Linux exists on mobile, too. Sent from my Librem 5.
Biggest lesson is Apple should allow you to downgrade OS, especially on old devices.
Or release some sort of open version once device is EOL'd.
Even if they did, would you recommend them allowing the downgrade without the passcode? Any action that requires a passcode doesn't help this user.
Then an attacker could load an older, exploitable OS and gain access.
Weirdly I care more about my rights as the owner of the device than the rights of a theoretical attacker.
I’m all for a system that allows you to wipe the device to do a downgrade or upgrade (just like any PC with an unset bios password allows) but the idea that it’s a good design for someone without my OS password to be able to downgrade my OS or perform any operation on my OS is insane.
What’s even the point of setting a password if anyone can manipulate the system without entering it in?
The entire iPhone OS is on an encrypted volume and that is the right design choice. Not having the password means no access.
There is no general purpose encrypted volume operating system that allows unauthenticated users to perform OS manipulation. If you encrypt your FreeBSD, Linux, or Windows volume, the result is the same: no password, no access.
Your choice is to enter the correct password or wipe the disk.
The fact that Apple doesn’t allow you to set up a system without full disk encryption is not a user freedom issue, it’s a very sensible design choice especially for a device sold primarily to non-technical consumers who don’t understand the security implications of leaving the volume unencrypted.
The issue here isn’t that iOS security is designed wrong, the issue is that Apple broke basic password entry with an update.
Shame on Apple for having such lazy software development practices when it comes to implementing updates like this.
Yeah I agree that a downgrade that always results in a full wipe is a good compromise.
So don’t buy an iPhone if you don’t care about the security of your device and personal information. That would introduce a massive security hole that would negatively affect far more users than it would help.
I doubt that. The group of people you're talking about are those who have their phone maliciously stolen by people who are actively working to hack/exploit their way into the devices and then actively exploit the information stored on them. That is a utterly negligible percent of users, or even of users who have their phone stolen. The overwhelming majority of thieves of intent move the devices onto professional orgs that wipe them, jailbreak them, package them, and then ship them on to other entities that resell them.
The percent that might want to choose a different-than-latest version of OS would also of course be quite small, but I suspect it would be orders of magnitude larger than the other group we're speaking of just because that group of people is going to be so absurdly tiny.
In this world stolen iPhones are mostly worthless because they can’t easily be wiped without the password.
In your world, they could be.
I imagine iPhone thefts would go way up. They’re worth $1000 and we just carry them everywhere - if they were easily resellble it would be a very obvious quick-money theft opportunity.
iPhones are currently the primary target of thieves by an overwhelmingly wide margin. There are many ways to wipe them and its an industry in its own right. One of the most common, as always, is simple social engineering. They contact the victim posing as Apple, convince them to reveal their credentials in this way or that, wipe the device and away they go. If that fails they're stripped down and sold for parts, which is also reasonably lucrative.
I don't know for certain why thieves are generally not typically interested in abusing user data, but I'd imagine it's because the penalties if caught would go way up. That'd go from what is generally just petty theft, which carries a slap on the wrist, to wire fraud and a whole slew of other charges, which can leave people spending most of the rest of their life in prison.
That’s all true, but it is also true that iPhone theft is relatively rare.
My assertion is that there would be way, way more theft if you could just downgrade and wipe.
It’s rare in the US and very common in London
Is it? Do you have any data to back this up?
Because a quick search for UK statistic shows that even though iPhones are minority of phones over here they are the overwhelmingly majority of all phone theft:
https://www.loveitcoverit.com/news/changing-world/mobile-pho...
"In terms of smartphone models, the data also indicates who might be most at risk. Looking at the entirety of the UK, 68.6% of stolen phones are iPhones."
[dead]
It should be then a switch in the settings.
What should we label it? “Waste time entering alphanumeric password that provides no security benefit”?
The particular use case you’re asking for here has no logical reason for existing
This is not an excuse to let people choose if they allow os downgrades or not. Like bootloader unlock option on android devices.
Also people find exploits on newer OS versions as well. Downgrading makes it easier but not downgrading doesn’t make the device unhackable.
Not allowing downgrades is the biggest contributor to smartphones becoming e-waste.
Apple should be forced to do this by law, but only after they discontinue software support. If they're willing to continue making small, incremental patches when necessary (such as to fix this obvious bug) then it's fine that they can still block downgrades. But at EOL? They should be legally required to allow old software to be installed.
This also impacts software compatibility - any 64-bit device that is now EOL that got updated to iOS 11 or newer is forever barred from running 32-bit apps just because people are worried that someone might take that old device and downgrade it as an attack?
The average person should always stay updated to the latest version for security reasons. But the power users should be able to choose which version they run, at least on devices that aren't currently supported at all.
Daily reminder that the first two iPhones and the first iPod touch had zero firmware signing, and you could freely install any supported version at any time, and can still do so today. That being the case has probably harmed 0.00001% of people at most
> Not allowing downgrades is the biggest contributor to smartphones becoming e-waste.
Citation needed. My guess is the biggest contributor to smartphones becoming e-waste is gravity.
I have heard many replace their phones due to dropping them and becoming unusable. But everyone uses a case now and the build quality is generally better that one mishap does trash the phone. Most people I know getting new phones now did so bc their old phone "got too slow to be usable." I believe that's a matter of new OS versions really are much heavier. Both my last 2 phones I had upgraded bc I went one version too far and had a nearly bricked phone.
The biggest lesson here is don't buy Apple products.
Steve Jobs would be rolling in his grave if he could see the software quality of the products that Apple releases today.
> Steve Jobs would be rolling in his grave if he could see the software quality of the products that Apple releases today.
lol, nah he wouldn't. He would of upgraded his coffin to plush and got a big screen to watch the money roll in.
I recommend reading up on his 80/90's antics. All he cared about was money and that the world was crafted by him.
He was widely known for intense bullying, lacking empathy, and ruthless manipulation, combined with a "productive narcissism" that fueled his obsessive drive for perfection.
> I recommend reading up on his 80/90's antics. All he cared about was money
Incorrect. Read the David Pogue Apple book. For example, after the iMac was released, the Apple board of directors offered Jobs a million shares and six million options if he switched from interim to permanent CEO. Jobs continued to refuse. “This is not about money. I have more money than I’ve ever wanted in my life.”
Most of Steve's wealth came from Pixar, which he ultimately sold to Disney, rather than from Apple.
Yes, and "his obsessive drive for perfection" as you put it is what would make him "rolling in his grave if he could see the software quality of the products that Apple releases today" as the parent put it.
He famously shipped the original Macintosh with a keyboard without arrow keys to force buyers to use the mouse.
His vision of perfection didn't always match common sense. There are quite a few examples of this.
I always cringe a little when I read these "jobs would have rolled over in his grave" comments.
He would've not let the abysmal slop like iOS 26 UI to ship ever.
Some things he didn't appear to care much about, the polished UX was his schtick.
I am 100% sure that Steve Jobs could have shipped a broken Czech keyboard if that was in pursuit of some random abstract like purity or minimalism. "iOS keyboard has too many keys. Reduce keys make them larger. People should not use these obscure symbols anyway". (extrapolated from a couple of biographies and a couple of books on 1980s Apple I read, this is very consistent with his character).
As for iOS 26, no reasonable person would have let it ship. From one source (John Gruber -> "Bad Dye Job") the previous head of Apple's UI design team who lead the UI team was just not a UX designer, he was just a visual designer or something. I think it shows.
You are over-exaggerating.
As much of a snob that Jobs was it's nonsensical to say that he would've knowingly insisted on changes that locked users out from their devices. That's just nonsense. At the very least there would've been a prompt to change the password phrase or some such in upgrade. And if it did happen as an oversight, it would've been patched on the first report and some heads would've rolled.
But that's the difference. Jobs might've done something like this for a reason. That's not what happened here. He probably wouldn't have tolerated it as a bug.
Jobs was a perfectionist and a minimalist. Part of minimalism is that sometimes you delete marginal features (arrow keys) that you still end up wanting back.
If you never delete too many features, you aren’t deleting enough features.
Didn't he also say you are holding it wrong?
> Byrne was hoping that the next update, 26.4.1, would introduce a fix for this, but its release this week has not helped.
Even if Apple restores the háček in a future update, wouldn't he still need to unlock the iPhone to install it?
You can always reboot to recovery and install an update that way.
Won’t that wipe all the user data?
He can upgrade, but not downgrade, for security integrity.
People often seem to ignore that Availability is part of the security triad.
If I burn someone’s wallet and throw the ashes to the wind nobody can pickpocket them for it. Secure.
Doesn't this mean that no matter how securely your phone is locked, Apple (and probably the three-letter agencies) can always unlock it by installing an appropriate update?
Not necessarily. If the secret is protected in the secure element against something only you can provide (physical presence of RFID, password, biometric etc) then it is ok.
BUT you must trust the entire Apple trusted chain to protect you.
That is a rather big BUT.
> If the secret is protected in the secure element against something only you can provide (physical presence of RFID, password, biometric etc) then it is ok.
But we already established unlocking is not possible, so going with the argument it's implied there is a side-channel. Nothing, but a secret in your brain is something only you can (willingly) provide. Especially not biometric data, which you distribute freely at any moment. RFID can be relayed, see carjacking.
If you can side-step the password, to potentially install malware/backdoor, that's inherently compromising security.
If the data you care about is encrypted with a token locked behind your passcode input, and it's not theoretically brute forceable by being a 4 character numeric only thing, then not easily, no.
Could they produce an update that is bespoke and stops encrypting the next time you unlock, push it to your phone before seizing it, wait for some phone home to tell them it worked, and then grab it?
Perhaps, but the barrier to making Apple do that is much higher than "give us the key you already have", and only works if it's a long planned thing, not a "we got this random phone, unlock it for us".
(It's also something of a mutually-assured destruction scenario - if you ever compel Apple to do that, and it's used in a scenario where it's visibly the case that 'the iPhone was backdoored' is the only way you could have gotten that data, it's game over for people trusting Apple devices to not do that, including in your own organization, even if you somehow found a legal way to compel them to not be permitted to do it for any other organization.)
> Perhaps, but the barrier to making Apple do that is much higher than "give us the key you already have", and only works if it's a long planned thing, not a "we got this random phone, unlock it for us".
The attack situation would be e.g. at the airport security check, where you have to part with your device for a moment. That's a common way for law enforcement and intelligence to get a backdoor onto a device. Happens all the time. You wouldn't be able to attribute it to Apple collaborating with agencies or them using some zero-day exploit. For starters, you likely wouldn't be aware of the attack at all. If you came home to a shut-down phone, would you send your 1000$ device to some security researcher thinking it's conceivably compromised, or just connect it to a charger?
If you can manually install anything on a locked phone, that's increasing the attack surface, significantly. You wouldn't have to get around the individual key to unlock the device, but mess with the code verification process. The latter is an attractive target, since any exploit or leaked/stolen/shared key will be potentially usable on many devices.
Nope
That's what I was thinking, but the phrasing seems to imply that he did update to 26.4.1? Not sure how that was possible.
afaik you can update your locked iPhone with a Mac or Windows in iTunes... but it will still require a passcode after update, so ¯\_(ツ)_/¯
Nope, the ”trust this computer” dialog needs you to enter your passcode before any other actions are possible
This can be bypassed by putting the phone in DFU mode.
Probably the only hope is jailbreaking.
Jailbreaking a locked, inaccessible iphone?
Keep in mind that everyone else is usually unaware (by design) of what all the intelligence agencies can do, but I doubt they would help in this scenario even if they could.
On the other hand, if this happens to a far more important person...
Jailbreaking is dead.
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.
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...
> 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.
Probably the better solution is to include some kind of special lock-screen keyboard that provides some fallback mechanism to input any character. Presumably there are similar edge cases where someone creates a password using one keyboard, then switches keyboard layout, and now can't re-enter it using the active layout...
Indeed. For example, most desktop operating systems have a keybinding for «search for any Unicode symbol by name and input it». That would make sense to have as a fallback button on a virtual keyboard too.
The iOS emoji selector is close in UI/UX already, but the search is restricted to the emoji range of Unicode.
Wonder if you can get it to enter effective. Power لُلُصّبُلُلصّبُررً ॣ ॣh ॣ ॣ 冗
You can but you have to tie it to actual devices and a point in time, not simply a specific OS version. Essentially, all devices that existed before the change must still support the old set of characters and devices produced (or sold or activated) afterwards can support the reduced set.
Or wait until a future OS version that will not support any device currently in existence.
This fails if they let you keep your password migrating between devices, though, so you probably need a version somewhere in the middle that flags it as an issue and flags it as not allowing migration without changing the passphrase.
Yeah, they could force a password update at some point to ensure passwords meet the new requirements.
You need to not just force the update, but also forbid using pre-updated ones in migration, since someone might conceivably have an off-for-many-years device they wake up and want to migrate.
The long tail of stupid edge cases is very long indeed.
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.
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.
Meh, I think you keep the old keyboard and set a password expiry. New passwords use the new keyboard. Or, if you're in a rush to remove the old code, _after_ next login you require password replacement and use the new onscreen keyboard from then.
It might be tricky when user upgrades while jumping the “headups” version.
There should be migration taken into consideration that is kept to any previous version allowed to be upgraded from.
And perhaps also introduce an upgrade blocker, as the keyboard app notifies the system of a situation that would be unsafe to upgrade to newer releases
That’s dangerous. Apple fooled me with the iOS 26 glass theme, it’ll be a while before I install another major update from them. I know many people still on iOS 18. I doubt many of them will update until either Apple fixes their UI/UX or they upgrade to an Android.
For other features, yes, but not this. Of course people will work around the warnings and then suddenly they're locked out of their whole phone?
You assume the worst case: every character that could ever have been entered is in use.
Yes, it really is that simple. They chose that responsibility the moment they allowed those characters. Any deductions done after that need to have a failsafe with the expectation they will break a clueless user's device.
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.
Agreed, but just to be clear; I was asking how would you test that assuming you still wanted to remove a character that was previously present.
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?
Right, but this test basically means you can't ever remove a character if it was ever present. I was assuming that you still want to remove it (for some reason) and wondering how to safely test the change.
You create two keyboards and use them both and test them separately. Then you create a keyboard update flow. And you test that. Then you make sure you test that the old keyboard shows until the user changes their password.
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.
> 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.
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.
I used to have an emoji password for my Android phone, and had the exact same issue after a reset! It's an odd but pretty terrible failure mode for locking oneself out...
You say locking oneself out, but I decline to consider any situation where a password can be set but not later entered as one where the user bears even a modicum of fault.
I remember a website that silently removed everything but the first 8 characters from the "password" field upon registration but somehow didn't do the same on the login page. It took me several hours and several password resets to actually log in after registration, since for some reason the trimming happened client-side and only when typing the password manually (and I was pasting my password from a password manager).
In a similar vein, I remember encountering a site where the frontend enforced basic complexity requirements ala “use at least one number and one symbol” but the system would silently drop all non-alphanumerics when it saved (presumably in some kind of failed conversion on the way into the backend DB). So setting a password like “foo_bar4!” would become “foobar4” which was surprising. What blew my mind though was when I figured out the stripped password worked to log in, which was how I eventually figured out what was happening, escaped the reset flow, and generated a compliant password.
We're so far down this path the language around the problem is distorted. Ownership has been perverted and the only thing you control is the bill.
Relevant xkcd: https://xkcd.com/2700/
This is completely unacceptable from Apple. You CANNOT remove a key from the keyboard that's being used as a password.
Turns out they CAN and they WILL. The character has always been special on all Apple OSes.
as if they cared
I wonder were are the software engineers. No senior devs at Apple anymore?
Just interns pushing to prod without any review? What the hell is going on in the software industry?
Such mistakes a trillion dollar company can not allow to happen.
Since the beginning, iPhone keyboard is wrong in entering a character first, háček second. It has been the other way around on typewriters and then computers for decades. Then some smart guy at apple thought he knows better. One of those never-fixed-bugs.
> It has been the other way around on typewriters and then computers for decades.
On a typewriter, I would expect one to type the latin character, hit backspace, and then add the mark? Or if using a typewriter without the necessary mark, just type the latin characters, then add the marks with a pen to the full sheet.
Wait, really? I thought "dead keys" being diacritics prefixes, not suffixes, was pretty universal. At least that's how it works with ^, ´, and ` on macOS for me.
I lost all of my photos when I was a college student too. I was way too irresponsible to actually back anything up. Kind of a bitter lesson.
I assume you can use a physical keyboard on an iPhone like I can on Android via USB? Presumably you could buy a wired Czech keyboard to access the device?
Twice I have had the touchscreen fail on Android devices and been able to get what I needed off them using a USB mouse.
For the same reason, plugging in an external keyboard is also a no-go since freshly updated iPhones are placed in what's known as a Before First Unlock state, which prevents wired accessories from working until the passcode is entered.
Makes sense why he didn't do this.
You can, after you unlock it.
This really should be escalated to the point where Apple engineers build a one-off / custom iOS so that this person can unlock their phone and change their passcode. I'm sure this is in the realm of possibilities. It is such a bad look.
That seems very unlikely if only because Apple probably has the equivalent of big flashing nuclear stockpile grade warning signs internally around anything that involves the phrase "one off firmware release", since they have every interest in convincing any nation-state or anyone else that it would be quite difficult and something they have no interest in to do if they ever try to compel them to make one.
Someone on twitter had the idea that he could use the camera to take a picture of the character (or his whole password) and copy/paste it using the built-in ocr feature.
I don't have a text password on my iphone so I don't know whether you can paste into that field.
The article mentions that he tried that and it scans as a different character.
Majority of California based companies employee English only or English and Spanish speakers possibly with some Indian language as well. This leads to lots of problems when you are bilingual or bilingual in other languages such as German in French. Neither Apple nor Microsoft under this sort of language swapping well. Never mind rarer languages like Czech or Greek.
> Majority of California based companies employee English only or English and Spanish speakers possibly with some Indian language as well [...] Never mind rarer languages like Czech or Greek.
That may be generally true, in this case Apple actually has an engineering team in Czechia that works on biometrics and authentication:
https://zpravy.aktualne.cz/ekonomika/apple-posili-v-praze-ty...
https://jobs.apple.com/en-gb/details/200636301-2611/software...
So could they finally fix their quotations marks in Czech? Probably no, they never cared, so why should they start caring now.
No but they might be able to fix authentication problems, which is what this is.
Guess what, they’ll do nothing. If Czech market is small enough for them to fix quotation marks, they’re not fixing Czech keyboard.
OTOH, if an American will whine enough on Internet, they may fix it for him. Maybe some other American should use standard Czech quotes as password to get it fixed also.
I'm a little impressed with Google. Recently the assistant started understanding when I speak Portuguese or when my wife switches to it in a text message. I hadn't had that experience before, the assistants would pick one language and mispronounce the other.
Alexa has an experimental bilingual mode but it's nerfed by its general failure to understand well.
This is a pet peeve of mine that makes it so annoying to communicate with friends and family who live in other countries.
I use danish and English and I must admit I don’t really encounter issues switching between them on apple or Microsoft operating systems.
Only thing I can think of is some features being available later in danish compared to the English release like the swipe keyboard in iOS.
I would not be surprised if Apple engineers are more likely to be bilingual than a random person selected from the world's population.
Netflix can't even auto-translate subtitles (in the age of genai where we are close to generating entire movies from scratch). Let alone ever imagine that you'd want to see subtitles in two languages at once.
Language support is still such an enigma.
We run into this issue when watching Korean movies/dramas. My wife prefers Japanese subtitles and I prefer English/German. I haven’t found a way to enable two subtitles in Firefox (via extensions). So in those cases I usually download a release which contains subtitles in both languages and use a script to extract them via ffmpeg and then combine them into a single srt. Now the issue is that the lines of the different languages don’t always appear/disappear at the same time. This leads to text jumping up and down. I have tried to mitigate it by injecting white space where only one line is visible, but this again fails when the video player breaks long lines or when the location of the subs change to the top (because there is hard-coded text in the image). I feel like there must be a better way…
mplayer supports displaying multiple subtitles
Apple should get sued for this to oblivion, this is unacceptable.
EU citizens have specific avenues to complain and get compensation for stuff like this so hopefully the user in question uses it.
Tangentially related, a relative bought a new Apple laptop a few weeks ago, and I was tasked with setting it up. The computer came pre-equipped with a Czech keyboard (apparently the US models weren't in stock and that relative needed a new computer as soon as possible, so they bought a Czech one).
Since the user doesn't speak Czech, I promptly removed the Czech layout and installed two other layouts, US English and Hebrew, for the languages that the relative uses to type on the computer.
For some reason, login screen just after boot still uses Czech layout, which means Z and Y are swapped and numbers must be typed with Shift (just pressing numbers outputs Czech letters like ěščř). So when booting up the machine (remember that you can't use fingerprint during first unlock), the user must type the password in whatever layout is physically printed on the keys, even though the rest of the OS doesn't even have a mention of that layout. Somehow afterwards the OS "can" see the list of the layouts and lock screen correctly chooses the English US layout.
Alongside of that, for some reason, the key that's supposed to type ` and ~ in the US layout types some nonsense instead (a plus-minus sign and a section sign), whereas the backtick key is for some reason located between left Shift and Z (good luck unlearning years of muscle memory typing ~/Documents in the terminal)
This feels like it's probably a stupid oversight chain like, keyboard layouts are user-specific data, so they're not decrypted before first unlock/set globally because the machine might have multiple users with different keyboard layouts.
Even if it is, why is there no way to change the system-wide settings? All other operating systems that I know either have an explicit button "Apply settings to login screen" or do it automatically (I'm sure 99% of the consumer-level computers sold worldwide never have more than one user on them, moreso with different keyboard layouts).
Evidently you can, though in traditional macOS fashion, you exploit Apple secretly changing the setting for you if you do a magic dance.[1][2]
I've never had a reason to try it, but there's also a remark that 99% of the Macs sold probably don't need to change the system-wide keyboard layout defaults, either...
[1] - https://heylon.ca/how-to-permanently-switch-default-keyboard...
[2] - https://support.apple.com/guide/mac-help/change-the-system-l...
Even if he did have a Mac with the continuity feature enabled, I suppose the lock-screen won’t accept a paste from the clipboard of a Mac. (If it did, he could enter the correct passcode in any text editor on his Mac, copy it to the clipboard on the Mac, then paste it into the lock-screen on his iPhone)
Continuity has never worked on the lock screen and certainly not in the BFU state.
This really reads like a modern Ancient-Greek story about inscrutable gods who suddenly decide to complicate your life for some unclear reason and don't respond to any prayers and rituals.
People are afraid of AI, but human organizations can be quite opaque as well.
That said, as a Czech, I wouldn't use any accentuated characters in my passwords. Anything beyond 7-bit ASCII is just asking for trouble.
> This really reads like a modern Ancient-Greek story about inscrutable gods who suddenly decide to complicate your life for some unclear reason
If you read the ancient Greek stories, a consistent theme is that, if you offend the gods, they will punish you...
...but they're at least as likely to do it by cursing someone blameless who will then have an effect on you as they are by cursing you directly.
there was a time when I used a simple "§" in my password. turned out, some Android keyboards don't have the "§". Since then I play it safe with my passwords, using only characters I don't need a specialized keyboard for
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.
Are you aware that billions of people live in countries where they could go on the whole life without seeing an ascii letter?
That's not really true in any country these days.
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.
because it is common sense
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.
Definitely isn't for non-technical users. I guarantee you if you asked basically any random Joe on the street what ASCII means they'd have no clue.
https://xkcd.com/2501/
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?
The "real mistake" is changing things that used to work.
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.
Did the underlying bits (hex/oct/… or whatever representation) actually change or just the visuals?
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 :)
Maybe.
But there is already a known pattern on how to handle this which I was taught (before the original iPhone even) in university CS studies:
If the manner of entering credentials has to change,
Then on first entry, offer the old method,
And, because you now (temporarily) have the plaintext credentials, you can now inspect it and test if anything need to change for the future,
And then set a flag, or require user action , or just re-encode, to use the new method as inspection determines.
But why should non-English speaking users be forced to use an ASCII password if the rest of the OS supports their language just fine?
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.
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?
It was hard enough to spell Français correctly.
To avoid apple inevitably fucking up and breaking things like in this case. The risk to benefit ratio for allowing this is just very poor
> 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).
> keyboard setting is per-user setting
Do you think most users know this?
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?
> I think the real mistake was Apple allowing to enter a non-ASCII password in the first place.
No that's obviously crazy!
The side of my brain that manages organizational changes wonders: how does Apple, a 50 year old company of tens of thousands of engineers and over a trillion USD market cap, manage to keep feature velocity high while not making more of these types of errors?
The bug seems low likelihood but high severity for the few affected users. Other than simply never changing the login keyboard (or any of the keyboard code) or having nearly 100% test coverage, how does a company not accidentally have more of these types of issues?
They do. It’s just that the people using these devices won’t go public with it. I’ve seen so many bizarre bugs in my own experience but I’ve gotten zero articles on them by popular tech journals.
This bug got popularity that’s all.
They do. Companies mess things up all the time. But only a fraction of bugs get discovered and then reported, so it appears that their quality is ok.
I have recently discovered several bugs in different products created by different companies. And none has been reported so far in my research despite the products' popularity. I am not surprised, since those bugs require specific combination of conditions to be triggered, which most people have never run into, like in this article.
And I don't even blame them -- the engineers probably could never think of such use cases and don't have those workflows themselves. You'd have to really go out of your way to use obscure workflows to discover them.
Although in this case Apple dropped the ball by locking user out and not providing any alternatives.
> how does Apple, a 50 year old company of tens of thousands of engineers and over a trillion USD market cap, manage to keep feature velocity high while not making more of these types of errors?
They don't. If you're anything other than an extremely casual user of iOS or macOS for a couple of years, you'll encounter things that really make you pull your hair out by shear magnitude of "how on Earth can anyone miss this!?".
The same goes for feature velocity.
This is why DIY is important: it's an operational risk mitigation measure.
"Never do a major OS update on any Apple product" - this is the mantra I am telling myself always.
Seems like a front-end bug? So just access the API directly, or ask someone who knows how to do that? Plenty of iOS-focused reverse engineers out there.
How? The article states:
> For the same reason, plugging in an external keyboard is also a no-go since freshly updated iPhones are placed in what's known as a Before First Unlock state, which prevents wired accessories from working until the passcode is entered.
The user can't even enter their passcode, how do you expect them to perform code execution?
Plugging in a USB keyboard is way higher level than what I'm talking about. You can contact a digital forensics firm, and they'll do it for you. It'd be custom hardware. Cellebrite-type stuff.
Why would they do it for free?
Why would it have to be free?
Do you know what the cost of breaking into a fully up to date BFU iPhone is?
They're not breaking in; he knows the password. Also, it's not fully up-to-date; it's an iPhone 13.
Surprised that no one commented on the clever title!
I had to read it 15 times to understand what it was trying to say. There is such a thing as trying too hard at being clever.
Just one more good reason to be doing unit tests
if you remove the hachek, there will be MANY locked out czech users. It's a symbol of national pride!
I’m willing to bet a significant portion of the passwords start with the letter “p”.
paššWord1!
[dead]
It’s an annoying workaround, but could he connect a USB keyboard (via a USB to lightning adapter) with the ability to enter the character? Does the passcode screen accept input from attached keyboards?
As mentioned in the article,
> For the same reason, plugging in an external keyboard is also a no-go since freshly updated iPhones are placed in what's known as a Before First Unlock state, which prevents wired accessories from working until the passcode is entered.
Why can't people read stuff before commenting?
I wish we could just have comments removed where it's clear the author didn't even put in the minimum effort of reading the article. It's disrespectful to the rest of us.
Today's free verse:
Why can't people read stuff before commenting?
Why can't people read stuff before?
Why can't people read stuff?
Why can't people read?
Why can't people?
Why can't?
Why?
?
Why can't people read the HN guideline before commenting?
https://news.ycombinator.com/newsguidelines.html
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that".
It's mentioned in the article. USB devices are blocked until the passcode has been entered.
I feel bad for the guy and all the Apple users constantly sharing stories of being mistreated and abused. Stop giving these companies your money and consent.
I'm basically numb to it at this point though. Every few days we read on this site small permutations of the same story. Sometimes people here get a little extra backchannel support, but that's a token prize for the jester who made a king chuckle.
Then a few more days go by and everyone upvotes a new iWidget to oblivion because it has 0.1 new gigablahs or takes up a milliblah less of some bullshit nobody was asking for.
All while we collectively virtue signal that people are spending too much time and relying on technology too much.
Well, it's almost Monday let's see what new bullshit convinces everyone to keep getting fucked and pay for the privilege.
I basically have turned into this guy: https://youtu.be/8AyVh1_vWYQ
> I feel bad for the guy and all the Apple users constantly sharing stories of being mistreated and abused. Stop giving these companies your money and consent.
Here's a challenge: walk into a store and attempt to buy a smartphone that is not iPhone or Android.
This is the situation that consumers face. Some alternatives exist, but most consumers are completely unaware of them, because the alternatives have no advertising budget or retail presence.
I think it's quite similar to the political duopoly. Third parties exist, but they have no advertising budget, and moreover, in a Catch-22 situation, they get little or no news coverage, precisely because they have no advertising budget, and thus the news media considers them "not viable." That's a self-fulfilling prophesy. Actually the same situation exists in tech: Apple and Google get huge amounts of free news coverage in addition to their paid advertising. The media appears to feel no obligation to help people escape from duopolies; guess who pays for their advertising...
Yes, the phone market is bad. But, you know you don't have to do everything in a phone, right?
Want to take pictures? Use a camera. If it somehow auto updates your photos are still on an SD card.
I get convenience has led everyone to expect their phone to do everything for them, but it's not working. When you're in a pinch you will go to a 7-Eleven and grab food, but everyone would agree that buying everything there instead of real groceries is a terrible strategy. Just because something is convenient doesn't mean it's good.
> I get convenience has led everyone to expect their phone to do everything for them, but it's not working.
It's mostly working, though. For every story of someone experencing a severe problem, there are millions of non-stories of people not experiencing the problem.
Inconveniencing yourself every day just to avoid the rare situation is not necessarily a great life strategy. Furthermore, most consumers are not as aware of these problem cases as we are. They don't expect the worst until it's too late.
Admittedly, failing to back up is just dumb, and everyone should know that by now. On the other hand, nobody should be expecting that a software update will kill their passcode.
Well I only use alphanumeric US keyboard standards ever since I found out, that certain characters unique to a language different from yours causes you lock out or massive headaches on a used keyboard with almost no print ink left on the keyboard in a Internet cafe in an other country around 2002.
Be aware of characters not passwords. I feel bad for the guy but not really blame Apple here.
English is my second language and ANSI etc is following a basic character usage. Everything must boil down to 0 and 1 in the end or American English.
It is a de facto standard and maybe knowing about it is as crucial as recognizing the difference between the imperial and metric system before heading for the moon. It is a life saver.
I agree with the recommendation, but it's absurd to not blame Apple here. There is absolutely nothing acceptable about what Apple did in this case, it's a major fuck-up to break password input in this way, and for no reason whatsoever.