Comment by captainmuon | Hacker News Reader

Comment by captainmuon | Hacker News Reader

Parent Full thread

The wierd thing is that this has been supported for years. Firefox has a compile-time flag that allows it to use operating system codecs, it is just not activated in the official binaries. (I think it also uses a codec whitelist on some OSes, and you have to comment out a line.) On Windows, it used DirectShow codecs, on Linux GStreamer, and on OS X probably quicktime. It's great to be able to just point the browser to a file on the local net and be able to play everything the system can play (and even if it couldn't load the system codec, it could load a MPlayer plugin).

I used this for a while on Linux when there was a codec war between Firefox and Chrome (forgot the details), but I could play videos that normally only played in Chrome without problems.

Browser vendors cite usability problems (if one person's browser supports more codecs than the default, then it is confusing for other people with the default browser... and the person with more codecs might create websites that depend on this), and stability problems (plugins in any form have a bad reputation, but actually the default OS media player codecs are of pretty good quality as they are excercised thoroughly). But honestly, I think it is mostly politics that this is not enabled.

One big concern is security: code like this is notoriously prone to exploits and once shipped everyone is exposed whether or not they use it.

That doesn't mean new formats can't happen but it should encourage some careful assessment of the benefits relative to the need to support it for years.

(This is one of the stated reasons why Firefox never shipped JPEG 2000 support despite some demand)

Good point. Decoders for various formats are being reimplemented in Rust, which may make Mozilla less hesitant. There's still no guarantees, but it seems much less dangerous.

It will definitely help but it also increases the cost of adding support if that means porting an existing code base and having to maintain it. It'll be interesting to see whether projects start migrating wholesale so that's not just a Mozilla effort.

True, but there is no intrinsic reason why code from one vendor (Mozilla, Chrome group at Google) should be more or less secure that from the OS developer (e.g. MS, Apple).

In fact, for probably everybody except large browser vendors, you should never roll your own codecs (security, networking libs...) if it is not absolutely necessary.

I disagree with this idea in the specific domain of Web Browsers. If a vulnerability is discovered in a codec that ships with Firefox, Mozilla can have a patch out within 24 hours. They only have to test that codec against their own browser software.

Microsoft and Apple can technically roll out a similar patch within 24 hours, but will rarely do so except for major bugs, which have significant baby-punching abilities, as they have to test all of the rest of the operating system software against changes to system libraries. (Linux users get to update their libraries independently, so my argument doesn't really hold water there.)

Since my web browser is one of those bits of software that I regularly expect to load code that I will not vet, from developers whom I don't necessarily trust, I feel like I'd rather have it loading codecs that were designed with the web in mind. I don't think I trust it running my OS codecs, especially for more complicated formats.

This still doesn't mean I'd expect Mozilla to write their own codecs from scratch; certainly they should pull that codec in from an open source, well written and well supported library. But I think they're in a better position to respond to threats and patch domain-specific issues out of that library than my OS vendor is.

Codecs often aren't written by the OS vendor. Throughout the 2000s a lot of Windows users got their codecs via less than reputable codec multipacks from sites that may or may not be reputable. The VLC/MPC-HC/Web "just works out of the box" method is more user friendly and secure than a bunch of independent binaries, written by various people, which may end up conflicting with each other.

Much codec code was written years/decades ago with zero concern for security, so browsers have to have whitelists and private implementations.

Diverse code ownership is a security issue. Even if the OS code is just as "good" as the browser code (and there are reasons to believe that's not necessarily the case), the assumptions is makes are at least partially encoded as knowledge by the authors. When you're dealing with benign code, that's no problem - people work around OS/library bugs and/or (mis)features all the time - but if you're going to expose the code to potentially hostile third-party input, it's a little tricky. There's simply more opportunity for miscommunication when there are multiple parties involved and the spec is complex and may lend it self to native (unsafe) implementation for performance reasons.

Browsers are right to be hesitant, here. Frankly, they should be hesitant, and sandbox the plugin, and use something like rust, and even then I expect there will be exploits sometimes.

> there is no intrinsic reason why code from one vendor ... should be more or less secure that from the OS developer

If you're writing a cross-platform application, it's often easier to be confident in platform-agnostic parsing code that uses the platform sandboxing primitives, versus yielding parsing to the operating system, which may decode in a different execution context, and be less secure compared to the application security policy.

of course its politics. Google ships chrome with unoptimized h.264 software decoder causing 1080p60 h.264 YT clips to stutter on 4GHz intel while more cpu intensive vp9 is butter smooth, and same 1080p60 h.264 clips downloaded to disk play at 30% cpu in mplayer.

That's not just politics, it's also patents.

patents dont make people ship software compiled without optimization. Intel did same thing with its compiler to push cpus, Nvidia with physx compiled to use FPU instead of SSE/AVX and so on, its all politics.

Reply on news.ycombinator.com