5 ms·

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.

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.

nitrogen 10y ago
Much codec code was written years/decades ago with zero concern for security, so browsers have to have whitelists and private implementations.
zeta0134 10y ago
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.
Klinky 10y ago
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.
twr 10y ago
> 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.
emn13 10y ago
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.

nitrogen 10y ago

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

zeta0134 10y ago

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.

Klinky 10y ago

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.

twr 10y ago

> 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.

emn13 10y ago

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.