[saagarjha]

Most iPhone attacks that users care about are those where attackers target sensitive user information and exfiltrate it–other ones don't really make sense on the platform. For this, typical attack vectors are a messaging app exploit (which is entirely outside of the control of Apple, FWIW), a web browser exploit coupled with a sandbox escape, or perhaps a bug in a Wi-Fi or Bluetooth driver; none of which typically require modifying kernel code in order to implement. The group of people that wants to patch the kernel, or extend it, is essentially nobody but security researchers and jailbreakers for whom the rationale to do something like this is often "because I should be able to do this". Thus, the feature is ineffective at addressing or preventing actual attacks that users care about and very effective at preventing people from tinkering with iPhones.

[pvg]

I think you're conflating 'attacks possible and thus more often seen in the wild' with 'attacks users don't care about'. People would very much care about exploits that become persistent if those happened.

[saagarjha]

Attacks against iOS that become persistent do not exist in the wild to my knowledge, nor did attacks that overwrote kernel text. They just do not exist because there is no reason to do this because it's substantially easier to find other things to exploit.

[pvg]

I just don't see how 'preventing such attacks is just to annoy jailbreakers' follows from any of this, though. Like, it's a narrative but the logic doesn't add up to me. There are really good reasons to also defend against complex attacks, attacks that require physical access, you name it. I don't want my iMessages leaking stuff because someone sent it a funny message, I also want my phone to remain reasonably secure if I hand it to a TSA agent.

[saagarjha]

Perhaps Apple has some sort of model where this is helping, but as it stands this makes the lives of security researchers and jailbreakers annoying and it does not close a hole that previous attacks were using (they are still using the same techniques!) Neither of your examples involve patching the kernel–the first is finding a bug in iMessage in userspace, and the second is handled by an entirely separate chip. My perspective is literally just "I want Apple to prevent exploits against my iPhone, and also not make jailbreaking worse for no reason" and this feature is "makes exploits no harder because no attacker cares that this exists" and "makes jailbreaking way more annoying". There's no balance between the two here, it's just negatives all around.

[pvg]

I didn't say either of these patched the kernel (one is in userspace, the other one is, well, you don't know where it since I didn't describe one) just that the difficulty and complexity of some potential exploit doesn't mean the exploit isn't important both to Apple and end-users.

You were arguing that some of Apple's mitigations are only aligned Apple's business interests and not those of end-users. I don't think you've said much to really show this is true, other than in your specific case. Not wanting the phone to be jailbreakable, to provide some assurance that when you buy an Apple phone, it's running Apple's software as designed by Apple and that it can't easily and surreptitiously replaced with something else is a perfectly reasonable consumer expectation very much in line with what Apple explicitly sells and promises of the product and services it comes with. The 'for no reason' bit just seems obviously inaccurate.