In my mind, the installer issue is an issue of trust. Do you trust the "installer" of an application to install the application in the best interest of the user. Do you trust that the installer won't install things you don't want. Do you trust that the installer provides a way to uninstall the application completely when its done.
The resounding answer to all of these questions is NO. This is one of the primary reasons why the Windows platform gets a black eye. Applications typically recklessly install themselves, overwriting other applications data, installing additional unwanted features deep into the operating system without the user being told resulting in spyware, nagware or annoyware under the guise of providing the user some wonderful feature. I've worked on many platforms for many years, from Windows to many varieties of Unix to mainframes. I believe that the only way to solve this problem of trust is to not trust the installer. That means that the operating system provides rigid constraints on what the installer can do without asking the operating system. Two options work: 1. Do not allow the application to modify anything that can affect other applications or the system overall. In my mind this is the typical Mac OS X approach today doing a manual install. The application is contained within one directory (bundle). The user can place that application wherever they want. It does NOT need to be a priviledged location. 2. If an application must modify the system beyond its own bounds, then the installer is forced to run within a sandbox controller by the operating system. The operating system provides an API through which ANY system modification is done. In this way the operating system can audit and log any activities the installer is doing. In this way the operating system can ensure that the operations can be undone to completely remove the application at a later time. A user could potentially use the install log to determine if unwanted activities have occurred. To emphasize what others have said... if Mac OS X moves away from its current manual install model, it risks the same installer abuses common in the WIndows world and one of its primary advantages over Windows will have been lost. >From a security perspective, I deride any Mac OS X application which requires an installer. I have never seen one which allowed me to install in a non privileged location. On Wed, Sep 10, 2008 at 9:21 AM, Scott Anguish <[EMAIL PROTECTED]> wrote: > probably best not to debate this particular aspect of things... > > As I said, I'll about getting this clarified in the docs, and a consistent > message in it. > > > On 10-Sep-08, at 3:40 AM, Charles Srstka wrote: > >> On Sep 9, 2008, at 4:26 PM, Bill Cheeseman wrote: >> >>> The poster didn't say why he assumes the Software Delivery Guide to be >>> more >>> authoritative. The only evidence I'm aware of is that the Software >>> Delivery >>> Guide was last updated over two years ago, in July 2006, before Leopard >>> was >>> released. The PackageMaker User Guide is a year newer, and it states that >>> it >>> applies to Leopard. On that evidence, I'm more inclined to think the >>> PackageMaker User Guide is authoritative with respect to Leopard. >> >> Well, the Software Delivery Guide is, as the name suggests, the guide to >> how you should deliver software, and is not intended to be a usage manual >> for any one specific method. The PackageMaker manual is a document >> describing how to use one specific application for software delivery, >> written by people who probably *would* like you to use their product. To my >> mind, it's like the difference between getting polling data from an >> independent polling site vs. getting data from Obama or McCain's web site. >> >> Anyway, if Mac software starts heading back down the road to everything >> having an installer, the appeal of the Mac platform vs. Windows will be >> severely diminished in my eyes. Drag and drop puts the user in control - >> installers put the user at their mercy. Whenever I see an installer that >> does nothing but put an app in /Applications, I tend to think twice about >> using that app, because it's often a sign of a poorly thought out product. >> Often I will send an e-mail to the author complaining about this as well. > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/enki1711%40gmail.com > > This email sent to [EMAIL PROTECTED] > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
