6 ms·
You can't trust macOS Privacy and Security settings
- dogusyilmaz 6mo agoI guess yes
- dackdel 6mo agocan you trust vpn to run well on a mac tho. like mullvad or something good.
- post-it 6mo agoYeah, they run fine.
- AlexandrB 6mo agoThis 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-bypass-firewalls-and-vpns-in-big-sur.html https://www.macworld.com/article/675671/apples-own-programs-...
- MegagramEnjoyer 6mo agoimo, 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 6mo agoI 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 6mo agoNotification storage? What’s the story there? Nevermind just saw this: https://news.ycombinator.com/item?id=47716490 https://news.ycombinator.com/item?id=47716490
- nroize 6mo agoI 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.
- nullpoint420 6mo agoWhy crack it when you have silicon level backdoors?
- nroize 6mo agoIn T2? Source?
- nullpoint420 6mo agohttps://en.wikipedia.org/wiki/Operation_Triangulation https://en.wikipedia.org/wiki/Operation_Triangulation iirc this was a register level exploit. no software in iOS or macOS touched the undisclosed register, but when the right secret key was entered, you got full read/write primitives on the silicon
- MORPHOICES 6mo ago[dead]
- throwaway290 6mo agoIt 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 6mo agoNot 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 6mo agoI 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.
- throwaway290 6mo agoif 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 6mo agoNot 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.
- throwaway290 6mo ago
- jasonjei 6mo agoThe 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 6mo agoSomeone at Apple should watch some of their old ads. https://www.youtube.com/watch?v=8CwoluNRSSc https://www.youtube.com/watch?v=8CwoluNRSSc
- halapro 6mo agoThe 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 6mo agoVery much agree. In fact I don't remember Vista or UAC being as unreliable as the Mac now is.
- big_toast 6mo agoI 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.
- chrisjj 6mo ago> Once you have downloaded Insent As if that's going to happen.
- Angostura 6mo agoI 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 6mo agoYes, 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.”
- mh8h 6mo 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.
- layer8 6mo agoThe 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 6mo agoThat'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.
- dadoum 6mo agoI 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).
- absolutedev 6mo agoEye-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.
- nativeit 6mo agoDon’t applications running under your user account have access to your user’s home folder by default?
- iAMkenough 6mo agoNo. 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.
- ted_dunning 6mo agoThe article seems to be saying that is true unless you implicitly and somewhat invisibly grant access via the file picker.
- ksidjwicjwjd 6mo agoNot always though. Adobe’s apps seem to be able to do whatever fuck they want whenever they want. I want so badly to stop them from creating a bunch of bullshit files in my Documents folder but there simply is no way to do it.
- josephcsible 6mo agoThe entire point of macOS's TCC was supposed to be to make that not the case anymore.
- absolutedev 6mo agoGreat insight! Thanks for sharing.
- eviks 6mo agoThat'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 6mo agoSpeaking 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 6mo agobased 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
- ksidjwicjwjd 6mo ago> bluetooth is always re-enabled after an upgrade Not user-hostile in the least. This is to ensure that the Mac can find Magic input devices.
- sillyfluke 6mo agoIs this sarcasm? What do people who don't want bluetooth on startup under any circumstances do?
- epistasis 6mo agoJobs 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.
- dangus 6mo agoThe 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.
- bombcar 6mo agoThis reminds me of the early days of MacOS where "repair permissions" was the magic fix to everything, or so it was rumored.
- dangus 6mo agoWhoa you are bringing back some memories. And it absolutely was a magic fix. I stand by it.
- steve1977 6mo agoSafari is snappier now
- bombcar 6mo agoBut the Finder is not. FTFF
- bombcar 6mo agoI remember verifying it really DID fix some problems (just not all) and it was so easy to do you might as well always do it. (You could see permissions errors in the logs that would go away after running it, which often didn't really fix anything but could make it faster since it didn't have to error out.)
- throwyu 6mo agoI never trust american and Chinese companies
- cifer_security 6mo ago[flagged]
- 4nonverbal-alit 6mo agoWhy 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
- TeMPOraL 6mo agoAnother 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.
- xvector 6mo agoYet more AI slop on HN
- concinds 6mo agoThere'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 6mo agoThat 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-access-to-files-secddd1d86a6/1/web/1 https://support.apple.com/guide/security/controlling-app-acc...
- binaryturtle 6mo agoI 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 6mo agoWhat is the arcane Terminal command to undo this access?
- cedws 6mo agoIs 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?
- concinds 6mo agoThese 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.
- saagarjha 6mo agoNo?
- isodev 6mo agoIt’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.
- ezfe 6mo agoThis 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.
- jijji 6mo agolinux and unix before it has been a pretty consistent interface for decades, especially since the introduction of X windows in the 1980's..
- jms703 6mo agoSo the title should be something more like "macOS apps retain access to folders after access is removed by the user".
- ezfe 6mo agoNope. 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.
- jeremyjh 6mo agoIts 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 6mo agoThe 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 6mo agoNo, 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.
- ezfe 6mo agoIt’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.
- glitchc 6mo ago> The UI just doesn’t reflect this. That's the bug. Either that or MacOS has two separate/distinct mechanisms for managing permissions, which would be a huge security flaw.
- ezfe 6mo agoMacOS has two distinct mechanisms. One gates access to Desktop, Documents, etc. for general access. The other grants access through the Open dialog. The open dialog is always superior because it's consent for a specific location.
- heyaco 6mo agois this is why apple pushed an update yestersay?
- lapcat 6mo agoNo.
- oceanplexian 6mo agoWell 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.
- lapcat 6mo agoIt 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.
- ezfe 6mo agoDoesn’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.
- lapcat 6mo agoWhy 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.
- kccqzy 6mo agoIt’s working properly in the sense that the Apple-provided file picker UI is designed to give permanent file permission access to an app. But the user thinks that access is temporary. It’s a mismatch between the user’s mental model and what’s actually happening.
- lapcat 6mo ago> It’s working properly in the sense that the Apple-provided file picker UI is designed to give permanent file permission access to an app. In the case of sandboxed apps, this is not true. The open panel provides temporary access, and a sandboxed app needs to create a security-scoped bookmark to retain persistent access across launches. For non-sandboxed apps, it's usually not an issue, because non-sandboxed apps have access to most of the file system by default. The weirdness occurs only for certain files and folders that are restricted by TCC, such as Desktop and Documents. But for non-restricted folders, nothing needs to be done. Observe that if you use the Open from folder... command from Insent on a non-restricted folder, then no com.apple.macl is set on the folder. No special permanent access is granted, because none is required. The only time the system automatically grants permanent access is with TCC-restricted files and folders, so we can't pretend that this is a "normal" thing. In general, non-sandboxed apps don't even need the open panel for file access. They can just read whatever file they want... except for the TCC-restricted files. The purpose of the open panel in a non-sandboxed app is just to provide a file picker UI to the user.
- nottorp 6mo agoActually 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 6mo agocould the same be said of iOS?
- KaiLetov 6mo agoSo 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 6mo agoI 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...