EDIT: As far as I know, the best long-term answer here is for apps that present visuals full screen to "capture" the external display for exclusive use using an API (https://developer.apple.com/documentation/coregraphics/14562...), but that's not super common right now.
> As far as I know, the best long-term answer here is for apps that present visuals full screen to "capture" the external display for exclusive use using an API...
If I'm understanding you correctly, that means there's already a supported workaround for this if apps just use that API? I don't want to downplay the annoyance of this for apps that aren't using that API, but this suggests there's already an official answer.
I'm mildly surprised the orange dot shows up in full-screen apps; I was going to suggest that might be the easiest "fix" for Apple to make that doesn't require either adding a new security setting or taking away the indicator entirely -- have it only show up in the menu bar, and not when the menu bar isn't present.
I'd like to ask a follow-up also as I don't do any Mac dev, but has this API been around for a bit then? Like Monterey has been out for a bit and it's a little surprising that this article and the subsequent discussion is only popping up now, especially if there is an API answer to it already.
I ask earnestly if the change is really such a substantial one?
I have mixed feelings after reading the comments as I think that there are fairly valid arguments in both directions (e.g., that the solutions are plentiful, but also that workarounds aren't really a solution), but the arguments feel a bit empty if there's a "right" way to be handling the visuals that just isn't being used.
As a user I like the change in general as I have caught naughty applications that try to use mic input when I really don't want it, and my misclick/absentmindedness is not uncommon, so seeing such things helps a lot as I don't really think it's reasonable to constantly be checking the various app permissions to make sure they're what I want. This is a good reminder for me.
But I totally get not wanting the dot, as it's even been a prank on a site I go to to have a tiny red pixel just to annoy people (and it's a prank I've used). So I get the frustration with an unexpected visual. But, if there's a way to do the same activity by having the app utilize the correct API, it seems like an issue that is solved in the next update from these visual production apps, no?
CoreGraphics and the associated screen capture APIs have been around for a very long time. However they aren't particularly easy to use and do require your app to be trusted (reasonably so). You can't have just any old Mac app start capturing the screen and doing things with the pixels.
Why would you think that? The CGDisplayCapture function that the GP linked includes a "display ID" keyword to specify a specific external display, like a projector or a screen. Why wouldn't it work?
Is that really all it takes to disable this? I guess if I'm a malware author looking to do surreptitious recording, I'll have to bundle these extra 10 lines of code lol...
You can, but note that as a user you have to open System Preferences and check a checkbox to allow said malware to do this. (Apple locked down the accessibility APIs that let apps easily manipulate each other a few years ago.)
The user has to manually open System Preferences and allow this program all the same. One place where this workaround would work for malware is embedding in apps that are expected to need these rights though.
On my machine, Dropbox, Alfred, BetterTouchTools, and Bartender have this permission. Zoom is in the list of apps that can be given this permission, but the permission is disabled by default and Zoom works fine without it - though the very fact that some may have given this permission to Zoom might be a cause of alarm! And it's possible Apple may patch away the ability of accessibility tools to mess with this, without giving a better system-level way to disable it...
If I had to guess Zoom is probably using the accessibility API to implement their remote control feature. I don't know enough about the other apps to guess why they need it, but dropbox needing accessibility permissions does sound strange.
The security agencies would pay good money for a solution that bypasses this requirement. They were paying good money for exploits that disabled the tally lamp on web cams.
I mean, I’d take advantage of that program. If it’s already installed then it probably has the permissions granted. So I’d only have to run it before recording audio.
That you built this in such a short span of time is impressive, and really does a great job undercutting the “security” reasons for the dot to be there.
I don't think this undercuts the security reasons. I think the general idea is that if you leave Zoom / FaceTime / OBS open and recording, the orange dot is there. Same dot, same place, no matter what app you are using, as long as the developer doesn't disable it.
Using the API to disable the dot requires some pretty scary permissions to be enabled on the app disabling the dot.
Yes, exactly. I'm sure there are more elegant answers — plus watching events so that it can hide the window right away instead of running in a loop — but I haven't used the accessibility APIs much lately and this is the first working approach I found.
On vacation and no laptop, but perhaps someone can add better readme directions to the patch.
To us software folks, I t makes sense, but I imagine this'll be linked to many individuals outside of software who won't know even what git is or how to get the fix.
https://github.com/s4y/undot
EDIT: As far as I know, the best long-term answer here is for apps that present visuals full screen to "capture" the external display for exclusive use using an API (https://developer.apple.com/documentation/coregraphics/14562...), but that's not super common right now.