[chriswarbo]

I think a more pertinent question would be: why have the browser decoding images at all, rather than loading a dedicated library?

The points mentioned in the article about streaming data and untrustworthy images make sense, but would be useful even outside the context of a browser rendering engine (e.g. many local image files will have come from the Web, so are just as untrustworthy).

[rwmj]

I remember when Mosaic used to launch an external program like 'xv' to display images. However in answer to your question, it's not clear that having a library would add any security, since libraries run in the same context as the rest of the browser (especially on Firefox where the default is still to have everything running in a single process). You could have an external program to do rendering, but embedding the output of external programs into the rest of the output is very inflexible, hard to do, and (with the design of X) not actually any more secure.

[epidemian]

> it's not clear that having a library would add any security

I don't think that's the main benefit of using/developing an external library for this. To me, using an external library sounds like a good idea because:

- You get code separation. A bit less code on the main Firefox repo, and a repo dedicated only to BMP decoding (or image files in general). Someone who wants to contribute to the BMP decoder wouldn't need to download all FF repo and understand/configure its build system. Big plus!

- The library can be shared among different applications. It doesn't make sense for each browser to have a different implementation of BMP decoding, each with their own bugs. Sharing a library for this kind of stuff would actually benefit security, as a bug fixed by one browser/app developer would benefit the others.

That last one is the biggest thing for me. The BMP example is a very simple one, and not very important. It is in more complex tasks that i think sharing libraries would be much more beneficial.

For example, wouldn't it be great that, instead duplicating so much effort in implementing the streaming capabilities of Media Source Extensions [1], the different browsers shared a library dedicated to that complex task? We could have had a more complete and robust implementation in less total time! And that's just one example; there are tons of complex things browsers do that could be extracted to separate shared libraries.

[1]: And so many bugs https://bugzilla.mozilla.org/show_bug.cgi?id=778617

[pdkl95]

> code separation

This is incredibly important for security. Reducing complexity and possible attack surface even between components is something that has been ignored in software for far too long.

Crypto shouldn't ever be in the same address space of any process that also does parsing or network I/O. That's just asking for the keys to be leaked (or other problems) when the inevitable bug is found.

[pcwalton]

I completely agree with this reasoning, and those are pretty much the reasons why Servo's developed in such a modular way (in contrast to most other browser engines).

[bzbarsky]

The obvious answer is that the library may not do what you want. Some examples of what browsers want to do with images in different circumstances:

1) Just determine some metadata about the image (size and a few other things) but don't decode the pixel data yet.

2) Asynchronously decode the pixel data on a separate thread, notify when done.

3) Synchronously decode the pixel data on the current thread.

4) Asynchronously decode the pixel data on a separate thread, notify as you go. This can have variants along the lines of "Progressive JPEG" as opposed to just delivering more scanlines.

Now ideally a good library would in fact let you do all of this as needed (e.g. Firefox just uses libpng for PNG decoding, though even there it's patched locally to add APNG support). Not all image formats have good libraries.

[rmc]

Because (a) the browser can't guarantee to support image formats, since it depends on what's available locally and (b) a flaw in an image decoder on one OS is essentially unfixable by the browser creator. Today they can roll out a new version which patches that flaw.

[ape4]

Might be nice if this code was packaged up as a library.

[amelius]

> why have the browser decoding images at all, rather than loading a dedicated library?

Because a dedicated library could change its API in version 2.0, and at the same time fix important security flaws. At that point your only options are: switch to a different library, write your own library, put the old API back in the original library, or ask the maintainers of the library. All of those options are difficult or unreliable, especially given the small timeframe in which it all should happen.

[chriswarbo]

> Because a dedicated library could change its API in version 2.0, and at the same time fix important security flaws.

The correct thing to do is back-port fixes to the 1.x branch, or come up with an alternative fix if the 1.x/2.x transition changes too much (in the latter case, the 1.x and 2.x versions would essentially be different libraries which just-so-happen to share the same name). Anyone can (attempt to) do this patch, including the library authors, the browser authors (who may be the same people), or any other users of the library.

If upstream don't accept such patches, and repeatedly indulge in such uncooperative behaviour, there is always the option to fork (and, in the process, perhaps strip out the parts which the browser doesn't need to make maintenance easier).

As an aside, the situation you describe sounds a lot like the Firefox/Iceweasel drama in Debian!

[leni536]

> Firefox/Iceweasel drama Was it a drama though? AFAIK it was pretty much drama free. Debian wanted to backport security fixes themselves but it wouldn't have complied with Firefox's trademark policy. So they just changed the name/icon and didn't make a big deal out of it.

[pixl97]

The end user doesn't care about the correct thing, they just want their web browser to work and to not break any other applications in their operating system. Working and not breaking other stuff is 'the correct thing', being secure is also 'the correct thing' so the culmination of these two leads to 'the browser contains all the libraries it needs'. This whole forking crap is exactly the last thing the end user wants or needs to care about.

[chriswarbo]

> The end user doesn't care about the correct thing

I think both of our definitions of "correct" coincide.

The reason to use libraries is precisely so that the applications will work, not break each other, be secure, etc.

The article talks about different browsers supporting different sub-sets of possible BMPs; from a user perspective, I wouldn't call that working.

> the culmination of these two leads to 'the browser contains all the libraries it needs'

This doesn't conflict with what I said. Write as many libraries as you like. Grab as many third-party ones as you want. Use OS-provided ones if you prefer that. Bundle them with your browser, I don't care. Statically link the binaries if it makes things easier. Keep copies of the libraries in your browser's source control if you think that's best. I wasn't addressing any of that.

My point was to use libraries; regardless of who writes them, how they're distributed, how they're linked, etc.

> This whole forking crap is exactly the last thing the end user wants or needs to care about.

Erm, exactly? Nobody likes to fork a project. It's a last resort for bad situations. End users certainly do care when devs steer a project off course; hell, just look at the outcry that happens whenever some social media site changes its colour scheme a little!

[i229718]

Less dependencies usually means less bloat.

[digi_owl]

Firefox is still offered as a "portable" archive download.

Meaning you can download said archive, extract it onto some storage media, and run it from there on a compatible platform.