I think, we fundamentally lack a mechanism to enforce secure / privacy aware APIs without resorting to trusted inner-circle type of things. I am already not comfortable with Apple picking winners (such as giving Zoom special entitlement but not the VOIP apps you want to distribute by your own). Apple trusting their own apps more than other apps is another symptom of this and it is not helping their anti-trust situation even if it is with good-will.
And "giving people choice" won't work neither because people will just tap whatever checkbox you give them (the internet should never forget that Facebook SDK just forces to accept "The App is Tracking You" notification and most users tapped yes).
Quicktime Player.app gets an entitlement called `com.apple.private.tcc.allow`, giving it unprompted access to the Camera, Microphone, and Screen Capture.
An MDM administrator, managing a computer or device owned by an organization, cannot grant those permissions to anything without user consent. For good reason!
So why the *fuck* does Apple think they're entitled to?
> So why the *fuck* does Apple think they're entitled to?
Because they manufactured the device, and you bought it?
And honestly, I support them. Because starting QuickTime is a user action, and it only records when I want it to. QuickTime is an app I trust.
I don't trust an organization admin not to record me without my consent. As we've heard the horror stories of schools spying on students with school laptops while they're in their own homes, their own bedrooms.
I trust Apple a whole lot more than I trust an org admin.
If you followed the Apple Security scene for a bit, you'll notice that a lot of exploits make use of special permissions granted to Apples own apps and services. If you find a way to run your code in Quicktime Player, or to control Quicktime Player, you can circumvent the privacy dialog.
Do you trust Quicktime Player to be free of exploitable bugs or behaviors?
> Do you trust Quicktime Player to be free of exploitable bugs or behaviors?
I trust they aren't there intentionally, and that they'll be patched in a security update as soon as Apple discovers them. In this regard, QuickTime is just part of the entire OS. No software is perfect. Bugs might be anywhere. But the permission dialogs are meant to protect the OS from third-party threats, not to protect the OS from Apple software.
Remember when people realized that Apple apps were bypassing application-level firewalls like LittleSnitch?
First it was denied, then it was a bug, then it was a "temporary workaround" while ... something ... was updated.
And that was just ... accepted as an answer. I could never fathom why TextEdit might need a kernel extension in the first place, let alone unfettered/unmonitored network access. I don't even think it was necessarily nefarious, just "we know best, shut up and buy".
Replace MDM administrator with ‘malware author’ or ‘spy software’ to get your answer. There is functionally no difference between a regular company doing MDM wanting to bypass camera permission prompts and a hacker who has tricked/forced the user into enrolling into MDM.
Now, replace ‘Apple’ with ‘malware author’. What’s the difference? Well, for one, a hacker has nothing to lose and everything to gain from snooping on your webcam. Meanwhile, if Apple mishandles this permission or used it to beam video data to HQ, there’s a high likelihood hundreds of millions of dollars of iPhone or Mac customers are lost, resulting in billions of dollars in stock value loss.
It's not very trivial to manage an Apple device and Apple would shut down those ABM tenants real quick. Not to mention, supervision requires enrollment pre-setup, which is really difficult.
So "just replace x with y" does not really work in this context, MDM is vastly more effort than you think and OP-s point still stands.
MDM is not easy but you can enroll devices after the fact, pre-enrollment isn’t the only option. But yes, it’s a PITA to deal with even at the best of times.
Ahh, maybe I’m mistaken or maybe iOS works differently. I believe you can enroll it in MDM and then you have 30 or 60 days to kick it out at any time and then it becomes fully locked in. Or perhaps I have my terminology wrong. I only scratch the surface of MDM at my company.
This is more to do with ABM - you can add a device to ABM that wasn’t put there by a reseller/vendor/Apple. This also enrols the device, and removing the enrolment in the first 30 days also removes it from ABM again.
After the 30-day period, the enrolment profile cannot be removed on the device-side. This workflow applies for both iOS and macOS.
On macOS the enrolment is supervised either way. You can also get a supervised enrolment on an iOS device that isn’t in any ABM instance - there is more than one path to supervision.
Think about why they ask for access in the first place - it's because camera access or screen access might be unexpected for the app you've just started. Or maybe you don't trust the app with your camera (looking at you, Instagram).
QuickTime Player is already on your Mac and you already know what it does when you launch it.
There are millions of ways you implicitly trust Apple software to not violate your trust when you use their products. The whole point is Apple can gauge whether it is appropriately stewarding that trust in first party code much better than it can with third party code.
I guess that's fair, because the name says Player. But still, the way to not use those features is to not use those features. Unlike a third party app you don't need to worry about it trying to read your screen if you haven't explicitly started a screen recording. If you can't trust Apple to do that then you can't trust Apple to block third party apps from recording, either.
Security boundaries are for more than intentionally bad apps, but things like bugs causing code execution or other ways of abusing their privileged position.
An app decoding complex untrusted media files from the internet? It should have the absolute minimum permissions.
That's not the problem Apple was trying to solve here.
I suppose I could see a system where every camera/screen recording access by QuickTime Player forces a popup, because you can't say whether it happened intentionally or due to opening a malicious video file, but that would have to be opt-in for sure.
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.
Because to activate apple's device (not yours), you had to read 1000+ pages of terms and conditions (did you?) and they told you this somewhere in there.
And "giving people choice" won't work neither because people will just tap whatever checkbox you give them (the internet should never forget that Facebook SDK just forces to accept "The App is Tracking You" notification and most users tapped yes).