On Tue, Nov 18, 2008 at 15:55:02 -0800,
Brennan Ashton <bashton@brennanashton.com> wrote:
> 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.

How about getting the people in charge of deciding what format to publish
content in, to not use crappy, security hole ridden, propietary formats.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Dennis J. wrote:
But that's the point. For quite a few people browser stability actually
*decreases* when nspluginwrapper is installed.


Please file bugzilla bug when you find a page where browser crashes
because of nspluginwrapper. I'll happily debug it.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Brennan Ashton wrote:

2008/11/18 Jesse Keating <jkeating@redhat.com>:

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.


--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Bruno Wolff III <bruno@wolff.to> writes:

> How about getting the people in charge of deciding what format to publish
> content in, to not use crappy, security hole ridden, propietary formats.

The main competitors are Java and Silverlight. Neither seems
particularly appealing.

Some things you can replace with either plain embedded video or AJAX,
but not everything.


/Benny

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Martin Stransky wrote:
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.

From both a security and privacy point of view you actually want to
sandbox plugins. Many of the security fixes to IE over the past 3 years
(which weren't pure bug fixes) was to limit what you can do from
javascript. The last thing that you want to do is to give a scripting
engine unbridled access to the DOM tree and the browser's internal
memory. The chrome model does not solve this problem.




--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Martin Stransky wrote:

> Dennis J. wrote:
>> But that's the point. For quite a few people browser stability actually
>> *decreases* when nspluginwrapper is installed.
>
> Please file bugzilla bug when you find a page where browser crashes
> because of nspluginwrapper. I'll happily debug it.
>

Here's a bit of nspluginwrapper strangeness. In /usr/lib/mozilla/plugins-wrapped I have:

nswrapper_32_32.libflashplayer.so (file, not a link)

Even though I have removed libflashplayer.so 32-bit. There is no flash in /usr/lib/mozilla/plugins.

I have re-rerun mozilla-plugin-config -c -v. It doesn't even mention the above file. There is nothing in /etc/sysconfig/nspluginwrapper telling it to ignore this. I thought after uninstalling flash 32bit and re-running mozilla-plugin-config it would clean up the old wrapper.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, Nov 19, 2008 at 09:37:56 +0100,
Benny Amorsen <benny+usenet@amorsen.dk> wrote:
> Bruno Wolff III <bruno@wolff.to> writes:
>
> > How about getting the people in charge of deciding what format to publish
> > content in, to not use crappy, security hole ridden, propietary formats.
>
> The main competitors are Java and Silverlight. Neither seems
> particularly appealing.
>
> Some things you can replace with either plain embedded video or AJAX,
> but not everything.

For normal web browsing, you shouldn't need to use Java, Silverlight or
Javascript. All of those are too powerful to let random web sites execute
on your local machine.

It's different if a trusted server is using your browser as an app platform.
I am not a great fan of that either because there aren't great tools in
Firefox to separate sites into ones that are providing trusted apps as
opposed to everyone else. (Noscript comes close, but seems a bit fragile
to me.) This can be an inexpensive way to provide apps that run on a lot
of platforms, so I see why people do it.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On 2008-11-18, 19:21 GMT, Neal Becker wrote:
> Should nspluginwrapper be banned from wrapping this? If so,
> should this be included in flash-plugin.spec?

NO! We want to keep flash-plugin separate from the firefox
process, moreover we confine nspluginwrapper (and thus
flash-plugin as well) with SELinux in Fedora >=9, so we need to
have nspluginwrapper around.

Matěj

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On 2008-11-19, 08:28 GMT, Martin Stransky wrote:
> Full browser-side emulation will be extremely complex and is
> close to chrome model where one process holds one browser
> page...

OK, I may be wrong then.

Matěj

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

On Wed, 2008-11-19 at 09:28 +0100, Martin Stransky wrote:
> Brennan Ashton wrote:
> > 2008/11/18 Jesse Keating <jkeating@redhat.com>:
> >> 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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list