Live data from Hacker News

iMessage: Malformed Message Bricks iPhone

bugs.chromium.org

31–40 of 279 posts

Re: iMessage: Malformed Message Bricks iPhone

#32
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.

Technical terms have meaning defined by actual technical usage regardless of common misuse by the less informed. Your entire tower isn't a cpu, a user recoverable device isn't bricked and if tomorrow most people start calling kidneys livers they will still be kidneys. Reducing bricked to a subjective statement about the users ability to use their device robs the term of all utility in the same way as calling a comput…

"Bricked" isn't a technical term; its basically just slang.

Re: iMessage: Malformed Message Bricks iPhone

#33

Genuinely curious: What’s the reasoning behind “unrestricting” this ahead of its 90 day window? (It’s tagged Deadline-90, Reported-2019-Apr-18 On Project Zero, so that’s July 18th?)

Because it's now fixed. The window is to allow the vendor to issue a fix.

Re: iMessage: Malformed Message Bricks iPhone

#34
This brings back old memories from hardening the sms/text parsers of feature phones of yesteryear.

There it wasn’t entirely uncommon that when you sent a malformed sms-deliver PDU (e.g. text message) to the phone and crashed parser that tried to decode it, it took also the phone down before it could ack the message back to SMSC. Which of course meant that as soon as phone was turned on and it registered to network, that same message was redelivered (crashing it again) for as far as the network was concerned, it was never received by the mobile. Until the time that message either expired in the SMSC in few days, or you switched you sim to a non-vulnerable mobile to receive the message. Good times.

Re: iMessage: Malformed Message Bricks iPhone

#35

Genuinely curious: What’s the reasoning behind “unrestricting” this ahead of its 90 day window? (It’s tagged Deadline-90, Reported-2019-Apr-18 On Project Zero, so that’s July 18th?)

It says:

> Unrestricting, as this was fixed in the 12.3 update.

Re: iMessage: Malformed Message Bricks iPhone

#36
post #19

Since a restore works it cannot be called a brick though?

It's a sliding scale which depends on the user's competence and not just the hardware. To a completely non-technical person, a hard lock-up is "bricked" even if it could be fixed by pressing buttons. To a normal user, a borked ROM is "bricked" even if it could be fixed by plugging into a computer and re-flashing. To a power user, a busted bootloader is "bricked" if it stops them flashing a ROM, even if it could be fi…

[deleted]

Re: iMessage: Malformed Message Bricks iPhone

#37
post #19

Since a restore works it cannot be called a brick though?

It's a sliding scale which depends on the user's competence and not just the hardware. To a completely non-technical person, a hard lock-up is "bricked" even if it could be fixed by pressing buttons. To a normal user, a borked ROM is "bricked" even if it could be fixed by plugging into a computer and re-flashing. To a power user, a busted bootloader is "bricked" if it stops them flashing a ROM, even if it could be fi…

This is a good way to describe the reality of "bricked", and I think you could extend this to consider price, too.

Even to the EE, the cost of parts and time to repair may exceed the cost of replacement, much like a car in a relatively minor accident can still be considered "totaled" if the repair cost exceeds its value. "Bricked" may still not be the right term, but the difference is irrelevant at that point.

Another consideration is there's a big difference to a user if the fix requires erasing all data, as the work required (after fixing) is then the same as getting a replacement. At the least, this is the effort of applying updates, restoring backups, then dealing with all the fiddly things that didn't update/reinstall/restore properly. At worst, it's irreplaceable data loss (and a hard lesson in why backups are important).

Re: iMessage: Malformed Message Bricks iPhone

#38
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.

Technical terms have meaning defined by actual technical usage regardless of common misuse by the less informed. Your entire tower isn't a cpu, a user recoverable device isn't bricked and if tomorrow most people start calling kidneys livers they will still be kidneys. Reducing bricked to a subjective statement about the users ability to use their device robs the term of all utility in the same way as calling a comput…

They weren't my words, so I'm not repeating myself. Just agreeing with the point that the term "brick" is subjective. Requiring one to go to heroic measures to render their device useful would make me consider the device "bricked" for all intents and purposes. Folks more technically skilled than I might be able to recover my device, but if I can't get it back, it's all bricked to me. But this is a silly argument.

Re: iMessage: Malformed Message Bricks iPhone

#39
post #28
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.

I think a fair in-between value on the "sliding scale" is calling a device bricked if it can't be recovered by a sufficiently advanced end-user without special hardware. If there is no way that an end-user could fix it without purchasing something or returning it to the manufacturer, it is bricked.

We can use it like when a car is "totalled". If it would cost the user more to fix the device (because they are nontechnical or need special parts) than the device is worth, then it is bricked.

Re: iMessage: Malformed Message Bricks iPhone

#40

Genuinely curious: What’s the reasoning behind “unrestricting” this ahead of its 90 day window? (It’s tagged Deadline-90, Reported-2019-Apr-18 On Project Zero, so that’s July 18th?)

Because it's now fixed. The window is to allow the vendor to issue a fix.

Yeah but maybe it would be nice for users to keep that extra time in order to maximize the probability that they have actually updated software at disclosure time.

Disclosing in advance is a bad policy, it will just incentive good behaving vendors that update fast to delay full description of their changelog for security reasons because you put their users at unnecessary risks.

Post reply on HN