5 ms·
I have no knowledge of apple's decisions here, and no experience with iOS, and you're generally correct that any sort of batch processing should be able to reco
by charleslmunger 8y ago
I have no knowledge of apple's decisions here, and no experience with iOS, and you're generally correct that any sort of batch processing should be able to recover from bad input, but I'll try to make an argument as to why this isn't as simple as it sounds.
1. Creating a graceful degradation path is a complicated and expensive, from a UX, product, and testing perspective - if you silently drop the message, that's much worse than crashing; if you insert some sort of tombstone "this message could not be parsed" into the UI, you have to figure out if that's something users will actually understand. These code paths are hard to exercise with normal integration or manual testing, and it's likely that over time they may stop working correctly.
2. Monitoring graceful degradation is more complicated than tracking crashes, especially for unforeseen issues like what you're describing. There's a real risk that if this periodically showed up with "failed to parse" messages, the actual issue would have remained undiscovered by Apple a lot longer.
3. Again, no familiarity with iOS, but on other mobile operating systems I've worked with there's a significant memory overhead to using multiple processes and IPCs this way. If your device is under memory pressure, the extra cost of a pipeline like this introduces new failure modes. First, your other process may be killed by the LMK, which the sender process could interpret as being a failed message. Second, you may increase the amount of memory required to receive a text message in the background - this can directly affect critical high-memory use cases like taking a live video with the camera. There may just not be enough room to do both at the same time.
4. There's significant input processing that can't be done in another process, or meaningfully isolated from that of other messages - the best example being UI rendering of the text. If there's a magic string that causes view measurement to fail, that's extremely difficult to attribute to any specific piece of input - so adding this extra process to do validation won't really help you, since the "validated" string will fail later on.
- stcredzero 8y ago1. Is probably a lot more desirable than the smartphone OS looking like trash, requiring a reboot. iOS has suffered epidemics of people trolling by sending out messages that crash processes on other's phones. 2. Since this has happened several times at this point, the point is moot. Since this is familiar territory, why not log it and have the system tell HQ something weird happened? 3. May have been true in the past. Very doubtful at this point. 4. Irrelevant. The process can have the UI, crash, then be restarted by the other process. There is no validation done by the other process. The 2nd process only detects that the 1st process has crashed, then removes the offending datum from the queue.
- Retric 8y ago> 2. Since this has happened several times at this point, the point is moot. Since this is familiar territory, why not log it and have the system tell HQ something weird happened? This has real privacy considerations. I would rather Apple not simply get a message sent to me forwarded to them. Is the trade off worth it in this case? That's not so easy to pick for all ~1/2 billion or so users.
- stcredzero 8y agoI would rather Apple not simply get a message sent to me forwarded to them. Is the trade off worth it in this case? That's not so easy to pick for all ~1/2 billion or so users. All Apple would need to get is the notification that there was a crash. It could be left to the user if the crashed message gets forwarded.
- bpchaps 8y agoWhat sort of useful information would that even provide? It would just show that the system crashed because of a text. You'd still have to send some sort of contextual information about the text, which itself would carry non-metadata information about the text (ie, components of the text's contents).
- MaulingMonkey 8y ago> (ie, components of the text's contents) Which may then crash the prompt asking if it can send the crash...
- stcredzero 8y agoJust send the metadata and the hex dump.
- stcredzero 8y agoWhat sort of useful information would that even provide? If it's a widespread attack, then the traffic analysis would still be useful. A hex dump of the offending data could be sent.
- kayamon 8y agoAre you seriously making the argument that a program reading untrusted data off a network should crash if it can’t parse the data? Programs should never, EVER crash. If you can’t decide/handle a Unicode codepoint, replace it with a question mark (or box etc) and carry on. And yes, a big-name program like iMessage absolutely should have unit tests for this. I can’t believe I’m having to explain this.
- xenadu02 8y agoI suggest you research font formats and the code required to render arbitrary unicode code points with case folding, reflow, ligatures, stacking, bidi, combining marks, etc. TrueType and OpenType are turing-complete all by themselves. There are nearly 140,000 Unicode code points; exhaustively testing the combinations is computationally infeasible. It is the definition of a decidedly non-trivial problem. Furthermore layout passes often involve hundreds or even many thousands of string measurements. Every platform has had numerous bugs, including exploitable ones, in font and string handling.
- eridius 8y agoThe problem isn't with parsing the data. The problem is with triggering pathological cases in the complicated beast that is font rendering. And rendering text is something that's so extremely common in apps, and so crucial, that it needs to be done in-process in order to avoid unacceptable overhead.
- zoul 8y agoPrograms should never, EVER crash. Oh yes they should. If, for example, the alternative is to continue in an undefined state, potentially corrupting user data. Not all error conditions are recoverable.
- feanaro 8y agoThe right question to ask yourself is why this is the only alternative. It almost never is, if the program is properly designed, especially for a user-facing application.