Why not nspluginwrapper?
- nspluginwrapper is not a sandboxing mechanism
- An NPAPI plugin relies on unrestricted access to the underlying operating system, so a general plugin cannot be easily sandboxed. nspluginwrapper will only push the plug-in into a separate process; the child process itself is still fully priviledged.
- nspluginwrapper is not a generic out-of-process plugin
- While nspluginwrapper does push plugins out-of-process, modern browsers like Mozilla Firefox and Google Chrome natively support out-of-process plugins and, by doing so at the browser level, can do a better job.
It is not recommended to use nspluginwrapper for plugins which already run natively out-of-process in a modern browser. They should still work, but it only adds overhead.
nspluginwrapper is currently the only means to run a
plugin in a browser of a different architecture. It is
most commonly used to run a 32-bit plugin built
x86 in a 64-bit browser built
x86-64, but other combinations are
with QEMU. While there
is no reason browsers could not better solve this with
existing out-of-process plugin, they
is developed primarily with filling this use case in mind.
nspluginwrapper also makes a good tracing utility for NPAPI plugins.