3 ms·

> If I'm using the App Store stuff, then my text editor can't edit all my files, my video player can't open videos when I double-click them, my Evernote can't p

> If I'm using the App Store stuff, then my text editor can't edit all my files, my video player can't open videos when I double-click them, my Evernote can't print to PDF, my disk usage analyzer can't analyze my disk because it can't ask me for authorization to do so, and so on. I fail to see how the macOS sandbox prevents this. Disk usage analyser can ask you for disk access, sandboxed video players can surely open files double clicked in Finder, sandboxed apps can print to PDF. A few example: QuickTime Player is sandboxed, Pages is sandboxed.

veidr 9y ago
> I fail to see how the macOS sandbox prevents this I think you might be thinking of the reasonable sandbox we wish we had, not the one we have. https://daisydiskapp.com/manual/4/en/Topics/Editions.html https://daisydiskapp.com/manual/4/en/Topics/Editions.html (Apple's own apps do not have to follow the rules that third-party apps do.)
- galad87 9y ago
  Ok, that's a limitation. What about the other ones you described? I wrote a bunch of sandboxed app, and it's good enough for a document based app (when working on a single document).
  - namelost 9y ago
    The sandbox allows apps to open files via three methods: * Open dialogs * A limited number of files that have been opened in the past via open dialogs (intended for e.g. recent files) * Files that live in the app's sandboxed region of the filesystem. That's it. So your text editor can't open ~/.bash_profile unless it pops up an open dialog and asks you to manually click it.
    - X-Istence 9y ago
      Which is a good thing for most users, just not the power users that would potentially want their editor to open ~/.bash_profile (although the downside is that if they were allowed to do so, they could do so silently as well... which is the problem Apple is trying to solve for).
    - ntaoe09unteont 9y ago
      How exactly is that a problem? You can open an open file dialog that is in the user's home directory and you can even select ".bash_profile" for them. All they have to do is click "OK" to start editing it. This gives them the security that your app can't just go and erase or overwrite or add malicious stuff to their .bash_profile without their consent, which seems like a really good idea!
    - PeterisP 9y ago
      I'm a bit confused - if I explicitly want my text editor to open ~/.bash_profile, then I need to tell it that, which I would do through the Open dialog for GUI apps (or as a command line parameter for command line apps); and if I don't explicitly want to do so, then it probably shouldn't be opening it behind my back. This sandboxing would be a problem with editors that naturally work with multi-file projects (e.g. an IDE where you'd want to open a whole Java project of linked files), but in the text editor scenario this limitation seems to make sense.
nicky0 9y ago
Those examples don't make any sense. All of them are possible within sandbox except perhaps the disk usage analyser.

veidr 9y ago

> I fail to see how the macOS sandbox prevents this I think you might be thinking of the reasonable sandbox we wish we had, not the one we have. https://daisydiskapp.com/manual/4/en/Topics/Editions.html https://daisydiskapp.com/manual/4/en/Topics/Editions.html (Apple's own apps do not have to follow the rules that third-party apps do.)

galad87 9y ago
Ok, that's a limitation. What about the other ones you described? I wrote a bunch of sandboxed app, and it's good enough for a document based app (when working on a single document).
- namelost 9y ago
  The sandbox allows apps to open files via three methods: * Open dialogs * A limited number of files that have been opened in the past via open dialogs (intended for e.g. recent files) * Files that live in the app's sandboxed region of the filesystem. That's it. So your text editor can't open ~/.bash_profile unless it pops up an open dialog and asks you to manually click it.
  - X-Istence 9y ago
    Which is a good thing for most users, just not the power users that would potentially want their editor to open ~/.bash_profile (although the downside is that if they were allowed to do so, they could do so silently as well... which is the problem Apple is trying to solve for).
  - ntaoe09unteont 9y ago
    How exactly is that a problem? You can open an open file dialog that is in the user's home directory and you can even select ".bash_profile" for them. All they have to do is click "OK" to start editing it. This gives them the security that your app can't just go and erase or overwrite or add malicious stuff to their .bash_profile without their consent, which seems like a really good idea!
  - PeterisP 9y ago
    I'm a bit confused - if I explicitly want my text editor to open ~/.bash_profile, then I need to tell it that, which I would do through the Open dialog for GUI apps (or as a command line parameter for command line apps); and if I don't explicitly want to do so, then it probably shouldn't be opening it behind my back. This sandboxing would be a problem with editors that naturally work with multi-file projects (e.g. an IDE where you'd want to open a whole Java project of linked files), but in the text editor scenario this limitation seems to make sense.

nicky0 9y ago

Those examples don't make any sense. All of them are possible within sandbox except perhaps the disk usage analyser.