Hacker News

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

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

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.

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!

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.

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

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.

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.

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.

Someone at Apple should watch some of their old ads.

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

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.

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

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.

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.

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

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

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

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

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.

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

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.

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.

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

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

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.

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

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.

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)

Yeah, they run fine.

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.

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.

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.

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.

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

Yet more AI slop on HN

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.

Notification storage? What’s the story there?

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