Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iMessage: Malformed Message Bricks iPhone

bugs.chromium.org

Post reply on HN
Print view View original

51–60 of 279 posts

Re: iMessage: Malformed Message Bricks iPhone

#51

Post by dmitriid »

mholt wrote: post #50

With ALL their infinite resources, how are Apple's bugs SO BAD. Like, repeatedly. goto fail, Facetime surveillance, empty password grants root access, and now this. As much as Apple touts privacy and security, this is not a great track record. The more resources a company has, the less forgivable serious bugs like this are. I need to keep reminding myself: Apple is a hardware company, not a software company.

> With ALL their infinite resources, how are Apple's bugs SO BAD.

Infinite resources do not easily translate to quality for many many reasons.

The main being: we’re just human, and we suck at managing large projects at scale.

Re: iMessage: Malformed Message Bricks iPhone

#52

Post by saagarjha »

EugeneOZ wrote: post #47

Lazy developers throw exceptions, good developers return errors. Exceptions should be exceptional. I'll use URL to this bug in my next comment-holywars to prove this point. Yes, it takes much less code to throw an exception in hope some code will catch it, but while compiler (not runtime) doesn't check it - this technique is not safe. So we should return errors, check them and handle - sometimes it means returning er…

Lazy developers also ignore errors by swallowing them. In this particular case, note that the error was detected many methods away because of Objective-C's weak typing, not because the developers "chose" to throw an exception.

Re: iMessage: Malformed Message Bricks iPhone

#53

Post by ec109685 »

EugeneOZ wrote: post #47

Lazy developers throw exceptions, good developers return errors. Exceptions should be exceptional. I'll use URL to this bug in my next comment-holywars to prove this point. Yes, it takes much less code to throw an exception in hope some code will catch it, but while compiler (not runtime) doesn't check it - this technique is not safe. So we should return errors, check them and handle - sometimes it means returning er…

Crashing a program is often safer for unexpected conditions than hoping your error handling will recover from it?

Have you tested every combination of state + error and made sure your app is robust for each situation?

Re: iMessage: Malformed Message Bricks iPhone

#54

Post by Razengan »

Can this be avoided by disabling iMessage notifications?

> The calling method then calls -[IMBalloonPluginDataSource _replaceHandleWithContactNameInString:] which calls im_handleIdentifiers on the 'NSString' which is really an NSNumber, which throws an exception as the selector does not exist in that class.

Looks like they need to move more of their stuff to Swift to reduce snarfles like this.

Stories like these (this isn't the first time that iOS/macOS could be crashed by chat messages), and the empty root password debacle, or all the GateKeeper bypasses, make me wonder if their engineers take their own WWDC security-related talks seriously.

Still, it's not so bad as the Windows XP-7 epoch, when eldritch nightmares walked the land.

Re: iMessage: Malformed Message Bricks iPhone

#55

Post by zaroth »

slyrus wrote: post #22
zaroth wrote: post #21

Earlier quoted context omitted.

The only purpose of the word’s existence is to define an entirely unrecoverable state. Crash loop or hung on startup describes the state. It is by definition not bricked if it can be recovered.

It's almost like the author of the above comment (zaroth) didn't read the parent comment. Put another way, bricking is in the eye of the beholder.

“Difficult [for someone] to recover” should not be a partially overlapping state as “bricked”.

I had a EdgeMax Lite router which has a propensity for the flash storage to get corrupted at which point it fails to boot. The fix is to buy a particular model of USB flash drive, and image it with a specific .img file. Open the case and replace the flash stick, then boot holding the reset button.

It was a somewhat difficult repair, but in the end just a matter of following step-by-step instructions with readily available tools. I would not consider the device to have been bricked. No more than your computer is bricked when your hard drive dies.

I did brick an Xbox once, trying to solder on an early gen mod chip that was well beyond my soldering abilities!

In this case it’s not even a question of hardware damage. The fix is to reset to factory, upgrade, and restore. This is the happy path recovery process which has done millions of times over on iPhones. I had to do it just a couple weeks ago when my son changed the PIN on an iPhone we use to play music on, and then promptly forgot the new PIN. (He’s 7)

With the proposed meaning, everything is a brick to the technologically illiterate. Better to admit the headline is simply sensationalizing / clickbait.

Re: iMessage: Malformed Message Bricks iPhone

#56

Post by read_if_gay_ »

peterkelly wrote: post #41
floatingatoll wrote: post #17

Earlier quoted context omitted.

You only lose data if you’re not backing up your phone - it’s not a corruption bug that breaks the ability to restore backups (like one of the iOS iOS 11 developer betas did).

That's like saying that with a faulty hard drive you can only lose data if you're not backing it up.

Well that’s not wrong.

Re: iMessage: Malformed Message Bricks iPhone

#58

Post by kennywinker »

EugeneOZ wrote: post #47

Lazy developers throw exceptions, good developers return errors. Exceptions should be exceptional. I'll use URL to this bug in my next comment-holywars to prove this point. Yes, it takes much less code to throw an exception in hope some code will catch it, but while compiler (not runtime) doesn't check it - this technique is not safe. So we should return errors, check them and handle - sometimes it means returning er…

This error is due to use of a un type checked language (objc). You can blame the coding style all you want but it’s like blaming bad drivers for accidents instead of fixing the system.

Re: iMessage: Malformed Message Bricks iPhone

#59

Post by Dylan16807 »

zaroth wrote: post #55
slyrus wrote: post #22

Earlier quoted context omitted.

It's almost like the author of the above comment (zaroth) didn't read the parent comment. Put another way, bricking is in the eye of the beholder.

“Difficult [for someone] to recover” should not be a partially overlapping state as “bricked”. I had a EdgeMax Lite router which has a propensity for the flash storage to get corrupted at which point it fails to boot. The fix is to buy a particular model of USB flash drive, and image it with a specific .img file. Open the case and replace the flash stick, then boot holding the reset button. It was a somewhat difficul…

Not a brick if you have to replace a storage device. Is it a brick if you have to replace a motherboard? Would replacing a motherboard not have fixed your xbox? (Surely the commercial availability of a part isn't the deciding factor in whether something is a brick, right?)

Re: iMessage: Malformed Message Bricks iPhone

#60

Post by zaroth »

taneq wrote: post #24
zaroth wrote: post #21

Earlier quoted context omitted.

The only purpose of the word’s existence is to define an entirely unrecoverable state. Crash loop or hung on startup describes the state. It is by definition not bricked if it can be recovered.

And as my post illustrated, "unrecoverable" is entirely relative to the user's capabilities. There's no such thing as "entirely unrecoverable" to a suitably equipped and motivated person, although you get into a Ship-of-Theseus situation if enough hardware needs replacing.

There’s a fairly meaningful distinction between replace, repair, and recover.

In this case we can recover the phone without replacing any hardware at all, so bringing up repair or replacement is a bit of a red herring.

But as I recall, Theseus’ ship was repaired over so many battles, nothing of the original remained. That is distinctly different than botching a single repair so badly you would have been better off replacing from the onset.

There are plenty of ways to get plenty of hardware into an obviously FUBAR state. It’s simply false to say that there is no such thing as a definitively bricked state for any device whatsoever.

Simple rule of thumb; if the commonly accepted solution is “get a new device” then you’ve probably bricked it.

Absolutely no one will have to buy a new iPhone because of this bug.

Post reply on HN