I think I’m probably being dumb, but the gotcha here seems to be - ‘if I give an application permission to access a folder, it has access to the files in that folder’ - which is what I would expect??

Eye-opening findings. After reading the article I revoked every folder permission and tested: Insent still reads Documents even when the UI shows "None". This is a serious trust failure; transparency is supposed to be the whole point of those preference panes.

That's the beauty of using a GUI-first operating system!

> only way you can protect your Documents folder from access by Insent is to run the following command in Terminal: tccutil reset All co.eclecticlight.Insent then restart your Mac

Actually there is another way to reset the permission besides running tcutil reset.

Simply go to Security and Privacy and turn the permission on then back off :)

What happens here is the UI displaying the permission state is buggy, but the permission actually works. It's just hard to see its state.

Buggy UI, modern Apple...

By the way there is another problem with that UI. The checkbox is blue when on and grey when off... but only when the window has focus. When the window is not focused it's grey in both cases. Different greys but still greys. And if you don't spend all day looking at checkboxes in Mac OS, you may forget if left or right is on.

And this is on Sequoia not <the low contrast update>.

Edit: I wonder if a reboot would also make security and privacy read the status properly. But it would ruin my uptime, so I'll let someone who has an OS update to install check :)

Edit 2: And I just noticed. I have a TB drive hanging off my Mac Mini and my games are on it. So there's a bunch of games in security and privacy (mostly crossover entries, but also for example euro truck simulator which is native) because they requested access to "removable volumes". No shit, they're installed on said removable volume.

So the title should be something more like "macOS apps retain access to folders after access is removed by the user".

The problem with Mac’s sandbox system is that it’s giving me some PTSD of Windows UAC. It’s inventing a solution to a problem that might exist in small doses, but instead gives users permission fatigue.

I personally think the traditional *nix model has served us quite well, and elective sandboxing using containers (à la Docker and so on) is quite good. The Mac sandbox model is probably ok for most normal users, but for power users is infuriating at times. Multiple restarts of Mac and various processes (and when you realize not enough scopes have been granted, another subsequent restart). I think Mac forcing all users into its sandbox system has been one of my least favorite impacts since upgrading macOS, leading to the enshittification of macOS.

The craziest thing is background processes started by Terminal/iTerm (such as tmux) can inherit Terminal or iTerm’s elevated status even when Terminal or iTerm are no longer running, dead, or killed. So you’ll have a bunch of elevated processes without the elevated parent or grandparent process running—it makes me feel the whole permissions scheme is more performative than actually useful.

Is this a bug, security vulnerability, or just an oversight? It’s not clear to me.

As a precaution would it be a good idea to run that reset command for all apps?

There's another "security UI" issue in the latest macOS, that's been there for at least a few versions.

I go into "Privacy & Security", "Full Disk Access". A bunch of apps added themselves in there (Anki, Fission, Microsoft Autoupdate, WhatsApp), the toggle is disabled and I've never enabled it. Ok, whatever.

But when I go into "Files & Folders", and under those apps I see "Full Disk Access" in gray. Apps that have Full Disk Access toggled on look identical, with "Full Disk Access" in gray. What the hell am I supposed to make of that?

Is it a bug? Do they have full disk access? Is the UI trying to imply that those apps are solely controlled by the FullDisk toggle and are ineligible to request granular permissions for Desktop/Documents? Or that they are eligible, but haven't requested it? Or maybe they did request it, and I granted it, but I don't get to see it? Who knows?

could the same be said of iOS?

What is the arcane Terminal command to undo this access?

It turns out the issue is a com.apple.macl extended attribute that gets set on the Documents folder and can't be removed, due to SIP.

The first thing I wondered after reading this article is whether there might be a scheduled task to run the permission reset similarly to how the author ran it via the command line.

It seems most likely that this is some kind of bug where that command or its underlying actions should be called every time the user unchecks something in the settings panel.

This is what we get when the iPhone’s permission system is grafted on top of a desktop OS that was never designed for it. I think they could have done something that is more Unix-like and yet friendly to the GUI end user.

is this is why apple pushed an update yestersay?

linux and unix before it has been a pretty consistent interface for decades, especially since the introduction of X windows in the 1980's..

[dead]

I guess yes

The post misunderstands how the permission system works.

Giving access to a file via the Open and Save panel is an explicit declaration of consent.

Because the panel is provided by OS itself, the app doesn't get access to the item until the user has selected a folder or file through that panel.

I never trust american and Chinese companies

It seems that author basically found a 0day and published it. It's for sure better than selling it on the dark web but maybe it's better first tell it to Apple?

can you trust vpn to run well on a mac tho. like mullvad or something good.

Well duh, the purpose of Privacy and Security was never Privacy or security. The purpose is to lock you into Apple's ecosystem and prevent you from installing your own software.

Great insight! Thanks for sharing.

> Once you have downloaded Insent

As if that's going to happen.

This is exactly why the security model matters. If the OS or app can access your data, so can anyone who compromises it. The only real solution is client-side encryption where the server NEVER sees plaintext — your keys stay on your device.

We've been building something in this space — Cifer Security uses ML-KEM (post-quantum) for key encapsulation and Poseidon hashing, with Groth16 proofs for verifiability. The server is intentionally blind to what it's storing.

The macOS permission model is theater if the app itself isn't zero-knowledge. Privacy can't rely on UI toggles — it has to be cryptographic.

I was considering buying a mini Mac, but there wasn't a way to encrypt it fully with Veracrypt and in the case of Francis Rawls the feds got pass Apples vault encryption. With the recent iPhone notification storage revelation I don't trust Apple at all.

I never used the ~/Documents folder. Lots of apps just trashed their stuff in there over the years making that folder entirely unusable for my actual document files. I would have to dig through the mess to find them. So I have to admit that I don't really understand the extra "care" Apple is doing to this particular folder. Same for the ~/Downloads folder: all my actual downloads go to some other disk, since the system disk is so small. Protecting this two folders would be entirely useless here.

IMHO where it really needs to be protected from when iCloud suddenly starts grabbing everything w/o the user's permission to upload it to some random Apple servers.

I think it is an acceptable quirk for a permission system that has been retrofitted on top of an ecosystem which was not designed with that threat model in mind.

But sure, if I was assigned to make an all-purpose desktop operating system today from scratch, I would likely do this differently, but along with a bunch of other things I think (and the app would have to be implemented differently too).