There are so many bugs in iOS that are years old and still unfixed.

One example is the cellular-data draining bug[1]. The only "solution" for this is to wipe your device, and set it up again, without restoring any backups, at all. Which makes the whole point of backups of the device totally pointless.

For a company that spent $6B+ on a (now mostly empty) campus, you'd think they could spare a few $million into proper QA/Testing.

[1] https://mjtsai.com/blog/2019/07/26/broken-ios-cellular-data-...

I had to do this last year. Three calls to Apple Support... in the end I just wiped the phone and started over. The first time in 10 years. I was burning through my entire quota in 20 days and then racking up $10 per Gb over the quota with Optus. Very frustrating.

Happened to me as well just a month or two ago! A total reset was the only fix…

i haven’t restored a backup on a new iphone in years. i was doing it for a while and always ran into issues. there were so many issues each time i restored that i simply didn’t have time for all the bs. since i stopped restoring everything went back to normal. now i just buy a new iphone every couple of years and simply set it up as new.

The backups aren't the problem - what is the problem is Apple's "solution" to a clear bug being "don't restore from backups" (for the cellular-data draining bug).

Instead of asking you to lose all your data as a workaround to a bad bug, they should actually fix that bug properly, so that it's no longer a bug.

Likely the same with the bug described in this story - if someone ends up affected by it, they're basically pooched: they can't do any more new backups, and likely if they do restore from a previous backup where data exists that triggers this, they're just going to get into that same loop of problems.

And because it's not a "high severity" (RCE) bug, it's likely never really going to get fixed as there are "workarounds for it" (read: wipe/setup the device and omit your data) or "other mitigations implemented already (previous versions of the OS be damned!)" as noted in the story.

I don’t see any indication that Apple recommends this workaround.

I was told this by Apple when I brought up the problem through their “support” for the cellular drain issue.

For the record, so was I, but by a repair/data-wipe technician.

No but it would be nice to be able to selectively restore a subset of backups.

Backups should be able to be merged with data on the phone. The use case is I want to travel overseas but I don't want various border control entities to make copies of my phone contents, so I back it up and reset the phone to factory defaults. Then I go on my trip and take pictures and receive texts and etc. When I get home I should be able to merge the pre-trip backup and the during trip stuff into a single set of contents on my phone.

Is this how backups work with your personal computers?

Yes, if I do a full restore, I expect all files and settings to be restored, including bugs present at the time the backup was made.

iOS backup apparently doesn't work like you described. E.g., when restoring a backup from iOS 14, it doesn't revert your system to iOS 14. Clearly there's a separation of restoring the executables and restoring the configs.

I do expect "the config/setup that would trigger a battery drain in <iOS X" to be restored, but Apple can always fix iOS so that the same config/setup won't break >=iOS X.

If you do a full restore implies that you don't have to do that.

And yeah as the other commenter said, that's not really how the ios one works.

> This bug was initially reported on August 10th

They had plenty of time. You did the right thing by disclosing.

Uh.

I wonder if this can still be triggered when the Home application has been removed from the device? I expect so as IIRC builtin-in application removal is really just hiding them and all the functions are part of priviledged bundles shipped with the OS.

Built-in apps are merely frontends, the actual functionality is tightly integrated into the OS in the form of daemons running in the background. I very much doubt removing the frontend app disables any of the daemons, especially considering these can be used to provide APIs that apps may rely upon.

> all the functions are part of privileged bundles shipped with the OS

Luckily a lot of these can be disabled when jailbroken: https://i.imgur.com/KhGmGrf.png

It's unfortunate that you need to exploit a (different) vulnerability in order to gain full control of your devices.

What app is that?

I tried to get into cydia and such as of late, and it's a confusing ecosystem, you need to find specific marketplace links from github to browse and then alot of stuff is very legacy and not organized.

Would love to jb but it is complicated.

It's iCleaner Pro. Here's the repo you can add in Cydia: https://ib-soft.net/

Thank you! :)

What is it with iOS and string parsing bugs? First it was iMessage content then it was SSIDs now it's LAN device names? Oof

This is not a parsing bug, it is just some component crashing because of a name that is too long. Not very nice, but considering the source of the name any exploitation scenario is very unlikely and this is incomparable to bugs that allow code execution.

This looks nasty, I hope they patch this soon.

Why didn’t they add a string limit?

Perhaps the limit was "available memory"? It's not hard to imagine how a programmer who has only ever worked with dynamic languages and basically doesn't know what a fixed-length-buffer is could be completely oblivious to it.

Then again, what is an appropriate limit on the length of the name of a HomeKit device? I'm tempted to say 255, but I'm sure someone else would disagree. I've been in design meetings where such things were discussed, with lots of bikeshed, so it's also understandable that, with deadlines and other priorities, they decided not to impose any limit.

I can't imagine anyone would disagree with 1024 characters.

"But that doesn't fit in a byte; why not make it 64k instead so it's 2 bytes?"

"Why not 1023?"

"Even 1023 is too long, I don't think anyone would need that."

"What if <long and convoluted use-case>?"

"How about 32?"

Having been in a few meetings that went in that direction, I am not surprised that they couldn't agree on a limit. "Design by committee" at its worst.

I doubt it even went that far - given the size the story mentions (500,000 characters, but isn't clear if they tried smaller), my thinking is the programmer didn't make any checks whatsoever and just thought "no one will type in crazy-large values here, and even if they do it'll just truncate on display" (if that) without consideration on how it might affect memory.

Another team that didn’t read nor adapted practices from About Face : on interaction design. What the team wants is irrelevant, how the user will adopt it is important, and for that you need to actually do tests.

Don't know, but in general arbitrarily set limits are bad. Note, the bug is not in the long name. The bug is in the inability of system services to handle a long device name. That I imagine is hard to fix, but this is exactly what needs fixing. Limiting the name length is akin to band aid.

In theory I would agree, but in practice (which is different from theory, as the classic saying goes), I disagree; I have another comment here about the perils of debating limits, but I don't think designing the system to handle 500,000-character names would be a good thing either, because we know from experience that if something can be abused, it will. Needlessly making something "limitless" is an invitation to test that --- and in the real world, we know that there definitely are limits even if they are as volatile as "available memory"; and doing something like that is not good for reliability.

No arbitrary limitations.