Discussion

The Eclectic Light Company

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

post-it: Yeah, they run fine.

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?

post-it: 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.

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.

nroize: 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.

chrisjj: [delayed]

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

AlexandrB: 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-...

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

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

layer8: 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.”

nullpoint420: Why crack it when you have silicon level backdoors?

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

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.

absolutedev: Great insight! Thanks for sharing.

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

altairprime: [delayed]

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

big_toast: 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.

jasonjei: 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.

big_toast: I remember it being worse a while ago. But most of the time I can drag a binary into Settings->Privacy & Security->Full Disk Access or other things (Accessibility API). Maybe other issues come up.I feel like it should still be much easier, but the general sandboxing model seems directionally functional. (My understanding is containerization isn't a silver bullet security-wise, still requires fiddling, and would be a resource hog ram-wise if not CPU?)I wish I could pick a parent folder/file and get a box to control everything (network/disk/folders/peripherals/accessibility).

jjtech: 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...

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

mh8h: "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.

layer8: The problem is that this given permission doesn’t show in Files & Folders, and after turning it on and off there it still persists. The only way to revoke it is using some CLI command and restart the computer.

mh8h: That's not what's happening here. Forget about the first 5 steps. If you install the app and start from step 6, the behaviour will be the same. If the user chooses the Documents folder in the browse window in an app, the app can use the contents of the Documents folder without the need for that permission in the Settings page.The Privacy settings applies only to access to the Documents folder without the user interaction.

tpmoney: I think the issue here though is that the permission for access remains even after you're not using the open/save dialog and that's not obvious (or controllable from the UI) after the fact.I think it's reasonable to expect that an application gets access to a file you access through open/save, but the fact that the access to the directory and all the items in that directory persists after that isn't necessarily expected. Especially given that the near equivalent workflow on iOS doesn't behave like this and that's what a lot of users would probably expect. On iOS an app can ask for access to your photos, which you can allow, or limit to specific photos or deny. If you allow access to specific photos and then the photo selector appears, even if you chose an album, the app will only get and retain access to the specific individual photos you gave it access to. It can not read the contents or even the names of any of the other photos in your library.It seems pretty reasonable to expect that if the "Documents" folder permission is turned off for an app on macOS and you have given the application access to a specific document inside your documents folder, that the application would not also get (and retain) access to read from all the other folders and files within your documents folder.I agree that this is the default behavior of most desktop OSes (including macOS), but it's also something that seems reasonable for Apple to change given how important sandboxing is to them in general, and how important it is in the broader context of always connected computers with multitudes of arbitrarily networked applications running.

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

sillyfluke: 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.

mixmastamyk: Screen time is swiss cheese as well, not surprised.

throwyu: I never trust american and Chinese companies

layer8: The point is that (a) it’s misleading that the app has access to the folder while the settings claim that it doesn’t, and (b) there is no reasonable way for the user to revoke the implicitly given permission.

mh8h: You don't need that permission if the user gives their implicit consent by selecting the Documents directory in the browse window. That's why most apps don't even show up in the Privacy Settings at all. Most apps don't need that, because they don't try to access that directory on their own. They only do it when the user selects the directory.I guess the improvement can be to show the implicit consent in the privacy settings page as well, and have a way to revoke it.

traderj0e: The real problem with this isn't so much that it doesn't show the implicit consent, but it shows explicit non-consent.

jakeydus: Yeah, it's less of a "GOTCHA!" and more of a weird use case that Apple engineers probably didn't think through all the way. Doesn't seem like a difficult fix at all.If the app opens a window and prompts the user to select a directory to save a file or load a file, should that access be recorded in the privacy settings page? I'd argue that maybe there should be a verbose version of the privacy settings page, where if you _really_ want to you can see every dir that every app has ever accessed, but the vast majority of users don't care.I'm less caffeinated this morning though so maybe I misread the whole argument.

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.

TeMPOraL: Another solution would be for people to make up their minds. Maybe it's time to give up entirely on multi-tasking support in the OS, because what's the point if all interoperability is going to be disabled "for security"? Might as well just go back to running one program at a time and close up all those security holes in one go.

traderj0e: Other comment seems accurate

misir: Why everything has to be on the server? ok, Where are you going to store your client authentication tokens or decryption keys. A proper file system isolation is a key if you want a proper application sandboxing

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.

epistasis: 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.

eviks: Is there a common source/collection of such stories?

epistasis: I'm sure there are some great ones, but it was 5-10 years ago when I last read one, and it was fantastic. It's nearly impossible to do a web search for it right now, probably because of Google's bias towards recency. I know it's been linked on Hacker News many times, so maybe somebody else has better info here.Even if you're not an Apple fan, these sorts of stories are kind of great for learning about product development and companies in general, I think. jwz's stories of Netscape are also phenomenal.

traderj0e: 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.

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

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.

glitchc: 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.

xvector: Yet more AI slop on HN

relaxing: 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.

nativeit: 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.