zlacker

>>Harvey+(OP)
The linked blog assures people that this can't be used to access data. Once something is crashing an app/OS, can you really say that? I mean, can you be sure there's no one clever enough to capitalize on the underlying software error leading to this state?

>>menaci+q9
That would be a general issue with app crashing, and a huge deal worth it’s own series of articles. iOS’ sandboxing makes it so unlikely this exists, it’s not worth mentioning and the sensational writing might be counterproductive to getting the actual issue fixed. To use an analogy, it’d be like mentioning that someone could hack Google in an article about Gmail downtime.

>>112358+2f
I see your point, but I actually think users should be _more_ alarmed when an input makes software crash, for just this reason. They tend to think of it as a harmless annoyance.

Also, while sandboxing may be designed to prevent this, Messages is probably also designed not to crash on link sharing.

>>menaci+Uf
There's far more risk in software not crashing when it gets malformed or otherwise unexpected input. If an application crashes, it's memory space has been relinquished and its execution process aborted. Yes, something could've been spawned, but... in general crashing when something unexpected comes up is more sensible, desirable behaviour.

(Or am I wrong? I'm not a professional programmer. I'm just reasoning from common sense.)

>>qubex+dC
You're not wrong. AgentME is correct, that crashes can be exploitable, but it is definitely more dangerous for software to continue after its data is corrupted.

The Erlang programming language, in fact, is built around the idea that as soon as you see data you don't expect, you crash, and an external process will start you back up in a known good state.