Great article. On point "One", you omit an even more serious problem about putting the preference file(s) in the app bundle: security.
Assuming you could still properly handle the multi-user paradigm correctly by placing multiple files in the .app bundle, you still require user write permissions to things in your app. You might be able to set up the directory structure such that only user write permissions are granted to the preferences files, but this presents additional problems. In multiple user situations, you have to prevent (malicious) users from being able to look at, modify, and corrupt other user preferences. Assuming you could pull this off, I think the solution is very messy (sticky bits?, access control lists?) and probably begging to be cracked.
And on fortified systems where Applications are placed in areas that are write-only, this is going to be a problem since the user shouldn't be able to create any files at all.
There are also Unix paradigms where you install different things to different partitions on your disk (for administration and/or security purposes). In this paradigm, you install applications to its own partition (and possibly mount it as read-only, and could also be a network mount), and you minimize the amount of free space on this partition. Assuming you didn't mount the partition as read-only and let users write to it, the small amount of free space could become a problem if enough users create enough large preference files to eat up all the disk space (which itself can be considered a form of attack).
by Eric Wing — Oct 16
Assuming you could still properly handle the multi-user paradigm correctly by placing multiple files in the .app bundle, you still require user write permissions to things in your app. You might be able to set up the directory structure such that only user write permissions are granted to the preferences files, but this presents additional problems. In multiple user situations, you have to prevent (malicious) users from being able to look at, modify, and corrupt other user preferences. Assuming you could pull this off, I think the solution is very messy (sticky bits?, access control lists?) and probably begging to be cracked.
And on fortified systems where Applications are placed in areas that are write-only, this is going to be a problem since the user shouldn't be able to create any files at all.
There are also Unix paradigms where you install different things to different partitions on your disk (for administration and/or security purposes). In this paradigm, you install applications to its own partition (and possibly mount it as read-only, and could also be a network mount), and you minimize the amount of free space on this partition. Assuming you didn't mount the partition as read-only and let users write to it, the small amount of free space could become a problem if enough users create enough large preference files to eat up all the disk space (which itself can be considered a form of attack).