I don’t really understand the thing people are trying to do here. The dot is a security feature. Any method which lets you hide it, move it, stop it is going to be treated as as security issue and fixed, because anything that can be exploited for sake of removing the dot from your screen recording can also be exploited by an attacker who wants to surreptitiously access the microphone. So the answer to whether it’s possible to hide the dot should always be “no” or at most “if there is a method, that method will go away very soon”.
So the answer to whether it’s possible to hide the dot should always be “no”
“Security” fails to be effective when it’s unwanted or gets in the way. The answer to whether it’s possible to hide the dot should be more nuanced than that. If people have to turn off SIP or use a different device entirely then the security is self-defeating.
Also the word itself “security” can be misleading. There are many different types of security with very different motivations. When a company uses the words “user security” they usually mean “our business security”; because if they face a decision between actual user security and something that affects their business security they will always still choose the latter (and try to brand it as user security). Hence the mass collection + sale of user data (“we protect your data from unauthorised access”), walled gardens (“you cannot install apps outside our store”) and closed source security software (“you are not allowed to reverse engineer this or change this”).
This dot sounds like a good idea with a bad implementation. A hardware indicator LED would fix all of the problem from all worlds (doesn’t affect video capture, doesn’t need extra work obfuscating APIs if implemented in kernel space, user can cover it easily if desired). A software dot that can be user-disabled more easily might also be a better compromise, otherwise a certain set of users will have to turn off SIP entirely or use a non-Mac device to do their work, thus invalidating all of the user security this feature intended to add (and possibly a bit more).
A business decision was made to do the dot the current way because it is cheaper and simpler, not because it’s the best for user security.
On a desktop Mac, a hardware LED wouldn’t really work because there is no internal microphone, and the machine can be put in a cupboard or something out of sight. A software approach works with external microphones and monitors.
“Security” fails to be effective when it’s unwanted or gets in the way. The answer to whether it’s possible to hide the dot should be more nuanced than that
The other part of this thread suggests that it is in fact relatively easy to turn off, just at the “cost” of also not getting the menu bar or window decorations. Which, for the full-screen-content use case that supposedly requires turning off the dot, seems perfectly reasonable to me.
I haven’t seen anyone make a case for wanting to turn off the dot and keep the menu bar/decorations visible.
CGDisplayCapture? That doesn’t sound like something a user can use, only an app developer, which means in practice the user still have to disable SIP to work around this issue (?)
Perhaps in a perfect world all apps would now do this, but that never happens in practice. You can’t rely on every independent making the same voluntary decision. It would be better that the problem didn’t exist in the first place.
People only seem to want this to happen when doing certain types of full-screen presentations. So it would make sense to me that the apps which do those full-screen presentations should use the API, accepting that it removes the menu bar, etc. (since the presenter almost certainly wants that stuff invisible too).
I’m not sure I understand what use case you’re trying to talk about where it’s necessary to turn off the dot in other circumstances.
Streaming games. Old software that no longer gets updates. Lots of fullscreen software the the developers will not change anyway.
Rather than putting the onus on app developers: it would more be more effective (and secure) overall to not make this problematic scenario in the first place. Don’t make users have to disable other security protections just to remove an overlay from their screen.
CGDisplayCapture is not a new API, it’s been the (only) documented way of doing full-screen applications since 10.0. I used it when I wrote a PDF presentation app for Beamer presentations almost 20 years ago.
it’s been the (only) documented way of doing full-screen applications since 10.0.
That is not true. Apple’s very own “Capture Displays” article notes that you don’t have to capture the display to do full-screen drawing, and that you may very much avoid doing so because capturing the display disables windowing features, like cmd-tab (and means you don’t have to worry about issues like display mirroring and friends).
In fact, not capturing the display is the default operating mode of toolkits like cocos2d.
Especially when there is a documented way to do it (per that HN thread linked), which makes sense in the context of visual displays - grab exclusive fullscreen on a display with CGDisplayCapture.
The issue is that CGDisplayCapture requires the app handle everything in fullscreen. e.g. you can’t just have a window that the user can resize/maximize, and have to do a bunch of work to manually go fullscreen. The once in fullscreen (with CGDisplayCapture) a bunch of other system services aren’t accessible (no menu bar, no window title bar, etc) so you now have to manually support those user interactions. I’m also not sure if cocoa works in a captured displays - e.g. does your visualizer or whatever now needs you to introduce your own ui toolkit?.
The once in fullscreen (with CGDisplayCapture) a bunch of other system services aren’t accessible (no menu bar, no window title bar, etc) so you now have to manually support those user interactions.
The post claims that the use case is things like videos/presentations where even just the dot would mar the illusion of a blank full screen with the content on it. So I’d imagine that use case would not consider it a bug that they also don’t get menu bar, window title bar, etc.
On macOS, a full screen window does not have any of those unless you move the mouse to them, at which point they become visible and usable. This is a normal and commonly used app behaviour.
Again, though, if the use case is, effectively, “I require an absolutely pristine blank canvas on which to project my full-screen content, such that even a small dot in the corner is ruinous”, then they’re not going to do things to trigger the menu bar, window decorations or other “superfluous” stuff.
The issue though is that with the screen captured nothing window management works, which gets into a rather inconvenient territory where you can’t even use screen mirroring (unless the application handles it itself) or tab out to a different application.
As a result, lots of applications don’t support CGDisplayCapture at all, because it’s a development burden for something that’s largely unusable in normal contexts.
So, how many times a day do you, personally, do something that A) requires the microphone on and B) needs to have full screen video capture and C) becomes absolutely useless to anyone for any purpose if the microphone-indicator dot is visible in the menu bar?
The dot is an utter annoyance, especially if one does not care if one is being recorded or not - in a live performance situation, for example - and there is no way to get rid of it from screen recordings, or during playback of art requiring as blank a screen as possible in some way.
What the dot needs, just like all the other annoyances that get treated this way, is a means by which to hide it intentionally, i.e. in one syspref, the dot hides shortly after recording is activated (for those paying attention and knowing that is how it is configured), in another syspref, the dot is ‘permanent’ - i.e. the truly paranoid, and in the last, the dot is simply not there and the user is on their own for microphone security, i.e. duct-tape.
That it is permanent no matter the best efforts of well-intended users is a frustration; that it can be disabled on non-SIP-enabled machines is not a solution; better user-friendly sysPrefs are required, but then again see also: Accessibility.
and there is no way to get rid of it from screen recordings
For situations where you truly need a blank canvas and even the small dot being visible would ruin the effect, there is – according to multiple people in this thread – an API that apps can use to get a full-screen with absolutely no decorations, dots, or anything else.
What the dot needs, just like all the other annoyances that get treated this way, is a means by which to hide it intentionally, i.e. in one syspref
No, not every single thing in every operating system needs a checkbox to toggle it on/off. Especially not security features.
We live in a world where big sites like Facebook have to log a scary console warning to people who open the browser dev tools, because malicious actors can literally talk ordinary users into opening the dev tools and voluntarily pasting in the code that will pwn their accounts. An easily-removable microphone indicator will be easily removed by malicious actors in exactly the same way, so putting it behind SIP, which is more effort to tinker with and can show big scary warnings to users, is an acceptable choice.
It’s a security feature in the same way that the green “camera is on” light is a security feature even though the light means the camera is already on and recording. In both cases, the indicator’s purpose is to tell you that something is recording, because you might not otherwise have known (say, because malicious code had surreptitiously turned on your microphone and/or camera).
In this case it is possible with the user’s consent. Sure, there’s no built-in checkbox, but disabling SIP is effectively a big override switch saying “I want to do some unsupported mucking about, please disable the extra security features for me.”
It’s true Apple doesn’t include a checkbox for every conceivable option… but that doesn’t make them evil. Disabling SIP will let you do whatever you want to the machine, and make any tweak that you like–including replacing the OS with Linux if you want.
On the other hand, I agree that having to disable SIP is a huge hammer even if you want to disable some security items for some time (e.g. a few hours).
I don’t really understand the thing people are trying to do here. The dot is a security feature. Any method which lets you hide it, move it, stop it is going to be treated as as security issue and fixed, because anything that can be exploited for sake of removing the dot from your screen recording can also be exploited by an attacker who wants to surreptitiously access the microphone. So the answer to whether it’s possible to hide the dot should always be “no” or at most “if there is a method, that method will go away very soon”.
“Security” fails to be effective when it’s unwanted or gets in the way. The answer to whether it’s possible to hide the dot should be more nuanced than that. If people have to turn off SIP or use a different device entirely then the security is self-defeating.
Also the word itself “security” can be misleading. There are many different types of security with very different motivations. When a company uses the words “user security” they usually mean “our business security”; because if they face a decision between actual user security and something that affects their business security they will always still choose the latter (and try to brand it as user security). Hence the mass collection + sale of user data (“we protect your data from unauthorised access”), walled gardens (“you cannot install apps outside our store”) and closed source security software (“you are not allowed to reverse engineer this or change this”).
This dot sounds like a good idea with a bad implementation. A hardware indicator LED would fix all of the problem from all worlds (doesn’t affect video capture, doesn’t need extra work obfuscating APIs if implemented in kernel space, user can cover it easily if desired). A software dot that can be user-disabled more easily might also be a better compromise, otherwise a certain set of users will have to turn off SIP entirely or use a non-Mac device to do their work, thus invalidating all of the user security this feature intended to add (and possibly a bit more).
A business decision was made to do the dot the current way because it is cheaper and simpler, not because it’s the best for user security.
On a desktop Mac, a hardware LED wouldn’t really work because there is no internal microphone, and the machine can be put in a cupboard or something out of sight. A software approach works with external microphones and monitors.
Good point.
The other part of this thread suggests that it is in fact relatively easy to turn off, just at the “cost” of also not getting the menu bar or window decorations. Which, for the full-screen-content use case that supposedly requires turning off the dot, seems perfectly reasonable to me.
I haven’t seen anyone make a case for wanting to turn off the dot and keep the menu bar/decorations visible.
CGDisplayCapture? That doesn’t sound like something a user can use, only an app developer, which means in practice the user still have to disable SIP to work around this issue (?)
Perhaps in a perfect world all apps would now do this, but that never happens in practice. You can’t rely on every independent making the same voluntary decision. It would be better that the problem didn’t exist in the first place.
People only seem to want this to happen when doing certain types of full-screen presentations. So it would make sense to me that the apps which do those full-screen presentations should use the API, accepting that it removes the menu bar, etc. (since the presenter almost certainly wants that stuff invisible too).
I’m not sure I understand what use case you’re trying to talk about where it’s necessary to turn off the dot in other circumstances.
Streaming games. Old software that no longer gets updates. Lots of fullscreen software the the developers will not change anyway.
Rather than putting the onus on app developers: it would more be more effective (and secure) overall to not make this problematic scenario in the first place. Don’t make users have to disable other security protections just to remove an overlay from their screen.
CGDisplayCapture is not a new API, it’s been the (only) documented way of doing full-screen applications since 10.0. I used it when I wrote a PDF presentation app for Beamer presentations almost 20 years ago.
That is not true. Apple’s very own “Capture Displays” article notes that you don’t have to capture the display to do full-screen drawing, and that you may very much avoid doing so because capturing the display disables windowing features, like cmd-tab (and means you don’t have to worry about issues like display mirroring and friends).
In fact, not capturing the display is the default operating mode of toolkits like cocos2d.
Especially when there is a documented way to do it (per that HN thread linked), which makes sense in the context of visual displays - grab exclusive fullscreen on a display with
CGDisplayCapture.The issue is that CGDisplayCapture requires the app handle everything in fullscreen. e.g. you can’t just have a window that the user can resize/maximize, and have to do a bunch of work to manually go fullscreen. The once in fullscreen (with CGDisplayCapture) a bunch of other system services aren’t accessible (no menu bar, no window title bar, etc) so you now have to manually support those user interactions. I’m also not sure if cocoa works in a captured displays - e.g. does your visualizer or whatever now needs you to introduce your own ui toolkit?.
The post claims that the use case is things like videos/presentations where even just the dot would mar the illusion of a blank full screen with the content on it. So I’d imagine that use case would not consider it a bug that they also don’t get menu bar, window title bar, etc.
On macOS, a full screen window does not have any of those unless you move the mouse to them, at which point they become visible and usable. This is a normal and commonly used app behaviour.
Again, though, if the use case is, effectively, “I require an absolutely pristine blank canvas on which to project my full-screen content, such that even a small dot in the corner is ruinous”, then they’re not going to do things to trigger the menu bar, window decorations or other “superfluous” stuff.
The issue though is that with the screen captured nothing window management works, which gets into a rather inconvenient territory where you can’t even use screen mirroring (unless the application handles it itself) or tab out to a different application.
As a result, lots of applications don’t support CGDisplayCapture at all, because it’s a development burden for something that’s largely unusable in normal contexts.
So, how many times a day do you, personally, do something that A) requires the microphone on and B) needs to have full screen video capture and C) becomes absolutely useless to anyone for any purpose if the microphone-indicator dot is visible in the menu bar?
Sure, keep the dot – but only on the main screen. Why project the dot on every attached display?
The dot is an utter annoyance, especially if one does not care if one is being recorded or not - in a live performance situation, for example - and there is no way to get rid of it from screen recordings, or during playback of art requiring as blank a screen as possible in some way.
What the dot needs, just like all the other annoyances that get treated this way, is a means by which to hide it intentionally, i.e. in one syspref, the dot hides shortly after recording is activated (for those paying attention and knowing that is how it is configured), in another syspref, the dot is ‘permanent’ - i.e. the truly paranoid, and in the last, the dot is simply not there and the user is on their own for microphone security, i.e. duct-tape.
That it is permanent no matter the best efforts of well-intended users is a frustration; that it can be disabled on non-SIP-enabled machines is not a solution; better user-friendly sysPrefs are required, but then again see also: Accessibility.
For situations where you truly need a blank canvas and even the small dot being visible would ruin the effect, there is – according to multiple people in this thread – an API that apps can use to get a full-screen with absolutely no decorations, dots, or anything else.
No, not every single thing in every operating system needs a checkbox to toggle it on/off. Especially not security features.
We live in a world where big sites like Facebook have to log a scary console warning to people who open the browser dev tools, because malicious actors can literally talk ordinary users into opening the dev tools and voluntarily pasting in the code that will pwn their accounts. An easily-removable microphone indicator will be easily removed by malicious actors in exactly the same way, so putting it behind SIP, which is more effort to tinker with and can show big scary warnings to users, is an acceptable choice.
How is this a security feature if the microphone is already recording audio?
It’s a security feature in the same way that the green “camera is on” light is a security feature even though the light means the camera is already on and recording. In both cases, the indicator’s purpose is to tell you that something is recording, because you might not otherwise have known (say, because malicious code had surreptitiously turned on your microphone and/or camera).
If it’s possible without the user’s consent it’s a security issue. If it’s possible with the user’s consent it’s just called “not being evil”.
In this case it is possible with the user’s consent. Sure, there’s no built-in checkbox, but disabling SIP is effectively a big override switch saying “I want to do some unsupported mucking about, please disable the extra security features for me.”
It’s true Apple doesn’t include a checkbox for every conceivable option… but that doesn’t make them evil. Disabling SIP will let you do whatever you want to the machine, and make any tweak that you like–including replacing the OS with Linux if you want.
On the other hand, I agree that having to disable SIP is a huge hammer even if you want to disable some security items for some time (e.g. a few hours).
Definitely gets an upvote from me for the H2G2 reference.