You can't trust macOS Privacy and Security settings

https://eclecticlight.co/2026/04/10/why-you-cant-trust-privacy-security/

by zdw • 3 months ago

512 167 3 months ago

eclecticlight.co

dackdel• 3 months ago

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

post-it2• 3 months ago

Yeah, they run fine.

AlexandrB• 3 months ago

This is a few years old, but at one point Apple was happy to bypass VPN or firewall settings to allow their own apps to communicate[1]. I don't know if this is still true on Tahoe, but I wouldn't be surprised if at least the mechanism still exists. So "they run fine", but they may not do what you expect them to do when it comes to Apple's products/services.

[1] https://www.macworld.com/article/675671/apples-own-programs-...

MegagramEnjoyer• 3 months ago

imo, you can't really ever fully trust a closed-source system, which is why I advocate for linux distros, even though I'm a mac user myself (for now)

VPN should be properly implemented though as you're able to verify network requests on your own and don't necessarily have to trust apple. Best guarantee is to have a VPN at router level that can't be circumvented by anything (+ a trusted router vendor)

b8• 3 months ago

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.

SilverElfin• 3 months ago

Notification storage? What’s the story there?

Nevermind just saw this: https://news.ycombinator.com/item?id=47716490

nroize2• 3 months ago

I couldn’t find any reference to File Vault being cracked in the Rawls case. Source?

Edit: I saw they accessed his Mac but they had his password. File Vault 2 wasn’t bypassed, and afaik has never been cracked.

nullpoint4202• 3 months ago

Why crack it when you have silicon level backdoors?

throwaway2905• 3 months ago

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?

post-it2• 3 months ago

Not really, just an unintuitive security feature. You still need the user's permission to access that folder, but that permission is then persistent. I consider it a UX bug for sure but not an exploit.

lugoues• 3 months ago

I agree, it's a ui/ux problem. It would seem that using the open file dialog should also request access but I'm guessing that was too intrusive and the user action is seen as implicit authorization. Security is one of those things that should aways be explicit though.

throwaway2905• 3 months ago

if having to run an arcane terminal program to disable access while GUI is as if access was not granted is "unintuitive security feature" for you, I can't even.

ethanrutherford• 3 months ago

Not exactly. It's not a "new" attack vector, any software which was malicious would have already been able to attack when you first gave it permission (a prerequisite for this sticky permission issue). If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app, not just "revoke the permission for the one folder".

It's not a good look for Apple, and it's not great that the permission revocation basically doesn't actually work, but any malware that could have infected the system due to this issue would have also been able to infect the system while the permission was still (intentionally) enabled.

throwaway2905• 3 months ago

If you had downloaded an app and discovered it was malicious the remedy would generally be to uninstall the app

There are many apps that themselves are not malicious but they run untrusted code via plugins and stuff. Like VS Code for example.

So you gave it a permission and then revoked it thinking all is fine. tomorrow an extension was hijacked and it now reads your files. cool?

concinds4• 3 months ago

Apple Security would instantly close it as "don't see the problem here" if you reported it to them. They have a poor reputation around TCC bug reports.

throwaway2905• 3 months ago

That makes it OK for you to not responsibly disclose a vuln? Cool I guess)

jasonjei3• 3 months ago

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.

al_borland• 3 months ago

Someone at Apple should watch some of their old ads.

https://www.youtube.com/watch?v=8CwoluNRSSc

halapro• 3 months ago

The best part is that this kind of popups have been introduced with OS X Lion in 2011, which only came 4 years after Vista.

jmount• 3 months ago

Very much agree. In fact I don't remember Vista or UAC being as unreliable as the Mac now is.

big_toast2• 3 months ago

I feel like I can mostly use containers on macOS. Is there a different sense that people are using containers on *nix? Or are you referring to all the macOS specific software footguns?

