3 ms·

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.

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.