I mean the reason is because Apple, the people who made the security boundary, and Apple the people who made Quicktime are the same people.
I'm not saying it's not anti-competitive but it's fine from a security context. Apple knows exactly how Quicktime behaves, that it doesn't act maliciously, and can't be updated to do so.
> Apple knows exactly how Quicktime behaves, that it doesn't act maliciously, and can't be updated to do so.
Yes, it's physically impossible for an Apple developer to accidentally or maliciously introduce an exploit into QT and for it to elude security or code review...
I've never heard a security posture that is "well, we know what your tool does, so it doesn't need any security controls".
I'm sure that could happen, but it's not really any different than exploiting some other part of the system. You make a fine case that the nature of this code means it will likely be under less security scrutiny than such an entitlement warrants but that's Apple's problem now.
> well, we know what your tool does, so it doesn't need any security controls
This really isn't that weird. The camera app doesn't need to ask for permission to use the camera/mic. And the why is because the thing you're worried about is some random 3rd party app capturing audio/video without the user's knowledge or intent. You know the built-in camera app doesn't do that because you wrote it, so it's fine to give it an entitlement to bypass the usual prompts. It can also access your photos without prompts because the threat model is malicious exfiltration and again, you know it doesn't do that.
I'm not saying it's not anti-competitive but it's fine from a security context. Apple knows exactly how Quicktime behaves, that it doesn't act maliciously, and can't be updated to do so.