Can we hide the orange dot without disabling SIP?
notes.alinpanaitiu.com
notes.alinpanaitiu.com
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.
What's wrong with SIP being on or off?
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.
A nitpick, but kexts really aren't the way forward post-Catalina.
Note that I am not defending Apple's bungled handling of the transition.
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.
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.
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]).
[0]: https://arstechnica.com/information-technology/2019/09/no-it...
[1]: https://fedoramagazine.org/what-is-silverblue/
[2]: https://en.wikipedia.org/wiki/Kernel_Patch_Protection#Critic...
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.
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.
If you want to disable specific security mechanisms then disable SIP.
But making that an option that developers will use to exploit less technical people is not good for the platform or frankly anyone.
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.
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.
https://github.com/SAP/macOS-enterprise-privileges
This helps prevent (not categorically prevents) drive-bys with persistent payloads without the extra attack surface that is commercial AV or anti-malware.
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.
The only thing that can appear above the dot is the cursor.
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?
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.
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>?)).
That's more alarming to me than the blue dot itself.
(Why it's happening, that is - not _that_ it's happening)
File Vault works independently of SIP. There's no conflict.
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.
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...)