Hacker Newsnew | past | comments | ask | show | jobs | submit | Matl's commentslogin

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.


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?


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.

Has it ever entered your mind that maybe it is actually Israel that is threatening every other country?

Israel remembers the Six-Day War...

The war started by Israel, ostensibly as a retaliation for a dispute about a bit of water, which Israel used as a pretext to invade the West Bank? What about it?

Does that give a perpetual licence to kill, or do we try something productive at some point?

The only productive solution is to get rid of all religious ideology out there (both sides).

Good luck.


The 'both sides' thing when one side is occupying the other is pathetic. There's only one side that needs to stop the occupation immediately, the Israeli one. We can go from there.

Yeah remember when they left Gaza in 2005. What happened then?

They levelled it, tens of thousands killed.

'left' as in imposed a blockade on it, you mean?

This is preposterous revisionism - Israel didn't just leave Gaza alone, they turned it into an open air concentration camp, controlling everything going in and out. And they were utter bastards about it too, literally counting calories going into Gaza, and classing just about anything as "dual use" so not allowed (e.g. tent poles could be used to hit someone).

Israel has never stopped being the aggressor. Maybe if they stopped occupying, stealing, raping, murdering and massacring, the entire region might be more peaceful. Not likely for a genocidal, apartheid state filled with religious supremacist fanatics though.


Everyone remembers The Nakba. Or the Suez Crisis

And?


Nakba - Entirely the result of Ottoman foreign policy, WW1, WW2, League of Nations being a total fuck up.

Suez Crisis - Egypt being dicks

Six Day War - attacked from all sides.

Bit of a contrast, no?


Translation: Israel is always the victim, even if the whole world outside it sees it as the aggressor.

I guess illegal settlement in the West Bank is the result of a Nintendo console not being launched the same day in Israel as in Japan? Or any other made up thing that shifts the blame from Israel to a 3rd party?


Israel wants to completely destroy Iran so than no one would be willing to in any way challenge its occupation of Palestine, nor its ambition to expand into Lebanon, Syria, Jordan, Egypt and beyond.

Then there's an element of extremist Christian ideology from Pete H. etc.

Hormuz has little to do with it, it's just an excuse to destroy Iran.

Trump has been convinced that the Iranians are after him, plus there's the Epstein kompromat that the Israelis have on him. He's the only US president compromised enough to destroy Iran for them, war crimes and all.


The oil narrative is what worked after Iraq war and I am afraid it will work now

For one, I am glad I don't have to color my functions like your typical async.

I agree that this is the big problem with Rust's async story.

But like I said, in my opinion this compares with Go not having an async story at all.


Other languages have ill considered shortcomings. Rust has ambitious shortcomings.

I don't know about progressives specifically, but I don't think 'cannot empathize with their opponents at all' is what articles like this are doing. It's more that the more people like Alex Karp talk the more they prove that their morality is something which should be opposed by the general public. IMO the more Palantir talks the better.


Many CEOs treat their employees like kids in elementary school to make themselves feel smarter.


I had Sailfish on XPERIA and it was no less stable than Android/iOS in my experience. But that wasn't the first version I don't think.


I can only guess but I'd think maybe it's more for playing out scenarios i.e. in such and such situation, if x, y and z are true on the ground, how would you expect this to play out, while playing with x, y, z and then maybe working to get x, y, z as close to be what we roleplayed on the ground before going in, rather than an exact 'how to'.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: