3 ms·

I'm sure this will make the user experience even worse. It seems we've the wrong lessons from Windows Vista's constant "Cancel/Allow" prompts.

Someone 3y ago
Why? Every sandboxed application will have a directory it can freely read from and write to, and if developers do their job (https://developer.apple.com/documentation/security/app_sandbox/accessing_files_from_the_macos_app_sandbox https://developer.apple.com/documentation/security/app_sandb...), files selected using the system open/save dialogs will still be readable/writable by the application. That page describes a couple of other scenarios, so Apple at least has given this some thought. So, developers will have to do more. I think that’s acceptable for the additional security that the users get, but that’s another discussion.
- lapcat 3y ago
  > So, developers will have to do more. Do what? As I said at the end of the article, there's no way for a non-sandboxed app to preserve the granted file access across launches.
  - Someone 3y ago
    Sandbox their app and configure it properly.
    - lapcat 3y ago
      > Sandbox their app Just sandbox a non-sandboxed app. Yeah, thanks for your input. > and configure it properly. This is nonsense. A sandboxed app only has access to its own container, so it's a non-solution to the problem of accessing the container of another app.
      - Someone 3y ago
        But how many apps need that? Can you give examples?
        lapcat 3y ago
        Yes. For example, Mac developers commonly have a non-sandboxed version of their app outside the Mac App Store and a sandboxed version inside the Mac App Store. If the user ever needs to switch between the two versions, then the non-App Store version needs access to the App Store version's container. Another example: sometimes a developer has a sandboxed sub-application embedded inside the main non-sandboxed application, for the purposes of security or crash protection, if the sub-app is loading arbitrary content from the internet. So now there would be a scary dialog every time the main application is launched and needs to access the container of the sub-application. There are countless scenarios that you've never thought of, and that Apple has never thought of. In fact, that's one of the main purposes of having a 3rd party developer ecosystem. You never know exactly what could be useful until someone clever and imaginative makes it. I've personally worked on a lot of software that users love but that would be banned by simple-minded fearmongering about "security". This is one of the reasons why the once thriving Mac software ecosystem is becoming quite barren nowadays. It won't be long before the Mac becomes nothing more than an ultra-expensive iPad.
        Someone 3y ago
        > If the user ever needs to switch between the two versions, then the non-App Store version needs access to the App Store version's container. If you resist sandboxing, yes, but the idea is to have the non-app store app sandboxed, too. If so, that would (at worst; possibly, the two binaries can be identical) be a one-time dialog, wouldn’t it? > So now there would be a scary dialog every time the main application is launched and needs to access the container of the sub-application. Isn’t that what the sections “Share file access between processes with URL bookmarks” or “Persist access to files with security-scoped URL bookmarks” cover? Launch a subprocess to do the dangerous thing, and have that send back such an url to the main process. TLDR: I may be overlooking something, but I think Apple’s message is that they want all apps to be sandboxed (for what you call fear mongering about security, but I think opinions will differ on that), and are willing to take collateral damage of making non-sandboxed applications harder to use.

Someone 3y ago

Why? Every sandboxed application will have a directory it can freely read from and write to, and if developers do their job (https://developer.apple.com/documentation/security/app_sandbox/accessing_files_from_the_macos_app_sandbox https://developer.apple.com/documentation/security/app_sandb...), files selected using the system open/save dialogs will still be readable/writable by the application. That page describes a couple of other scenarios, so Apple at least has given this some thought. So, developers will have to do more. I think that’s acceptable for the additional security that the users get, but that’s another discussion.

lapcat 3y ago
> So, developers will have to do more. Do what? As I said at the end of the article, there's no way for a non-sandboxed app to preserve the granted file access across launches.
- Someone 3y ago
  Sandbox their app and configure it properly.
  - lapcat 3y ago
    > Sandbox their app Just sandbox a non-sandboxed app. Yeah, thanks for your input. > and configure it properly. This is nonsense. A sandboxed app only has access to its own container, so it's a non-solution to the problem of accessing the container of another app.
    - Someone 3y ago
      But how many apps need that? Can you give examples?
      - lapcat 3y ago
        Yes. For example, Mac developers commonly have a non-sandboxed version of their app outside the Mac App Store and a sandboxed version inside the Mac App Store. If the user ever needs to switch between the two versions, then the non-App Store version needs access to the App Store version's container. Another example: sometimes a developer has a sandboxed sub-application embedded inside the main non-sandboxed application, for the purposes of security or crash protection, if the sub-app is loading arbitrary content from the internet. So now there would be a scary dialog every time the main application is launched and needs to access the container of the sub-application. There are countless scenarios that you've never thought of, and that Apple has never thought of. In fact, that's one of the main purposes of having a 3rd party developer ecosystem. You never know exactly what could be useful until someone clever and imaginative makes it. I've personally worked on a lot of software that users love but that would be banned by simple-minded fearmongering about "security". This is one of the reasons why the once thriving Mac software ecosystem is becoming quite barren nowadays. It won't be long before the Mac becomes nothing more than an ultra-expensive iPad.
        Someone 3y ago
        > If the user ever needs to switch between the two versions, then the non-App Store version needs access to the App Store version's container. If you resist sandboxing, yes, but the idea is to have the non-app store app sandboxed, too. If so, that would (at worst; possibly, the two binaries can be identical) be a one-time dialog, wouldn’t it? > So now there would be a scary dialog every time the main application is launched and needs to access the container of the sub-application. Isn’t that what the sections “Share file access between processes with URL bookmarks” or “Persist access to files with security-scoped URL bookmarks” cover? Launch a subprocess to do the dangerous thing, and have that send back such an url to the main process. TLDR: I may be overlooking something, but I think Apple’s message is that they want all apps to be sandboxed (for what you call fear mongering about security, but I think opinions will differ on that), and are willing to take collateral damage of making non-sandboxed applications harder to use.