There's long been a controversy brewing about Input Managers in Leopard. At first it seemed that they were doomed. Now that Leopard is out, however, the news is not so dire. Input Managers are allowed in Leopard, but the restrictions on their use have increased. Apple has released a Document outlining these restrictions, and warns that Input Manager "functionality is likely to be disabled in a future release." As it stands, however, they can still work so long as the conditions are met, most importantly that they're located at /Library/Input Managers (instead of the corresponding folder in the user's home directory) and the permissions are set properly. This hint over at Mac OS X Hints sets out the procedure to make these changes with a couple of simple terminal commands. The hint itself focuses on the Safari search tool Inquisitor, but the same idea should work (in principle) for other Input Managers (though some will still be incompatible for other reasons). We also previously mentioned Plugsuit which accomplishes the same task, but apparently in a different way (see below).The sort-of final word on Input Managers in Leopard
There's long been a controversy brewing about Input Managers in Leopard. At first it seemed that they were doomed. Now that Leopard is out, however, the news is not so dire. Input Managers are allowed in Leopard, but the restrictions on their use have increased. Apple has released a Document outlining these restrictions, and warns that Input Manager "functionality is likely to be disabled in a future release." As it stands, however, they can still work so long as the conditions are met, most importantly that they're located at /Library/Input Managers (instead of the corresponding folder in the user's home directory) and the permissions are set properly. This hint over at Mac OS X Hints sets out the procedure to make these changes with a couple of simple terminal commands. The hint itself focuses on the Safari search tool Inquisitor, but the same idea should work (in principle) for other Input Managers (though some will still be incompatible for other reasons). We also previously mentioned Plugsuit which accomplishes the same task, but apparently in a different way (see below).
Reader Comments (Page 1 of 1)
11-05-2007 @ 9:40PM
Ben said...
Has anyone figured out how to get Pithhelmet to work yet? I've tried everything and I'm going insane. Ecspecially here at TUAW where it looks like they made the website in FrontPage 98 and 99% of the site is bulky disgusting ads.
Reply
11-05-2007 @ 9:47PM
Max said...
Pith Helmet has not been updated yet.
You could use SafariStand, and write a css to hide ads.
Reply
11-05-2007 @ 9:47PM
Max said...
Pith Helmet has not been updated yet.
You could use SafariStand, and write a css to hide ads.
Reply
11-05-2007 @ 9:58PM
Dan said...
That's not really so much a Support document as a Developer document. Support documents are meant for the general public. Developer documents are meant for developers.
There is a difference.
Reply
11-05-2007 @ 10:21PM
Andrew said...
The programs that used Input Managers are one of the coolest things that made me happy to switch to Mac OS from Windows. It seems like Apple could come up with a way to embrace these program plug-ins instead of forcing them out. I can't even begin to list all the plugin programs I use that would no longer be usable in a "future release". That could even mean 10.5.1!
Reply
11-05-2007 @ 10:26PM
Bob S. said...
You don't need any input managers. Install Privoxy and edit your hosts file to block ad servers. If your system thinks ar.atwola.com, pr.atwola.com, js.revsci.net, and pix01.revsci.net are hosted locally, TUAW has no way to put what they're serving in your browser window.
Reply
11-05-2007 @ 11:08PM
Rhywun said...
I was all ready to do without any plugins that use InputManagers until 1Password decided to stick with it in Leopard. I can't live without 1Password.
@6: I am a software developer and even I don't have the patience to work with Privoxy. There was a proxy in Windows I used to use that had a nice GUI*. Privoxy's web-based configuration is a bit shall-we-say unpolished, so I think it's not a solution that 95% of the public is going to want to deal with.
*Proxomitron; I just remembered the name.
Reply
11-05-2007 @ 11:11PM
Ari said...
I don't like the input manager mechanism, but I do like some of the add-ons it allows-- what we really need is a way to add plug-ins to Safari.
Some might consider plug-ins unnecessary, but apart from ad-blocking there are quite a few Safari input managers that I can't browse without.
The primary one is Greasekit, which enables a javascript that allows me to open up Google Reader items with the keyboard. Greasekit is actually a version of Firefox's Greasemonkey, and there are some great scripts for it-- I really like the one that lets you know if the local library has the item you're looking at on Amazon, or the one that opens all the New York Times articles in single page view.
Inquisitor is neat too. I could use Firefox, and it may come to it, but Safari is far nicer, save its lack of plug-ins. One could argue that Apple wants to keep Safari simple and shouldn't add plug-ins. If it wants to add them at all, it could allow them in webkit-derivatives. That's a defensible point, but I doubt at that point there would be enough of a market for any plug-in development.
Reply
11-05-2007 @ 11:36PM
Dan said...
Furthermore, no 64-bit support for InputManagers.
Reply
11-06-2007 @ 12:32AM
millenomi said...
Ahem, no.
PlugSuit completely replaces the InputManager vector with mach_inject, which Apple hasn't said anything about (as opposed to "InputManagers are going to die" in there). It loads InputManagers, but not that way.
This means it will survive InputManager removal and quite possibly a nuclear winter. :)
Reply
11-06-2007 @ 6:36AM
Chuck said...
Safariblock works. Not as good a PithHelmet, but much better than nothing.
Reply
11-06-2007 @ 8:55AM
WiLLGT09 said...
I wish Apple would also provide a reason as to why they are dropping InputManagers. Anyone have an idea?
Reply
11-06-2007 @ 10:45AM
Bob S. said...
I dunno, Rhywun; I installed Privoxy on my old G4 many years ago; when I upgraded to the Mac Pro a year and a half ago, everything transferred over just fine with the Migration Assistant, and I really haven't touched it since then. The two-step installation process (1. Install; 2. Change one line in System Preferences) truly is set-and-forget, even across machine upgrades.
And even if that's just too much hassle, like I say, keeping an up-to-date hosts file is very useful too. Whenever an ad makes it through to my screen, I view the source, find the ad's URL (sometimes embedded in a Javascript routine but still human-readable if you take a moment), and add the server to /etc/hosts.
Of course, as a web developer, the last thing you want to do is block content, even content like ads that 99% of the public doesn't want to see, and that's fair. But as web ads get more and more invasive, we can either block them or bend over and spread 'em.
Reply
11-06-2007 @ 12:25PM
J.B. said...
@12
The reason they are dropping/limiting support for input managers is that they have the potential to turn into a security nightmare since they allow arbitrary code to be injected into a user's otherwise "trusted" application. The restrictions outlined in that document are clearly security-oriented. Disabling user-installed input managers and only using the ones from /Library means that an input manager can't be installed without a user explicitly being prompted to authenticate. Disabling input managers from running inside an application that has root privileges means that the input manager can't hijack a privileged application and use it to make further changes to system files.
Just think of the possibilities if Apple hadn't put these restrictions in place. A user could be tricked into installing a malware trojan that quietly puts an input manager in place for a "trusted" (read: Apple-supplied) application, such as Safari. The user unwittingly runs the app, thinking that since it's from Apple that nothing bad can happen. Since the input manager allows injection of arbitrary code, the input manager could start sniffing out user's passwords on any web site it deemed interesting and silently sending them back to the mother ship. That's just one example. If the input manager were installed for some other application that executed root privileges, it could start making changes to the underlying operating system and install a rootkit that evades detection.
In short unrestricted input managers are a recipe for a Pre-SP2 Windows XP style disaster in the making. Apple users have taken security for granted for far to long, when they really shouldn't. I for one am pleased to see Apple taking steps in the right direction, even if it comes at the cost of some plug-ins that were never really officially supported in the first place.
Reply
11-06-2007 @ 6:25PM
Carlos Fonseca said...
Tip for the great mail.appetizer from http://www.versiontracker.com/dyn/moreinfo/macosx/22225:
A workaround was posted to the Mail.appetizer mailing list yesterday. I don't have the message here on my work computer, but I believe the following is the correct procedure:
1. Ensure that Mail.app is not running.
2. Launch Terminal and enter these two commands:
defaults write com.apple.mail EnableBundles 1
defaults write com.apple.mail BundleCompatibilityVersion 3
3. Move the Mail.appetizer bundle from the folder ~/Library/Mail/Bundles (Disabled) back to ~/Library/Mail/Bundles.
4. Launch Mail.app -- all should be well again.
Reply