Uhm, there is a open plugin way ... Safari supports the old netscape plugin api afaik, but it's painful to work with and not very well documented. I stumbled on some of the docs and I think one example on the developer.apple.com pages somewhere.

Reply

If I lose the use of Inquisitor, I might riot.

Reply

Mayo, he's not talking about browser plugins as in media plugins like QuickTime, etc. What's being talked about are browser add-ons that are more like Firefox extensions: third party software that adds new features. I use a number of add-ons with Camino.

Reply

The only reason I use safari is because I have, Saft, Pithhelmet, SafariStand, Safariplus

All these things combine to make Safari awesome for me.

Reply

I've gone back to Firefox for compatibility with sites like Blogger, extra features in Gmail, etc. (two minor examples). However, if I can't use Saft in Safari, and Apple doesn't build in basic ad-blocking at the very least, then I'll probably be using Firefox for a good while longer. This isn't MyFirstComputer. Apple wants a clean and safe environment. Fine. But completely preventing third party participation is plain arrogant. Safari isn't finished yet (or is it?). I guess we'll see.

Reply

oh come on. have any one of you actually ever seen how it's made now with input managers in Leopard?

Reply

shoot, comments don't support HTML with img src tag. check this out, the actual screenshot from the recent build of Leopard.
http://img227.imageshack.us/img227/7002/sssmr7.jpg

they are not axed, but now you can disable it.

Reply

We make two Inputs Managers for Mac OS X. CutX Content Filter and RapidoWrite and we hope to see Apple keeping this feature.

Reply

I've always thought of input managers as kind of dangerous. They've strayed far from their original purpose - providing alternative means of text input- and they've become a significant potential vector for malware. Indeed, while there haven't been any reports of in-the-wild infections, the two proof-of-concept Mac OS X trojans I've heard of use input managers. I, for one, think it's about time they're gone. However, an official plug-in architecture for apps like Safari would be a nice replacement.

Reply

No Saft, bye bye Safari, hello Camino (or Firefox, Omniweb, anything else).

Reply

Alexmak, where did you find that screenshot? The grammar and formatting were atrocious. It's hard to believe Apple would put out a product with a message like that, even in a beta.

Reply

Simon Arch, no kidding. What is a functionality? Why would a user care about Cocoa or not?

Also, http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSInputManager_Class/Reference/Reference.html

Reply

I don't understand why people use a separate ad-blocking plugin for every browser when the awesome Privoxy (http://www.privoxy.org) does so much more and will work in every browser.

Reply

Anon, the Privoxy url you give points to an ad site; to download Privoxy (of which I'm an extremely happy user) go to http://sourceforge.net/projects/ijbswa ...
Privoxy has this excellent feature that you can use it with any app browsing, for instance I am working now from my RSS reader's html viewer, with ads filtered even though the developer never thougt of it...
Hervé

Reply

"There's a disturbing rumor floating around the Mac web today."

Oh, yes, it's disturbing, indeed, to hear that a security hole in the OS is likely to be closed.

Good grief.

Reply

Security hole? Can an Input Manager even be installed without the operating system warning the user?

Reply

System-wide input managers require a warning, but they can be installed for individual users with just user privileges. It wouldn't be too hard to have a warning for that too though...
Personally, I'm a little bummed to see spellchecker and textpander, two apps I rely on a lot, may not be possible in Leopard...

Reply

I would welcome it, if Apple kicks input managers out of OS X. I already "disabled" inputer managers and if an app wants to install a input manager, I will avoid it.
The idea behind Input Managers was ok, but the have been used in the wrong way.

Reply

Input Managers are effectively a drag-and-drop means of something that's only marginally more difficult to do another way (and even then it's trivial, especially if you're in the game of producing malware). Mac OS X's dynamic linker, just like most Unix/Unix-like operating systems, has the facility to preload or insert additional dynamic libraries. On Darwin and friends, it's the DYLD_INSERT_LIBRARIES environment variable (which of course applies to everything, not just Cocoa apps); on Linux and Solaris (and possibly the BSDs), it's LD_PRELOAD. Granted, there's no specific hook callback mechanism, but most of the really useful Input Managers seem to use the system as a means of shoehorning themselves into the application's memory space, which is all DYLD_INSERT_LIBRARIES does for you.

I don't know (because I've not tested it yet) whether DYLD_INSERT_LIBRARIES can be set via environment.plist: Apple would have had to specifically prevented it if it can't. If it can, there's your install vector right there; instead of copying a file in place, you have to copy a file in place and update a property list. Given most Input Manager hacks come with installers already, there's not a huge difference from an end-user perspective (and it's not noticeably more difficult for a malware author).

Reply

About time that this hack to Input Manager is being sealed.

I'm sorry if this hurts a few of you, but the fact that coders do this against EVERYTHING Apple tells them is for this programmer unacceptable. All such security issues should be terminated, period.

Keep it coming, Apple!!!

Reply