Lets talk about a variety of Mac OS X software called Input Managers.
In brief, an Input Manager is software that can affect other running applications. The original intent of Input Managers was to provide a means for customizing the operation of the keyboard and/or mouse to support things like locale-specific input behavior (treating keyboard input differently for different languages or regions) and software that aids handicapped individuals. The name “Input Manager” is thus appropriate for these intended uses. (Read more about Text Input Management.)
However, it wasn’t long before Mac developers found this to be a useful way to graft additional functionality into other applications. There are several OS X software products out there that are input managers which have little to do with input management (Inquisitor, 1Password, Chax are three that I use today). These products are typically unstable in nature, since they often times rely on undocumented aspects of the “host” application. But when they work, they can add real useful functionality to other programs.
The downside to Input Managers is that it is a tempting means for rogue software to exploit. One such example is the “Oompa-Loompa” trojan which surfaced about two years ago. This was a download that supposedly contained pre-release screen shots of OS X 10.5. It masqueraded the installation program as an image file, and when the unsuspecting user tries to view the file, it installs itself into the user’s “Input Managers” folder. It then can access any application that is run and affects iChat in particular, so that it tries to spread to others in your iChat contact list.
One of the changes in Mac OS X 10.5 (Leopard) was in how OS X dealt with Input Managers. The early rumors were that Leopard wouldn’t permit them to run at all. But after release, Leopard did run Input Managers, but only those that are installed in the system-wide “/Library/InputManagers” folder.
The distinction is this: before Leopard, if a user runs software that tries to install an Input Manager, there is nothing to stop it from installing one that is local to that user’s account (installing it to the “/Users/username/Library/InputManagers” folder). With Leopard, installation of an Input Manager requires system-administration rights (so the user is prompted to authenticate to permit the installation), and the Input Manager is installed to the “/Library/InputManagers” folder.
The authentication requirement is the key and is a welcome change. There should be some kind of barrier to install software of this nature. BUT, it is wrong for Input Managers to only be installable in a system-wide fashion.
Before Leopard, I always— always— installed Input Managers for my own account only. By doing so, I could always login as another user to disable them. Remember— by their nature, they are less stable, and can cause applications to crash. A common request of developers when reporting bugs in their programs is to disable any third-party Input Manager software to see if it resolves the problem at hand. I could do that by logging in under a different account before Leopard, but now I cannot.
Personally, I would have preferred that user-specific Input Managers were still supported, but also require an administrator’s password to install. So, you would have a path, perhaps like “/Library/InputManagers/Users/username”, which may even be symlinked to “/Users/username/Library/InputManagers”. I think this is a better option, than requiring Input Managers to be activated for all users of that machine.
Hopefully a later update or release of OS X will address this and restore the option of user-level Input Managers.
