5 ms·

Mac OS is a multi-user operating system. Most applications that are installed are global to the system although each user also has their own Applications folder

by donarb 7y ago

Mac OS is a multi-user operating system. Most applications that are installed are global to the system although each user also has their own Applications folder. The Application Support folder resides in the user's Library folder and contains information that the app needs when running for that particular user. Storing information in the .app bundle would affect every user on that computer.

taftster 7y ago
You're saying that an application can't write user specific information into the bundle and sort that out? There's no difference between these two (hypothetical) file paths: /Applications/SomeApp.app/users/taftster/user.specific.data /Users/taftster/Library/Application Support/SomeApp/user.specific.data These two file paths are effectively the same. And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well. And no, I'm not talking about saved output (documents, etc.) that are generated by the application. I'm saying there is just no need for Application Support at all; it adds no value and is just used by convention.
- comex 7y ago
  > /Applications/SomeApp.app/users/taftster/user.specific.data This doesn't work well for a few reasons: - The Unix permission model makes it difficult to set that up in a way that doesn't allow someone to access someone else's user-specific data, or otherwise tamper with the app. - Some setups sync home directories across the network, so everything related to a particular user needs to be under their home directory. Applications, on the other hand, would be part of the read-only OS image. - If you delete a user in System Preferences, it gives you the option to delete their data or archive it. This works by deleting or archiving their home directory; things would be much messier if their data were scattered all over the disk. - It breaks the concept of an app bundle as a immutable, sealed tree that can have its validity checked via code signature. - If you're searching through your disk to see what's using up disk space, mingling user data with the app itself makes it harder to distinguish between the two. - If the app decides to start storing its data in iCloud and syncing it across devices, it wouldn't make any sense to have it within the app bundle: among other things, you don't want the app's immutable data (i.e. what's in the app bundle today) to count towards your storage quota, and the data may be shared between, e.g., the macOS and iOS version of an app. (Application Support itself is not synced to iCloud, though.) > And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well. Do you? - What if you're just upgrading the app? If you download a new app bundle, drag it into Applications, and tell Finder to overwrite, it will delete everything in the old bundle. - What if you're migrating to a new Mac? You may prefer to reinstall applications manually instead of copying everything, but that doesn't mean you want to lose your data. - Even if you do want to delete the app entirely, does that actually mean you want to lose your data from that app? What if you're planning on reinstalling it in the future? iOS does automatically delete data when deleting an app, but it's not at all obvious to me that that's the best behavior.
  - taftster 7y ago
    All these are fair and good points. But all of these are still workable problems that should be very much in the capable hands and constraints of the operating system and "app bundle runner" (call it) to deal with. Your points are all solved by using the user's home directory, very true. But the problem simply remains -- I think this is my main point -- that the "App bundle" has failed the user by not allowing for cleanup of everything that the application has created. If an application can simply write any executable into any user directory it wants, there's no code signing or integrity checks on the app itself that matters. Applications should be treated as hostile, just like a user is treated in a multi-user system. I think it's a failure of an operating system to not be completely in control of the limitations and installation of any program. It's also a failure of the developer community to not stand up and insist on this too. A sand-boxed model is what we should all be striving for here. Force the bad actors out. I'm not a Mac developer (obviously). But I am an old Unix neckbeard. So I get all of your points; Unix invented this problem. In a multiuser system, individual users are treated as hostile. Going forward, so too should applications. That's the failure in all of this (and it's been with us a long time now). Our security model is based on not trusting users, but in trusting applications. This thinking was born in the 60's when users couldn't install/execute any random download. It's interesting that the unix model of security is hurting us more today than helping. The time for sandboxed applications is definitely overdue.
    - comex 7y ago
      For the record, sandboxed macOS apps do exist (as someone mentioned upthread) and have a design somewhat similar to what you're describing, but uglier for the sake of backwards compatibility. For each app you have a directory like /Users/foo/Library/Containers/com.some.bundleid/Data, which is an entire virtualized home directory, containing not just a Library subdirectory but also Desktop, Documents, Downloads, etc. The latter directories shouldn't actually be used, but they're there in case some legacy code tries to access them. When an app presents an open or save dialog, the dialog is out-of-process and unsandboxed, so the user can pick a file from their real home directory or anywhere else; once they do so, the app is automatically granted the ability to access that particular file.
- donarb 7y ago
  In addition, users can run applications from a CDROM or a read only USB stick, where the app would not be able to write anything.
- Twisell 7y ago
  It’s a design choice, and of course it arguable but it have it’s (good) reasons. By design choice user data of any App should be only be readable and modifiable by the active user. If user data is stored somewhere under home folder, this mechanism comes for free for the App developer and the OS handle it. If you want that same level of privacy in the App Bundle developers would have to handle it themselves (and well). But then what happen when you uninstall ? Either you are blocked because you can’t remove data from another user or you somehow require escalation to admin privileges to remove data of all users at once. Which might or might not make other users happy if they were unaware of the uninstall... With current data model choice (pretty much shared across all UNIX world and even Windows). If user A delete the App but user B still needed it you just have to reinstall to keep user B unharmed. Your proposal is not bad to optimize for disk space gain at removal, it just happen that (quite rightfully) OS vendors chooses to rather optimize for data persistence and security.
- pishpash 7y ago
  You're trading one problem for another. What if I want to delete a user instead? Now I have that user's crap in every application bundle. However, the OS should perhaps insist on a particular location within "Application Support/" that each app can write to, and when the application bundle is deleted, provide a way to delete those support files as well, either for that user alone or for all users within permission (can be a system-wide configuration).
  - taftster 7y ago
    I would argue, I think most systems have more quantity and churn of applications than users. Meaning, it would be better to pay some overhead to deal with "user's crap" in every application bundle than to deal with "application crap" in every user's home. Your second paragraph though is probably closer to a realistic solution. That is, the OS provisions an Application Support directory and restricts the application to using it exclusively. Any application uninstalls can (via admin prompting or configuration settings) then also delete the support directories as well.
- jinglebells 7y ago
  You absolutely wouldn't want user data stored in app bundles. You can back up all user data by backing up /Users/ or /home/ on Linux. As an application developer, I want to be able to drop a new bundle over the old version and NOT LOSE ANY USER DATA. The only way to do that is separate them completely.

by donarb 7y ago

taftster 7y ago

You're saying that an application can't write user specific information into the bundle and sort that out? There's no difference between these two (hypothetical) file paths: /Applications/SomeApp.app/users/taftster/user.specific.data /Users/taftster/Library/Application Support/SomeApp/user.specific.data These two file paths are effectively the same. And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well. And no, I'm not talking about saved output (documents, etc.) that are generated by the application. I'm saying there is just no need for Application Support at all; it adds no value and is just used by convention.

comex 7y ago
> /Applications/SomeApp.app/users/taftster/user.specific.data This doesn't work well for a few reasons: - The Unix permission model makes it difficult to set that up in a way that doesn't allow someone to access someone else's user-specific data, or otherwise tamper with the app. - Some setups sync home directories across the network, so everything related to a particular user needs to be under their home directory. Applications, on the other hand, would be part of the read-only OS image. - If you delete a user in System Preferences, it gives you the option to delete their data or archive it. This works by deleting or archiving their home directory; things would be much messier if their data were scattered all over the disk. - It breaks the concept of an app bundle as a immutable, sealed tree that can have its validity checked via code signature. - If you're searching through your disk to see what's using up disk space, mingling user data with the app itself makes it harder to distinguish between the two. - If the app decides to start storing its data in iCloud and syncing it across devices, it wouldn't make any sense to have it within the app bundle: among other things, you don't want the app's immutable data (i.e. what's in the app bundle today) to count towards your storage quota, and the data may be shared between, e.g., the macOS and iOS version of an app. (Application Support itself is not synced to iCloud, though.) > And when the "global" application gets deleted, I most definitely want all the user data deleted with it as well. Do you? - What if you're just upgrading the app? If you download a new app bundle, drag it into Applications, and tell Finder to overwrite, it will delete everything in the old bundle. - What if you're migrating to a new Mac? You may prefer to reinstall applications manually instead of copying everything, but that doesn't mean you want to lose your data. - Even if you do want to delete the app entirely, does that actually mean you want to lose your data from that app? What if you're planning on reinstalling it in the future? iOS does automatically delete data when deleting an app, but it's not at all obvious to me that that's the best behavior.
- taftster 7y ago
  All these are fair and good points. But all of these are still workable problems that should be very much in the capable hands and constraints of the operating system and "app bundle runner" (call it) to deal with. Your points are all solved by using the user's home directory, very true. But the problem simply remains -- I think this is my main point -- that the "App bundle" has failed the user by not allowing for cleanup of everything that the application has created. If an application can simply write any executable into any user directory it wants, there's no code signing or integrity checks on the app itself that matters. Applications should be treated as hostile, just like a user is treated in a multi-user system. I think it's a failure of an operating system to not be completely in control of the limitations and installation of any program. It's also a failure of the developer community to not stand up and insist on this too. A sand-boxed model is what we should all be striving for here. Force the bad actors out. I'm not a Mac developer (obviously). But I am an old Unix neckbeard. So I get all of your points; Unix invented this problem. In a multiuser system, individual users are treated as hostile. Going forward, so too should applications. That's the failure in all of this (and it's been with us a long time now). Our security model is based on not trusting users, but in trusting applications. This thinking was born in the 60's when users couldn't install/execute any random download. It's interesting that the unix model of security is hurting us more today than helping. The time for sandboxed applications is definitely overdue.
  - comex 7y ago
    For the record, sandboxed macOS apps do exist (as someone mentioned upthread) and have a design somewhat similar to what you're describing, but uglier for the sake of backwards compatibility. For each app you have a directory like /Users/foo/Library/Containers/com.some.bundleid/Data, which is an entire virtualized home directory, containing not just a Library subdirectory but also Desktop, Documents, Downloads, etc. The latter directories shouldn't actually be used, but they're there in case some legacy code tries to access them. When an app presents an open or save dialog, the dialog is out-of-process and unsandboxed, so the user can pick a file from their real home directory or anywhere else; once they do so, the app is automatically granted the ability to access that particular file.
donarb 7y ago
In addition, users can run applications from a CDROM or a read only USB stick, where the app would not be able to write anything.
Twisell 7y ago
It’s a design choice, and of course it arguable but it have it’s (good) reasons. By design choice user data of any App should be only be readable and modifiable by the active user. If user data is stored somewhere under home folder, this mechanism comes for free for the App developer and the OS handle it. If you want that same level of privacy in the App Bundle developers would have to handle it themselves (and well). But then what happen when you uninstall ? Either you are blocked because you can’t remove data from another user or you somehow require escalation to admin privileges to remove data of all users at once. Which might or might not make other users happy if they were unaware of the uninstall... With current data model choice (pretty much shared across all UNIX world and even Windows). If user A delete the App but user B still needed it you just have to reinstall to keep user B unharmed. Your proposal is not bad to optimize for disk space gain at removal, it just happen that (quite rightfully) OS vendors chooses to rather optimize for data persistence and security.
pishpash 7y ago
You're trading one problem for another. What if I want to delete a user instead? Now I have that user's crap in every application bundle. However, the OS should perhaps insist on a particular location within "Application Support/" that each app can write to, and when the application bundle is deleted, provide a way to delete those support files as well, either for that user alone or for all users within permission (can be a system-wide configuration).
- taftster 7y ago
  I would argue, I think most systems have more quantity and churn of applications than users. Meaning, it would be better to pay some overhead to deal with "user's crap" in every application bundle than to deal with "application crap" in every user's home. Your second paragraph though is probably closer to a realistic solution. That is, the OS provisions an Application Support directory and restricts the application to using it exclusively. Any application uninstalls can (via admin prompting or configuration settings) then also delete the support directories as well.
jinglebells 7y ago
You absolutely wouldn't want user data stored in app bundles. You can back up all user data by backing up /Users/ or /home/ on Linux. As an application developer, I want to be able to drop a new bundle over the old version and NOT LOSE ANY USER DATA. The only way to do that is separate them completely.