This is, I'm afraid, part of a vision (of which Apple is the preeminent sponsor but Microsoft definitely believes it too, they're just less aggressive) where the OS vendor is presumed to know best and the owner of the computer's wishes are occasionally considered on an "if possible" basis.
Obviously they could allow whatever signatures go into SIP to be updated, so you could make changes and then bless your changed configuration, and it wouldn't really even be hard. But they consider most computer owners to be too stupid to be trusted with that kind of power. And, they do have a point, a lot of users would happily do any super unsafe things they're told, just in exchange for a promise of a free game or a cracked version of Photoshop or whatever.
It's just sad for those of us who remember that computers used to really be almost infinitely customizable. If you didn't like something, and you cared enough, you could fix it. I assume that soon, SIP won't be a thing you could turn off even if you wanted, and while you will still be able to get a root shell on a Mac it'll eventually be on some virtualized entity whose permissions are curtailed to only a sandboxed environment.
If that future ever happens there will be much gnashing of teeth, but, well, we're not there yet. Apple's been threatening to do that since the iPhone was released and they still haven't, so while SIP is way more annoying to disable in Ventura compared to the big cat days before it existed, Apple hasn't actually done this terrible thing that we're all afraid of.
It's not impossible for Apple to try something like that, but looking at the client side CSAM debacle, and Apple's backtracking on that idea, I think that a future rev of OS X that's locked down to end consumers just isn't going happen. I'm not saying it's impossible or that we can stop being vigilant, or even that Apple's a good business partner (they're not. they really seen to hate enterprise for whatever reason).
But the day Apple makes that move is the day Apple loses their way again. Which they seem to have found again, judging by the number of ports and the keyboard on the M2 laptops.
This is macho-computing bullshit, the same as the 1980s "it's a toy unless it's a command line".
For most users, SIP increases ownership and control. Chrome can no longer make your Mac unbootable.[0] Journalists and human rights activists can be slightly less afraid of rootkits that can put their lives at risk. Teenagers can worry less about RATs that access their webcams and blackmail them. Companies can deploy these machines with greater confidence that trade secrets won't be stolen.
There's a reason Microsoft, Apple, and even Fedora[1] are all moving in the same direction. Most of the time, modifying system binaries is not done in users' interest: it's either malware, or it's "legitimate" large software vendors who couldn't write proper code at gunpoint, yet feel entitled to take over your kernel, make it unstable and increase its attack surface (look at Windows antivirus makers in the '90s and early '00s. Just look at how ISVs lobby against these security measures: [2]).
Like I said. They have a point. You’re not wrong that all kinds of security threats have been neutralized by this change. It’s just sad for those of us who remember that by virtue of being a computer, all aspects of the system were customizable if you were determined enough.
There were entire ecosystems of customizations and hacks available 20 years ago on both Mac and Windows. I’m not really sure what the Windows customization scene is really like these days, but essentially it’s over on the Mac. Even things like clipboard managers, I assume will be broken in the next couple of years, because it will be considered too much of a security threat to allow an app to monitor the Clipboard.
This "vision" has been gradually creeping into other aspects of life too, and it's called "authoritarianism".
It scares those in power to give that power away, because then they may not be able to corral and persuade them in the desired direction (i.e. to be milked for $$$) as easily. Apple, Google, Microsoft, and all the others aren't really acting in your best interests; they just pretend to do so and persuade with superficially convincing arguments, so they can get you to trust them.
Off the top of my head, dtrace and dyld are gimped with SIP enabled, and you cannot modify your system volume for whatever reason (yes, that means "sudo mount -uw /" fails). You cannot use LD_PRELOAD if SIP is enabled, even on your own apps. Kernel extensions also need you to disable SIP, which is annoying if you want to work on a kext or even install one.
For a non-technical problem: if you want to be able to share your screen on apps like Discord and forward audio output, you have to install a kext (oops, can't do that anymore with SIP enabled!), or you use "system extensions" which run in user space and expose less APIs (oops, on Apple Silicon macs the user has to boot into recovery mode to temporarily disable some security option before system extensions can be loaded!)
The result? A lot of Mac users are simply too wary set up audio output for Discord's screen sharing because it means having to boot into recovery mode and do a bunch of stuff that will scare the hell out of any non-technical user.
So it's not just power users that are affected by silly Apple policies. Everyday users, too.
I think that's magnifird by the software you use, in this case, Discord. I've got SIP enabled and didn't need to disable it for Zoom or Google Meet to do screen sharing. There was one permissions dialog I had to go through in accessibility for screen sharing to work for them, and it's a tiny bit scary, but it's not SIP disabling, reboot into recovery mode and run crsutil disable level scary.
All features of Discord work for me using the normal system permissions on screen recording and audio. I do run MacVMs with SIP off, but I leave it on as an important security feature most of the time. It's really not a lot different that say, SELinux, except a bit easier to administer but a bit less flexible. RO system volumes are getting popular too. Fedora has one, as does the steam deck.
Zoom and Google Meet share audio conferencing with Discord all of which require the microphone audio. But Discord differs in that you can stream the audio _output_ as well; think of something like Twitch.
Agree on this, but I would like to lament the loss of SoundSource, an amazing third party app that I paid for, that since some recent MacOS requires some SIP related BS to enable - which I’m not even close to willing to do on my work laptop where I spend 90% of my time. So I just lost this functionality, and unlike Windows MacOS has absolutely no ability to do this natively (adjust the volume and destination of sound per-app)
Apple needs to allow users to defeat certain security mechanism without disabling SIP. The "all or nothing" approach will end up with a lot of people going "nothing" or leaving the platform. Not everyone faces the same risks.
Something like (just typing this out, haven't thought it through): Having Apple associate your hardware with an apple id. Logging into apple id and registering a key. Apple signs key and you can install key on the specific hardware. You can then use said key to sign a security policy.
The key can be removed by install Apple's default key by anyone, increasing the security level back to normal.
> Apple needs to allow users to defeat certain security mechanism without disabling SIP. The "all or nothing" approach will end up with a lot of people going "nothing"
But is that so bad? For technically-inclined users, I'm still largely unconvinced of the value of SIP.
Either you want Apple to be in control of your computer—and I think that's a perfectly reasonable default, if it can be changed—or you want to take control. If you take control, you must by definition also take responsibility for delegating those privileges to locally-installed software—which you can do via the standard UNIX permissions model.
Apple added an extra layer on top of UNIX permissions in order to limit the users' maximum privilege level. If the user tells Apple to GTFO, there's no need for an extra layer.
> For technically-inclined users, I'm still largely unconvinced of the value of SIP.
Problem is technically-inclined users are the ones most likely to not be running "defense in depth" and therefore susceptible to zero days such as the H.264->code execution discussion earlier this week.
Arguably, technically-inclined users participating in the software supply chain should go beyond SIP and run in Lockdown mode permanently, both on the dev machine and any mobile devices used for MFA, or at the very least self-install SAP's "Privileges" or equivalent that requires a deliberate unlock to act as Administrator.
This helps prevent (not categorically prevents) drive-bys with persistent payloads without the extra attack surface that is commercial AV or anti-malware.
I find that I fall somewhere in between. I tend to turn on (or leave on, or configure) every security feature available that doesn’t create an immovable obstacle to my needs. Lockdown mode does that, so I partially counteract that by running SAP Privileges and also creating a separate, dedicated admin account that I almost never end up signing into directly.
Turning SIP off just doesn’t make sense to me without a compelling reason. Those reasons aren’t as common as they used to be. I seem to remember early in the life of SIP, the Steam client didn’t work well so you’d end up disabling SIP on some personal devices. I don’t think that’s been the case for a long while.
Apple already engineered SIP to let the user disable it with csrutil. It is unsupported but you can selectively disable parts of SIP. (You cannot Apple Pay if any flag is disabled.)
In good old ChatGPT fashion, it is utterly wrong, of course. If you are passing some unknown struct to a function, you should make sure you at least get the size right.
ChatGPT Axiom of correctness: If an answer cannot be googled or cannot be obtained by making trivial modifications to an answer found on google, most probably GhatGPT's answer is incorrect.
Bartender [0] hides and rearranges icons by manipulating how the menu bar gets rendered. IIUC, it takes screenshots of the menu bar and uses them to cover certain areas of it. This might be another promising approach for hiding the orange dot.
"Oh, and it also appears in screen recordings, which annoys me as well whenever I want to demo something."
If only there was a way to take that screen recording into some bit of software and cover up this part of the image so that it no longer offends in this precious bit of content. It's not like you're going to post that RAW screen recording session to some place without doing anything else to it in a professional manner, are you?
I actually forgot about the menu bar in macOS ever since they gave me the ability to hide it like the dock. When I don't need it, it's out of the way recovering precious extra rows of screen height. When I do need it, it just magically reappears.
"It can also be a distraction for a specific group of people struggling with attention deficit."
If you are distracted by a dot, how are you not distracted by all of the other info in the menu bar too?
> If you are distracted by a dot, how are you not distracted by all of the other info in the menu bar too?
The other things in the menu bar have a consistent design (e.g. they're black and white) and are static (assuming you aren't changing values in them like increasing the volume). This easily allows it to fade into the background.
This dot pulses and uses a color not used elsewhere in the menu bar. It has been intentionally designed to get your attention.
From the previous HN thread linked from this article, it seemed like the “officially supported” ways to avoid the orange dot for live performance and editing video were either a hardware capture device, or an app that uses an API to output raw video to a window/display.
I finished the article and was wondering if the author will show a image of how the dot looks like, and later find out that the first "image" is a video, and Firefox blocked the auto-play leaving the first frame that doesn't contain the dot. Have to right click on it and select play to reproduce it. I like that feature and avoid things moving around without interaction, but I think Firefox should put an overlay with a play button on native web videos, at least on mouse hover, isn't the first time I have to right click to know if is a video.
And for the author, the use of descriptions at the bottom of images/videos is good for accessibility, a description like "Screen recording of the dot appearing" will avoided my confusion, and persons using screen readers will know it too (I checked and in the code there isn't a alt text for that (question: the alt="description" works for <video> like is used in <image>?)).
macos 13.3 introduced another dot, a blue dot for location services. Unfortunately it seems to severely interfere with games. For example, playing Asphalt9 from the mac app store, on macOS 13.3, whenever the blue dot appears, which seems to happen almost every minute, the game's audio stops, any attached game controller becomes unresponsive, and if you were actively playing a single player race, the game pauses and shows the pause menu, as if you had changed focus to a different application. After about 10 seconds, the blue dot disappear and the game controller becomes responsive again, allowing you to unpause the game. This makes any attempt at actually playing the game an exercise in anger management.
It's a problem where the Operating System decided to run a background task and caused the foreground task that the user was interacting with to develop UX issues. Arguably the game could do a better job of handing when the operating system pulls the rug out from under it, but managing the limited hardware resources is really the job of the operating system. So it's the blue dot.
It's possible, given all of the macOS games out there, but macOS often decides to check on its own location, either to report the weather, or to update the laptop location for Find My, in case it's been stolen.
While we're here, does anyone know a way to keep FileVault enabled with SIP disabled? It seems like a huge anti-privacy measure from Apple. Want control of your system? No FDE for you!
That part is correct, and it's to save you from doing something rather dangerous.
On modern macOS systems, the system volume is not encrypted. If SSV is disabled, there's nothing to prevent the (potentially modified) system from exfiltrating your password and/or your encrypted data after you log in -- File Vault would be unable to provide any substantial security guarantees in this configuration.
Now, because you can modify the system, you could probably bypass this check, or work around it (e.g. by mounting an encrypted volume during startup). But you should probably think very carefully about what attacks you're permitting before you do that.
This was a little bit of an uncomfortable read as I really didn't want to see this defeated, but I'm glad people are checking that it works as intended. The pessimist in me fears that when SIP bypasses are found this will be ready to go as part of a RAT. Realistically though the authors of RATs probably didn't need the example.
Apple could just go to the expense of adding a few extra LEDs to the case. They already have one in Caps lock - could put one behind the volume button or something.
Or make it only appear on the internal monitor, not mirrored or external devices.
This would be so much better, and harder for real attackers to obfuscate and mislead. It would be easier to secure as well. It should of course also be physically based, and not software. This would probably mean always-on BS like Siri would always leave the light on, which would be honest.
> Or make it only appear on the internal monitor, not mirrored or external devices.
Using an external monitor shouldn't mean the user loses access to a privacy feature. (Especially because some systems, like the Mac Mini, don't even have an internal monitor...)
Obviously they could allow whatever signatures go into SIP to be updated, so you could make changes and then bless your changed configuration, and it wouldn't really even be hard. But they consider most computer owners to be too stupid to be trusted with that kind of power. And, they do have a point, a lot of users would happily do any super unsafe things they're told, just in exchange for a promise of a free game or a cracked version of Photoshop or whatever.
It's just sad for those of us who remember that computers used to really be almost infinitely customizable. If you didn't like something, and you cared enough, you could fix it. I assume that soon, SIP won't be a thing you could turn off even if you wanted, and while you will still be able to get a root shell on a Mac it'll eventually be on some virtualized entity whose permissions are curtailed to only a sandboxed environment.