I would like to be able to run arbitrary code with gradual/granular privilege escalation. (e.g iOS/android with more affordances and escape hatches. macOS is getting there, but it's been a pretty bumpy/potholed road). Right now if I download a random github repo, I'd put it in a docker container and give it ports/volumes/etc.

jasonjei3• 3 months ago

I was building a lightweight imitation of OpenClaw. Just a Claude.md and iMessage watcher. I had to play around with Privacy a lot to be able to read my iMessages database, and do a lot of iTerm restarting.

shantara• 3 months ago

One of the worst cases happens immediately after logging into a fresh Mac, or after upgrading one. You’re instantly hit with a barrage of requests from all the installed apps and their various permissions. It makes for such a terrible initial user experience, it’s utterly baffling someone at Apple has signed it off. They used to poke fun at Windows in their ads, but UAC has never been that terrible in my experience.

iamcalledrob• 3 months ago

Plus, Apple exempt their own apps from a bunch of these permissions (because it would be an unacceptable user experience for their customers)

jjtech• 3 months ago

Note that this isn't "Mac's sandbox system", it's TCC. That's an important distinction to make, because apps that have opted into the proper App Sandbox can't do this... they don't even have the ability to display a prompt for direct access to Documents/.

With the App Sandbox, sandbox extensions are issues whenever you open a file using the file picker. They only last until the app is restarted.

A caveat is that you can save "Security Scoped bookmarks" (basically a signed base64 blob [1]) and pass that around to preserve access, but that isn't very common.

[1] https://www.mothersruin.com/software/Archaeology/reverse/boo...

jasonjei3• 3 months ago

Yes, TCC is what I meant, but my understanding is TCC is a platform wide sandboxing system?

galad872• 3 months ago

TCC is a different thing. Sandboxed apps work differently and won't need those TCC dialogs.

traderj0e3• 3 months ago

I feel the opposite with Mac permissions (or Linux or Windows). Hardly anything asks me, and it seems like everything has access to everything. But same conclusion here, if I don't trust something, I want to explicitly sandbox it.

p_stuart82• 3 months ago

performative is right. files & folders says blocked. open panel access still works. the pane only knows about one path

cosmic_cheese• 3 months ago

I think the bigger issue is that way too many devs still live in the extremely dated paradigm of “anything has access to everything all the time”, even though this model has repeatedly proven itself unworkable (particularly for anybody using proprietary software, which is notorious for sticking its fingers in places it has no business touching).

The way macOS handles permissions with user prompts might be the wrong UX, but giving every program carte blanche by default is definitely not the answer either.

It’s dangerous, particularly for those of us who are developing and publishing software that’s used by many thousands of people — we’re juicy targets and every time we disable protections in the name of convenience and carelessly run random third party software with unfettered access we’re playing with fire. I find myself consistently stunned by the flippant attitude SWEs take towards securing their systems. Our confidence that we’re too smart to fall victim is entirely misplaced.

josephcsible2• 3 months ago

I personally think the traditional *nix model has served us quite well

It has the https://xkcd.com/1200/ problem on almost all end-user setups.

streetfighter64• 3 months ago

I don't understand why OSX needs to restart the app to grant it permissions. The most annoying is video chat apps such as Teams and Zoom, having to close everything and reconnect if you want to share the screen or such. Perhaps there's a technical reason but it just feels like a lazy implementation.

But about the unix permissions model, is it really useful? During all my years of using linux on my personal machine, I've always had everything owned by my own user. Setting up specific users for programs would be a pain, and I don't think anybody does that? Servers is a different question, because then you're not actively using the system in the same way, which makes managing user accounts and their permissions on an app-level doable.

For normal users I think what's done on iphones and such works fairly well, and there they actually seem to have implemented it properly so that it doesn't require a restart to grant permissions.

liquid_thyme• 3 months ago

BTW - UAC is not a security boundary, so UAC-bypass is not the same as privilege escalation, and there is no bounty for it, etc, etc. It's a common misunderstanding, probably in no small part due to Microsoft's own lack of communication around it.

chrisjj• 3 months ago

Once you have downloaded Insent

As if that's going to happen.

Angostura• 3 months ago

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??

layer83• 3 months ago

Yes, you need to read more carefully. In particular:

“8. Confirm that Documents access for Insent is still disabled in Files & Folders.

“9. Whatever you do now, the app retains full access to Documents, no matter what is shown or set in Files & Folders.”

[…]

“Access restrictions shown in Privacy & Security settings, specifically those to protected locations in Files & Folders, aren’t an accurate or trustworthy reflection of those that are actually applied. It’s possible for an app to have unrestricted access to one or more protected folders while its listing in Files & Folders shows it being blocked from access, or for it to have no entry at all in that list.”

mh8h4• 3 months ago

"6. Click on Open from folder and select your Documents folder there. Confirm that works as expected and displays the name and contents of one of the text files in Documents."

It's because in step 6 the user explicitly selected the Documents folder.

The app can access the Documents folder because the user chose that directory in the native file browse dialog during the same run of the app. IMO that's a reasonable trade-off.

lynx97• 3 months ago

This is so typical for Apple software "quality". While a truly love some of the features Apple has put into my pocket, I am noticing since years that at least iOS is the first commercially sold platform where I sometimes have to press a boolean toggle twice to have it take effect. They seem to have a lot of bugs around UI synchronisation.

mixmastamyk• 3 months ago

Screen time is swiss cheese as well, not surprised.

yAak• 3 months ago

The gotcha is “I gave it permission, then revoked permission in the UI, but it still has permission.”

swiftcoder• 3 months ago

That's not quite it either. It's more along the lines of "I revoked access via one mechanism, then granted it via a different mechanism, and the setting UI for the first mechanism doesn't reflect the second action".

There's no privilege escalation here, but there is a misleading privacy settings UI, which offers no obvious way to audit/revoke permissions in the second case

wtallis• 3 months ago

Not quite. The steps are revoking permission in the UI (which works as expected), then implicitly granting permission in a way that the UI does not reflect but quietly persists.

_blk• 3 months ago

So basically the opposite of Windows NTFS and SMB access. Windows is tricky but this is just bad.

DrammBA• 3 months ago

TFA intro (emphasis mine):

In this Friday’s magic demonstration, I’m going to show how what you see in Privacy & Security settings can be misleading, when it tells you that an app doesn’t have access to a protected folder, but it really does.

relaxing• 3 months ago

It’s really poorly written. After reading it all I still can’t figure out what’s the mechanism by which revoked permissions are hanging around, which is what would actually be interesting here.

nativeit2• 3 months ago

My impression is that the revoked permissions do not persist. Rather, an interactive window running under the user’s name has implied access to the user’s home folders, regardless of what’s been set under “Files & Folders” (which still applies for background/non-interactive processes).

I could absolutely be missing something here, but the title would be accurate in saying, “MacOS ACLs aren’t terribly intuitive”. But I think the behavior they’re documenting is intended behavior.

kccqzy3• 3 months ago

It is poorly written. I have suspicion that the author is talking about the persistent file permission mechanism known as Security-Scoped Bookmarks, but the article makes it hard to understand what exactly is being discussed. It reads like a raw bug report without any analysis done.

And specifically they could show some code snippet to reveal what exactly the Insent app was doing. Was it calling startAccessingSecurityScopedResource of the NSURL class?

altairprime• 3 months ago

One might expect macOS to recognize “you selected a folder that’s already got a UI associated with it” and to wire this up on the backend through the UI rather than creating a simple path exception that leaves the UI nonfunctional. I would have just filed a feedback report about it; but, the outrage-framing of that is, in historical context for this particular site, normal. They have posted extensively about Gatekeeper and TCC issues and seem to encounter them rather more reliably than others do, and released various tools (including today’s!) to support debugging, so certainly I empathize!

xp84• 3 months ago

I’m glad I don’t even rely on this dumb system in the first place. I just run programs that don’t do shady shit. Wish I could disable these idiotic prompts entirely and go back to how it was before.

“Word” would like to access the files in your “Documents” folder

“Terminal” would like to access the files in your “Downloads” folder.

Yes, because I am telling them to access the files.

john_strinlai• 3 months ago

I just run programs that don’t do shady shit.

you hand-audit every update for every program you run? can you share your workflow to do this?

otherwise, i am not sure how you can possibly guarantee that the programs you are running "dont do shady shit" (or, "wont do shady shit" in the future). there have been several compromises of non-shady programs and libraries in recent memory.

ted_dunning4• 3 months ago

Wow... that would be great.

All that remains is an algorithm to reliably determine which programs do "shady shit". How is it that you determine that Microsoft updates have not been tampered?

(insincere) apologies for the snarky tone. You are making light of a very hard problem and default deny until confirmed by the user isn't a bad first approximation.

dadoum• 3 months ago

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).

