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