31–40 of 175 posts
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??
The gotcha is “I gave it permission, then revoked permission in the UI, but it still has permission.”
Earlier quoted context omitted.
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 reflec…
"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 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…
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 do…
Earlier quoted context omitted.
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 reflec…
"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…
Is this part true? The article's fix involves running a command and rebooting the computer. If restarting the app was sufficient, surely you wouldn't need the command/reboot?
Earlier 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.
The Privacy settings applies only to access to the Documents folder without the user interaction.
> 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
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.
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??
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 reflec…
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 graf…
Earlier 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…
> during the same run of the app Is this part true? The article's fix involves running a command and rebooting the computer. If restarting the app was sufficient, surely you wouldn't need the command/reboot?