An unfortunate description
Posted Mar 15, 2012 16:29 UTC (Thu) by rqosa
In reply to: An unfortunate description
Parent article: Idealism vs. pragmatism: Mozilla debates supporting H.264 video playback (ars technica)
> Whitelist is important but then you need to keep it up-to-date, which is not trivial.
Are you saying that it's more difficult for browser developers to keep a whitelist (of codecs and containers) up to date than to implement video/audio demuxing and decoding on their own?
I don't believe that. It seems like all that the Gecko developers would need to do is to make a whitelist containing entries for only VP8, Ogg, and Matroska (possibly allowing for users to edit the whitelist on their own installations, at their own risk), and leave it up to GStreamer to decide which particular implementation of those codecs and containers it will use. That way, all of the many other codecs and containers supported by GStreamer are excluded from the "attack surface" that the browser exposes to untrusted remote servers.
And by using a mature system-wide library for media playback (or anything else, basically), you will not only avoid missing out on useful capabilities that have already been implemented in that library (for example, I believe that Gecko still does not support GPU-accelerated video scaling, even though GStreamer has had it for a long time now, and Xine, MPlayer, and VLC have all had it for something like 10 years by now!), but you ultimately end up improving the library for all its other users. When app developers adopt the NIH attitude like Mozilla developers have done (or alternately, when they do use third-party libraries, but fork them and build the forked versions into the app, which is what Chromium/Chrome developers tend to do), it violates the engineering principle of modularity (a.k.a. "do one thing and do it well"), and ultimately causes a tragedy-of-the-commons where all app developers need to go to great effort to implement pieces of functionality that have already been implemented elsewhere (thus negating one of the major potential benefits of FLOSS).
to post comments)