Son of Input Manager

It's not as dangerous as the original but it's still not something you want.

Get It Try It

A while back another 'Safari plugin' appeared. Again. It's a makeover of an earlier 'plugin' called 'SafariPlus'. What it wants to do is give you the ability to better control your Safari cookies. It lets you construct 'white lists' of cookies you never want gone and 'white lists' of web sites you're willing to keep cookies for.

For some this can seem rather useful. For others the simply mechanical action of removing all cookies (in Safari) after a session or setting all cookies to immediately be destroyed after a session (in Firefox) seems the better alternative.

But there's an endemic difference between how 'plugins' on Safari and Firefox work.

Firefox has a true plugin architecture - one of the reasons Firefox is so popular, enjoying a 1/3 market share in Europe and a 1/5 market share in the US: the platform independent browser created a veritable greenhouse of third party activity so that the number of good useful plugins today is almost beyond easy count.

Firefox plugins interact only with Firefox and at the sole behest of and under complete control of Firefox. The code in these plugins can't possible interact with any other applications. It's 'sandboxed' to Firefox and can go nowhere else.

Safari 'plugins' aren't plugins at all - they use the abhorred 'input managers' architecture which means their code affects all running applications. Not exactly a comforting thought.

Inq.Tana, Oompa Loompa, Leopard

The input managers facility goes a long way back on Mac OS X. Word has it that it came about in the NeXT era to help accommodate Japanese character input. The design was extremely unfortunate.

Anything placed in a number of 'input managers' locations would automatically and without client control run in the address space of every Cocoa application. It was up to the discretion (and the benevolence) of the 'input manager' to not interfere with applications for which it had nothing to contribute. It was up to the proficiency of the input manager programmer to make sure it didn't make client applications crash and burn as a result of its interference.

Several people have suggested an alternative input manager architecture where the input manager of its own volition refrains from injecting code in any application for which it's not been written. But this still doesn't eliminate the danger - for control is still in the hands of the input manager and not with the client application where it belongs.

Noted security guru Kevin Finisterre began a campaign several years back to encourage Apple to do something about this gaffe, releasing a succession of 'proof of concept' applications which exposed the dangers of the input managers idea.

Coincidentally with the release of his first POC (called Inq.Tana) another critter popped up on the horizon and caused quite the stir: the feared Oompa Loompa. Several security cottage industry companies of course crafted a typically 'officious' name for it: they called it Leap-A.

Oompa Loompa was a flawed but brilliant concept that in one fell swoop exposed an impressive gamut of Mac OS X design flaws - and especially the input managers design flaw. Would Inq.Tana and Oompa Loompa combined force Apple to wake up?

Yes they would - to a certain extent. Current 'Leopard' architecture doesn't allow input managers to be placed willy-nilly in a system: they may only be placed in /Library/Input Managers. Furthermore: they must be locked down by root. The files and the directories must all be owned and protected by the root account - otherwise Mac OS X will refuse to run them.

The reasoning is good: it's going to take authentication for privilege escalation to install them and get them to run; the user must ordinarily be a member of the admin group; therefore nothing should be happening without the express knowledge and permission of the user.

So far so good.

Safari Cookies

Safari Cookies is a reworking of (and using code from) Safari AdBlock and SafariPlus. Both the latter used the only available method to create a Safari plugin: input managers. At least one of these applications failed on the upgrade to Leopard (and the author seemed at that point to have lost interest). A certain 'Mr Qwirk', erstwhile known as a street pantomime artist, decided to take this open source code and make a cookie manager that works on Leopard.

The download for Safari Cookies was not available earlier this week purportedly because 'Mr Qwirk' detected a malicious bug in the code and needed time to fix it. The program is available again.

Installing Safari Cookies requires root escalation.

The following is performed immediately after all files are copied to the target system.

#!/bin/sh
chown -R root:admin /Library/InputManagers
chmod -R go-w /Library/InputManagers

Uninstalling Safari Cookies also requires root escalation.

The following is performed to uninstall Safari Cookies.

#!/bin/sh

echo "Uninstalling Safari Cookies..."
rm -rf "/Library/InputManagers/Safari Cookies"
rm -f "$HOME/Library/Logs/SafariCookies.log"
defaults delete com.apple.Safari SCremoveNonFavoritesWhenQuitting
defaults delete com.apple.Safari SCPreferencesAcceptCookieDomainsKey
defaults delete com.apple.Safari SCenableLogging
defaults delete com.apple.Safari SCcookieAcceptPolicy
defaults delete com.apple.Safari SCacceptCookieDomains

Given that everything was protected by root in the first script it follows that Safari Cookies is either itself running as root or is obtaining a 'privilege' from the system authorisation services to later remove it.

Bottom Line

You might or might not need a Safari cookie manager (when Firefox already has an adequate one). You might or might not feel OK knowing Safari plugins aren't real plugins at all but use a technique identical to the destructive Oompa Loompa to give you greater cookie control (and hopefully nothing more). You might or might not feel OK using a Safari 'plugin' from a street pantomime artist. Certainly other users can tell you if they got burnt or not.

But input mangers have never been and will never be a good idea. The word on the street is they'll be totally verboten in Mac OS X 10.6 Snow Leopard - and that would be a Good Thing™.

The question remains: what are people to do to enhance the performance of Safari when Safari ostensibly does not offer a plugin architecture like Firefox? Firefox has benefited immeasurably from its plugin architecture; what are the managers at Apple afraid of anyway?