7 ms·

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 no

by layer8 7mo ago

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 reflection of those that are actually applied. It’s possible for an app to have unrestricted access to one or more protected folders while its listing in Files & Folders shows it being blocked from access, or for it to have no entry at all in that list.”

mh8h 7mo ago
"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 7mo ago
  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 7mo ago
    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.
    - layer8 7mo ago
      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 7mo ago
        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.
        jakeydus 7mo ago
        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 7mo ago
        > 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).
  - jbverschoor 7mo ago
    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 7mo ago
      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 7mo ago
        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 7mo ago
        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.
- Liquid_Fire 7mo ago
  > 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 7mo ago
    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.
lynx97 7mo ago
This is so typical for Apple software "quality". While a truly love some of the features Apple has put into my pocket, I am noticing since years that at least iOS is the first commercially sold platform where I sometimes have to press a boolean toggle twice to have it take effect. They seem to have a lot of bugs around UI synchronisation.
mixmastamyk 7mo ago
Screen time is swiss cheese as well, not surprised.

by layer8 7mo ago

mh8h 7mo ago

"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 7mo ago
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 7mo ago
  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.
  - layer8 7mo ago
    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 7mo ago
      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.
      - jakeydus 7mo ago
        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 7mo ago
        > 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).
- jbverschoor 7mo ago
  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 7mo ago
    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 7mo ago
      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 7mo ago
        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.
Liquid_Fire 7mo ago
> 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 7mo ago
  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.

lynx97 7mo ago

This is so typical for Apple software "quality". While a truly love some of the features Apple has put into my pocket, I am noticing since years that at least iOS is the first commercially sold platform where I sometimes have to press a boolean toggle twice to have it take effect. They seem to have a lot of bugs around UI synchronisation.

mixmastamyk 7mo ago

Screen time is swiss cheese as well, not surprised.