← Back to context

Comment by tpmoney

15 hours ago

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.

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.

  • That URL should expire after a relatively short time.

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

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

    • “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”?

      1 reply →

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

      1 reply →