Really interesting development in the section titled "Crash Monitoring?":<p>> An interesting side effect of the new processing pipeline is that imagent is now able to detect when an incoming message caused a crash in BlastDoor (it will receive an XPC error)... As can be seen, imagent is apparently informing the iMessage servers that the message with the UUID 0x3a4912626c9645f98cb26c7c2d439520 (fU key) has caused a crash in BlastDoor. It is unclear what the purpose of this is without access to the server’s code. While these notifications may simply be used for statistical purposes, they would also give Apple a fairly clear signal about attacks against iMessage involving brute-force and a somewhat weaker signal about any failed exploits against the BlastDoor service.<p>> In my experiments, after observing one of these crash notifications, the server would start directly sending delivery receipts to the sender for messages that hadn't actually been processed by the receiver yet. Possibly this is another, independent effort to break the crash oracle technique by confusing the sender, but that is hard to verify without access to the code running on the server.<p>Apparently Apple has added the ability to detect crashes when parsing iMessages, report that data back to the mothership (with some attribution), and then mislead the sender of the likely malicious message with fake delivery receipts. This is cool on so many different levels.
It’s kind of great that we really as consumers get state of the art security on our devices especially on iOS, that’s constantly improving. Having a non-fragmented ecosystem can enable this.<p>Yes, Apple had embarrassing bugs on macOS but it’s been a steady march to democratize the best practices and put them behind elegant UX, like touch and Face ID with Secure Enclaves and secure boot.