absolutedev2• 3 months ago

Great insight! Thanks for sharing.

absolutedev2• 3 months ago

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.

nativeit2• 3 months ago

Don’t applications running under your user account have access to your user’s home folder by default?

iAMkenough• 3 months ago

No. You get prompted something like “Application wants access to your Documents folder” and “Application wants access to your Downloads folder” on first attempt of each folder.

josephcsible2• 3 months ago

The entire point of macOS's TCC was supposed to be to make that not the case anymore.

eviks2• 3 months ago

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

sillyfluke2• 3 months ago

Speaking of GUI weirdness, I've seen a couple of relatively newer macbooks do this thing where the laptop is shutdown with wifi disabled, but after login on startup the wifi icon displays the wifi scanning mode as if the wifi is enabled and looking for networks before reverting to the wifi disabled display icon.

Is this a GUI bug or is the wifi disabled setting overrided for a split second on startup? I haven't looked into it, but the latter would be extremely concerning.

eep_social• 3 months ago

based on my experience, I suspect the latter

similar, user-hostile behaviors I have found include:

- wifi network passwords are persisted through a system wipe and reinstall in recovery mode - a phone home is required by an activation step during installation - bluetooth is always re-enabled after an upgrade

epistasis2• 3 months ago

Jobs is turning in his grave. There are lots of stories of this conflict at NeXT and Mac OS X where there's a quick fix but not via GUI, which was one of the many things that incensed him.

