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

[what]

Isn’t it exactly the same on iOS? If you select a folder, the app gets a security scoped URL for the folder and can read/write the entire tree. The app can also then create a bookmark to persist the security scoped url and use it whenever in the future.

[ted_dunning]

That URL should expire after a relatively short time.

[zarzavat]

This rules out entire classes of app and would make using a computer a miserable experience.

For example let's say you want to make an app that every day writes a backup to a particular location e.g. 1Password can do a daily backup of your encrypted passwords to a backup location.

Or, let's say you want to make a GUI around a command line program that stores its config as a dotfile.

Without a way to save access to file system locations persistently, apps would be forced to constantly shove open panels in your face all the time.

[msephton]

Expiration depends on how the app has implemented the request for access. Granting access creates a security-scoped bookmark. The app can store it and use it the next time access is required which will bypass the prompt and the bookmark will remain valid in perpetuity (or until tcc reset), or the app can not store it and request permission every launch.

IIRC the bookmark is a base64 encoded plist containing bunch of data about the file/folder. A quick search got me this: https://www.mothersruin.com/software/Archaeology/reverse/boo...

[jagged-chisel]

“Should” meaning “I believe it currently does expire after a short time”?

Or “should” meaning “Apple should change this to expire after a short time”?

[what]

No, it shouldn’t. There are real reasons to give persistent access to a particular directory. Maybe you want your note taking app to put all notes in a directory for iCloud/dropbox/google drive/some other sync service.

[crdrost]

> That's not what's happening here.

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.

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

[jeremyjh]

I don't think any long-term implicit consent is acceptable. I would not expect that after opening one document in a folder without being shown any permission prompt, that permissions have been permanently altered. I would never even go look to see if it was "implicitly permitted".

Without a prompt or notice, I would expect only that the app has access to the file or directory I chose until the app is closed/quit.

[ted_dunning]

Why should the permission even persist that long? You might leave that app running for the next two years.

Shouldn't a temporary access be temporary? Possibly scoped by time? Possibly scoped to a single access?

[saagarjha]

How would the app be able to reopen the file then?

[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.[0]

I'm less caffeinated this morning though so maybe I misread the whole argument.

[0] edit: And whether the app still has access to that dir. Which maybe that was the point of the article. I am just skeptical generally of these kinds of exposés because while they're generally pretty fair, they'll inevitably get picked up by the geniuses on r/pcmasterrace who will spin it into "Apple Privacy and Security Settings Let Terrorists Invade Your Family Photos"

[crossroadsguy]

> Doesn't seem like a difficult fix at all.

Tell that to Apple engineering team who hasn’t been able to fix iCloud tab syncs after all this decade or so. Among hundreds of bugs that Apple users just live with, some even defend. Something tells me things in Apple’s OS architecture is so messily intertwined and too many things hardcoded that even competent software engineers at Apple will start having nightmares at the thought of touching them. Perils of a completely closed ecosystem (and don’t mean closed source).

[traderj0e]

The real problem with this isn't so much that it doesn't show the implicit consent. That would be nice but not a big deal. It's that it shows explicit non-consent that is getting ignored.

  8. Confirm that Documents access for Insent is still disabled in Files & Folders.

[ksidjwicjwjd]

Eeeeeh not quite. It depends on the app. Take Adobe’s apps, for instance, you may revoke access to documents but they will still create a bunch of cache and setting files in there whether you want it or not, there simply is no way to revoke these permissions—and these are not files created by the user in any conceivable way.

[traderj0e]

Other comment seems accurate

[jbverschoor]

You “feed” it the document.

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

[wlesieutre]

When you use iOS's "limited access" permissions to give an app access to some of your photos but not the whole library, the photo picker UI does a pretty good job of letting you easily do three things:

1) Grant access to a photo

2) Identify which photos you've granted access to

3) Revoke previously granted access

macOS's concession to give access to whole folders at a time is necessary for real software to work, but they haven't done a good job of items 2 and 3.

[jbverschoor]

Sure.

But the proper api call to make is selecting a picture. Not access to the photo library. That is an api design flaw, and simply a bad / obsolete implementation by the app developer.

The complaint of the OP is that he can still open a file which is in the downloads folder. But that’s not what the user is doing.

There’s no reason to give folder access at all. (Except for file sorting apps etc).

The only “reason” would be that it’s more difficult for developers to atomically overwrite a file in the same locations. And quite frankly, they should (and perhaps already do) have api calls for exactly that. I think this is why many apps request access sometimes.

[wlesieutre]

I'm trying to think of a scenario where a users hits Open and picks a directory but does not want the software to have access to the contents of that directory. If you don't want it to access a folder, then don't open a folder in it.

This behavior gets used all the time in things like opening a folder in your IDE so it can access the whole project.

The OS does allow file pickers that can only pick files and not directories (set canChooseDirectories = false), and if an app has no legitimate reason to need a directory they should do that, but the fact that you can grant permissions isn't the problem. What they need to fix is that you're granting permanent permissions with no indication that you've done it and no way to remove them.

To anyone at Apple reading this - please do not draw the conclusion "permissions to access a previously opened file or folder should expire after 24 hours" there are already more than enough permission prompts.

[simoncion]

> I'm trying to think of a scenario where a users hits Open and picks a directory but does not want the software to have access to the contents of that directory.

Firstly: If that user has explicitly disallowed access to a particular directory in a system-wide filesystem access control dialog, the intent to prevent access to that directory seems completely clear. In cases like this, it seems fine to me to have a "Grant read/write/list permissions to this directory? [Once] [Forever]" dialog that this access attempt causes to pop up.

Secondly: Directories with XY3 or XY1 permissions are not unheard of. If you want programs to be able to access a directory but not be able to list its contents, that's what you'd do. Perhaps you don't want people to be casually able to read the metadata on files in that directory. I have a vague, distant, and extremely unreliable memory that tells me that this was a technique used by some *nix mail or print spooling software way back when, but... "extremely unreliable memory".

This configuration would probably cause most GUI file pickers to shit their pants, but there's absolutely nothing that says that you need to have either 'r' or 'w' privs to a directory for a GUI file picker to actually function. Nearly every one of them that I've used contains a text box that you can use to punch in path components and filenames.

[Liquid_Fire]

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

[mh8h]

I guess not. Looks like if you choose the Documents directory once, you give your implicit permission to the app until you choose another restricted directory.