look at each one to figure out which actually do work.

1. WebKit plugins. Theoretically they should only load when Safari encounters the
right web ContentType. But you can convince WebKit to auto-load your plugin[1]. This
will only work if Safari loads 64-bit plugins in-process, instead of using a sandbox
as it does for 32-bit plugins, anybody want to check this out for me?

2. OSAXen, aka Script Additions. This is what 1Password uses. You have to create an
OSAX that responds to a custom Apple Event, such as "inject SafariBlock". Then you
have a background app sit around watching NSWorkspace application-launch
notifications. When it is notified that Safari is launched, it sends the "inject
SafariBlock" event to it, which gets your OSAX code running inside the Safari process.

3. mach_inject. This would also need a wait-for-launch-then-inject mechanism. Also
needs certain special privileges, see taskgated(8). It looks like there's been some
Snow Leopard work in the mach_star github repos, so presumably either it already
works or will eventually.

4. DYLD_INSERT_LIBRARIES. This is what the WebKit nightlies do, and now the Chax
alphas too. You basically create a launcher for (application + your plugin), that
sets the DYLD_INSERT_LIBRARIES environment variable, then launches the app. Some
caveats: You can't really have multiple plugins this way, each needs its own
launcher. This technique may impact the dyld's shared library caching. Since you also
need the env var DYLD_FORCE_FLAT_NAMESPACE, an app which links to different libraries
with the same symbol will misbehave--but I wouldn't worry about this with Safari.

[1] See http://www.switchersblog.com/2007/08/the-end-of-th-2.html , and Google for
BP_CreatePluginMIMETypesPreferences

src: http://code.google.com/p/safariblock/issues/detail?id=115#c16