On Wed, 2008-11-19 at 09:28 +0100, Martin Stransky wrote: > Brennan Ashton wrote: > > 2008/11/18 Jesse Keating <jkeating@xxxxxxxxxx>: > >> On Tue, 2008-11-18 at 14:21 -0500, Neal Becker wrote: > >>> Should nspluginwrapper be banned from wrapping this? If so, should > >>> this be included in flash-plugin.spec? > >> Oh, I'm pretty sure you still want to keep flash separated from your > >> browser, regardless of the arch. > > > > Not according to the developer of the 64bit plugin. > > > > " > > Talking about nspluginwrapper: I strongly suggest not to use it. I > > know that some distros are thinking of even wrapping 64-bit plugins > > including Ubuntu with the thought that it will improve security and > > stability of the browser. This is a very bad idea in the state > > nspluginwrapper is in today. We have done some internal testing and > > discovered that several features in the Flash Player are broken when > > the plugin is wrapped. More importantly performance and user > > experience is pretty bad when the plugin is wrapped. Why? Lots of data > > needs to be transfered through IPC channels. I hope that browser > > vendors will eventually come up with a better architecture to wrap > > plugins without sacrificing performance, stability and functionality. > > " > > http://www.kaourantin.net/2008/11/64-bits.html > > > > > > I am not advocating one way or another, just wanted to get the voice > > out of one of the few who really knows what is going on behind the > > plugin. > > For instance, NPAPI plugins can share memory with browser and operate > with internal browser memory (like DOM tree) and this "feature" is > blocked by nspluginwrapper because of it's simple architecture. > > Full browser-side emulation will be extremely complex and is close to > chrome model where one process holds one browser page... > > ma. ... And the last thing you'll want (from both stability and privacy viewpoint) is to have a random plugin running code from some random website have access to your browser memory space. As for using multiple processes instead of multi-threading, I fully agree. (though I can't really comment about Chrome as I never tested it) - Gilboa -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
