HN

Comments (100)

• Menu

  Angostura
  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??
• Menu

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

  eviks
  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
• Menu

  absolutedev
  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.
• Menu

  cedws
  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?
• Menu

  jasonjei
  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.
• Menu

  concinds
  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?
• SomaticPirate
  What is the arcane Terminal command to undo this access?
• Menu

  lapcat
  A few notes after testing extensively:1) This is a crazy macOS bug!2) The suggestion in the article to do tccutil reset All co.eclecticlight.Insent and reboot didn't actually work for me. However, I did first delete the Insent listing in Privacy & Security System Settings, which could have made a difference?3) A plaintext search of the whole Tahoe volume from another volume with SIP disabled failed to reveal where this persistent access is stored. It's definitely not in the standard TCC.db files. Perhaps the permission is encrypted somewhere?4) The article comments suggested that the com.apple.macl extended attribute is the cause, but it's not. Removing all macl attributes makes no difference.5) The access appears to be to the whole Documents folder rather than any specific file in the folder. If I have multiple files in the folder, the Insent app will sometimes show the contents of one file and sometimes the contents of another.
• heyaco
  is this is why apple pushed an update yestersay?
• throwyu
  I never trust american and Chinese companies
• dogusyilmaz
  I guess yes
• jijji
  linux and unix before it has been a pretty consistent interface for decades, especially since the introduction of X windows in the 1980's..
• Menu

  dangus
  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.
• MORPHOICES
  [dead]
• Menu

  throwaway290
  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?
• Menu

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

  xvector
  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.
• absolutedev
  Great insight! Thanks for sharing.
• oceanplexian
  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.
• chrisjj
  > Once you have downloaded InsentAs if that's going to happen.
• Menu

  cifer_security
  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.
• Menu

  b8
  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.
• dadoum
  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).
• binaryturtle
  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.