eviks2• 3 months ago

Is there a common source/collection of such stories?

themafia• 3 months ago

Then there's the OS/400 approach: Build TUIs that allow the user to set arguments and then just run command the line tools on submit. It was a really nice blend of two approaches and made things like man pages somewhat superflous.

wutwutwat2• 3 months ago

where there's a quick fix but not via GUI

This is every OS. Unless you're telling me linux users have never had to open terminal to change something? Or windows users never need to use powershell when installing the OS in order to create a local non-cloud account

wutwutwat2• 3 months ago

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

What non-gui first OS are you running? DOS?

dangus2• 3 months ago

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.

bombcar3• 3 months ago

This reminds me of the early days of MacOS where "repair permissions" was the magic fix to everything, or so it was rumored.

dangus2• 3 months ago

Whoa you are bringing back some memories.

And it absolutely was a magic fix. I stand by it.

throwyu• 3 months ago

I never trust american and Chinese companies

concinds4• 3 months ago

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?

grvbck• 3 months ago

That is really poorly worded by Apple, because if I understand it correctly, the "Files & Folders" list is just a list of apps that have requested Full Disk Access/FDA (or other locations).

It's really confusing that some of those settings can be toggled on/off, while the Full Disk Access is greyed out and can only be toggled under "Privacy & Security".

To add to the confusion, toggling FDA off just protects a few selected folders that Apple decided are extra sensitive, like:

  Messages                     ~/Library/Messages
  Safari browsing history      ~/Library/Safari
  Cookies                      ~/Library/Cookies
  Identity services            ~/Library/IdentityServices
  Spotlight data               ~/Library/Metadata/CoreSpotlight
  Phone call history           ~/Library/Application Support/CallHistoryDB
  Facetime data                ~/Library/Application Support/Facetime
  TCC database                 ~/Library/Application Support/com.apple.TCC.db

