Which system integrity protection are you worried about missing? Muse being able to exfiltrate the contents of your messages db doesn’t compromise system integrity to begin with. It being able to write arguably does, but this whole conversation was about how to grant it full disk access in the future anyway.

And OP had SIP enabled, but his system still got compromised with a remote exploit.

▲

throw0101a 4 hours ago | parent | next [-]

AIUI, SIP protects "/" but not "/Users" (macOS' $HOME base). All your private data is in $HOME, so that's why Muse could get it even with SIP.

	▲	brigade 4 hours ago \| parent \| next [-]
		Sort of; SIP originally was simply meant to protect /System from root. But nowadays, it's more used for system attestation. Which in turn is used by the OS to decide how to ask for and enforce certain user permissions and sandbox profiles.
	▲	lapcat 2 hours ago \| parent \| prev [-]
		> SIP protects "/" but not "/Users" (macOS' $HOME base). > that's why Muse could get it even with SIP. Both of these assumptions are mistaken.

▲

lapcat 3 hours ago | parent | prev [-]

> Muse being able to exfiltrate the contents of your messages db doesn’t compromise system integrity to begin with.

I care more about the integrity of my personal privacy than I do about the integrity of the "system". The point of the system is to serve me.

> And OP had SIP enabled, but his system still got compromised with a remote exploit.

Nobody said that SIP magically prevents macOS bugs and security vulnerabilities.

▲

brigade 2 hours ago | parent [-]

Protection from the sort of malware OP was hit with is the most commonly cited dire warning against disabling SIP. I just assumed that was also the reason you were against disabling SIP in order to grant permissions to software you intentionally installed.

▲

lapcat 2 hours ago | parent [-]

> Protection from the sort of malware OP was hit with is the most commonly cited dire warning against disabling SIP. I just assumed that was also the reason you were against disabling SIP in order to grant permissions to software you intentionally installed.

No. The confusion here is that the Stratechery post combines multiple stories. There was a macOS screen sharing vulnerability, now fixed. The vulnerability existed even with SIP enabled, and that vulnerability is how Ben Thompson's Mac was hacked.

The question was, why did Thompson's Mac have the screen sharing port open to the internet, and that's when Thompson explained that the Mac was running an agent.

Coincidentally, Apple published a developer note on Friday about upcoming changes to Full Disk Access, which mentioned AI agents. Apple did not give any specific reason for this change, but presumably the inspiration was a very recent public controversy initiated by a journalist whose Messages database on macOS was read and uploaded by the Meta Muse app. Muse and similar AI apps request Full Disk Access to access all of the user's information. Without SIP, these apps would be able to suck up all of your data without permission.

▲

brigade 2 hours ago | parent [-]

If you're arguing that SIP isn't a useful defense against malware, I agree there.

Sandboxing full disk reads is orthogonal to what SIP actually provides. It's entirely possible for an unsandboxed binary to slurp your private data even with SIP enabled.

▲

lapcat an hour ago | parent [-]

> If you're arguing that SIP isn't a useful defense against malware

No? I'm not.

SIP is of course not a universal defense against every possible kind of attack, but did anyone ever expect it to be?

> Sandboxing full disk reads is orthogonal to what SIP actually provides.

No, because again, as I already said, disabling SIP also disables some TCC privacy protections.

> It's entirely possible for an unsandboxed binary to slurp your private data even with SIP enabled.

Not the data protected by TCC.

	▲	an hour ago \| parent [-]
		[deleted]