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.
You can't trust macOS Privacy and Security settings
81–90 of 175 posts
Re: You can't trust macOS Privacy and Security settings
#82Eye-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.
Re: You can't trust macOS Privacy and Security settings
#83Re: You can't trust macOS Privacy and Security settings
#84Earlier quoted context omitted.
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
I think the issue is more like: - it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism. - it's non-obvious that the second mechanism (a file picker) is a permission granting mechanism whose permission survives the action context that triggered the file picker (e.g "pick a folder to do action A" also magically imbues similarly gated actions B C D and Z with access to that folde…
This is a result of trying to retrofit a series of tighter security measures on top of a system that was not originally designed for them, in a way that is both understandable to users but also doesn't break back-compat with APIs (and therefore a lot of existing third-party apps that are seldom updated) too badly. I'm not saying Apple did a perfect job here, but it's a hard problem.
Yes, the problem could probably be "solved" by adding more UI, but "more UI" is not always a good solution. The more UI that exists, the less likely the user is to successfully navigate it. On the other hand, adding additional complexity to an existing UI is also fraught with potential for new bugs and edge cases. Again, not defending the status quo, but I can see how it might have ended up like this.
This is worth spending more time on trying to improve, and perhaps it is reasonable to expect better from an almost-$4tn company. But at the same time, a potential solution is far from easy or obvious, and there is a risk of making things worse if not done with an extreme level of thought and consideration.
(Alternate pessimistic take: A large number of users don't care or read anything, they just click "allow" on anything that gets in their way. A smaller set of users are terrified and disgusted by repeated invasions of the privacy and click "deny" on everything. None of these implementations are doing any good for either group. The allow/deny design pattern is badly broken and in need of rethinking.)
Re: You can't trust macOS Privacy and Security settings
#85Earlier quoted context omitted.
"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 tra…
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.
Same way you select a picture on iOS. It is your deliberate decision and intent to open the document with that application.
That is totally different from the application having permission to scan and view anything in for example the downloads folder
Re: You can't trust macOS Privacy and Security settings
#86Earlier quoted context omitted.
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.
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 intera…
No, it is, the comment you're replying to is correct in what it said to you.
> The Privacy settings applies only to access to the Documents folder without the user interaction.
Yes, BUT, the user interaction is irrevocable. There are two user interactions here, one is "please access Documents this one time" and the second is "please don't let this app access Documents again."
Of course, if the stakes were higher you wouldn't even think to defend this behavior. Like if you were dealing with a nuclear weapon launcher and there was a big panel saying "TARGETING SYSTEMS: 0 targets (Permission Lock sandbox excluding 450 potential targets needing approval)" and then you poked around and found out "uh... why can I still go into the interface and target Milan and the big glowy 'launch missiles' light then starts lighting up and presumably I can launch a nuclear strike on Milan?!" and someone says, "oh yeah, that's because back when we were demoing it, the general had us punch in a random city to show what the targeting UI looked like, and we randomly chose Milan... it's okay, to fix it someone just needs to go and manually remove the warhead and put in a different one and then we'll restart the system and it'll forget all its targeting data for the old warhead" -- that'd strike you as unsustainable.
But this is very low-stakes for us so it seems less outrageous, but fundamentally it is a solid buggy behavior, "The UI makes it sound like there is only one system at play here, but there are actually two and the other system can override a specific revocation that's placed at the level the UI controls." Even if there are going to be two systems, you expect that their security controls will both be followed, or that the second one will know enough to be able to say "I say no, but I am being overruled" in its status panel.
Re: You can't trust macOS Privacy and Security settings
#87The 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 f…
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.
Re: You can't trust macOS Privacy and Security settings
#88Re: You can't trust macOS Privacy and Security settings
#89It 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?
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.
Re: You can't trust macOS Privacy and Security settings
#90Eye-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.
Don’t applications running under your user account have access to your user’s home folder by default?