"Normal" files and folders on your disk (including Desktop, Documents, Downloads, network volumes, and removable volumes) can always be accessed (even with FDA permission revoked!) after a simple prompt. [1]

[1] https://support.apple.com/guide/security/controlling-app-acc...

binaryturtle• 3 months ago

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.

SomaticPirate• 3 months ago

What is the arcane Terminal command to undo this access?

cedws• 3 months ago

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?

concinds4• 3 months ago

These are considered security UI bugs. They are a subcategory of security bugs, since they result in users lacking control or awareness over permissions. If this were a Chromium bug it would get a CVE.

saagarjha6• 3 months ago

No?

isodev• 3 months ago

It’s Apple’s performative “security” (showing popups and asking the user for all sorts of permissions) overlapping with some pragmatic choices about how files and folders work. For me the gap is in Settings & Privacy - 1) it should be clear that the app has been given permission and 2) it should be harder to give permission once you’ve explicitly disabled it. 3) (nice to have) Apple should get rid of permissions that make you restart the app because it’s 2026 lol.

ezfe7• 3 months ago

This is an oversight in the UI. None of the systems are malfunctioning, it's just that there's no affordance in the UI for the implicit consent flow.

dogusyilmaz• 3 months ago

I guess yes

jijji• 3 months ago

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

jms703• 3 months ago

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

ezfe7• 3 months ago

Nope. The user is not revoking the access that they granted. They are revoking general access to a folder, but since there is no way to revoke specific access nothing happens.

jeremyjh8• 3 months ago

Its both. They can never revoke access to a folder they opened/selecte in the app UI, and aren't notified that the app has permanent access.

But also, once they've explicitly granted access, and then implicitly granted access to the same folder, disabling explicit access changes nothing.

xvector• 3 months ago

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.

glitchc2• 3 months ago

No, this is definitely a bug. The Privacy and Security panel is part of Settings, which is definitely part of the OS. Saying the Open and Save panel somehow has priority suggests that the Privacy and Security panel is not looking at the same parameters as the Open and Save panel, ergo a bug.

ezfe7• 3 months ago

It’s not a bug and that is clear if you don’t use the documents folder as your example. When granting specific access it is not the same system as when granting general Documents folder access.

The UI just doesn’t reflect this.

heyaco• 3 months ago

is this is why apple pushed an update yestersay?

lapcat5• 3 months ago

No.

oceanplexian• 3 months ago

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.

lapcat5• 3 months ago

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.

ezfe7• 3 months ago

Doesn’t seem like a bug to me - it’s just a poor UI. Two different security systems both working properly but only one has a UI to show the protections.

lapcat5• 3 months ago

Why would you think it's "working properly"?

The app somehow gained a permanent permission that I didn't give and that I can't remove no matter what I do. That's not working properly in any sense.

nottorp• 3 months ago

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.

zahirbmirza• 3 months ago

could the same be said of iOS?

ezfe7• 3 months ago

iOS does not allow any access to files outside of the file picker or the apps own folders

laosb• 3 months ago

Well it’s actually the same on iOS: Once you granted access by opening a folder via the picker, the app can save a bookmark and have access to it forever.

KaiLetov• 3 months ago

So you end up with two parallel permission systems that contradict each other, and the Settings UI only controls one of them. It's not a bug, it's architectural debt that they've decided is cheaper to leave than to fix.

broheimz• 3 months ago

I tested my own device (following this article), and found mac-native apps seem to respond well to the toggling in privacy and security settings, while 3rd party apps do not.

Pretty scary considering the blast radius of Electron apps: huge attack surface (Chromium + Node.js), require permissive entitlements to function (e.g., disable-library-validation, allow-unsigned-executable-memory), JS code is often unencrypted/easy to modify, easy inheritance to all the TCC permissions the user granted to the app.

Popular Electron Apps: Claude Desktop app, Spotify, Slack, Discord, Microsoft Teams, VS Code, Notion, LM Studio...

You can't trust macOS Privacy and Security settings

Related Stories