A theory on why most browsers control their own list of CA roots
As part of the ipsCA failure, a number of people are noticing that most browsers keep their own list of CA roots, instead of deferring to whatever system-wide list your operating system keeps. There are at least three ways to explain this, depending on how cynical or optimistic you are.
The first is that it is the natural outcome of a ruthless but completely uneven Darwinian struggle for influence (and the benefits it brings) between SSL CA vendors, browser vendors, and OS vendors. Since browser vendors ultimately hold all of the cards in this, they won; how SSL works, including who controls what certificate authorities are trusted (and thus which of them get to make money and who goes bankrupt) is something that they dictate.
(Note that IE 8 is not an exception here; while it uses the Windows list of CA roots, it's written by the same people (well, the same company) as the OS, so the two are effectively the same. Safari and MacOS X is the same way. Chromium is an interesting exception, but Google probably was uninterested in stepping into the SSL snakepit.)
The second and more optimistic view is this has happened because it is the browser that is ultimately on the hook for who they trust. Regardless of who is really at fault, people will not say 'Windows trusted this evil site with a certificate from a bad CA vendor', people will say 'Firefox trusted this clown'. When you are being blamed for things that goes wrong, you have a natural motivation to control it so that you can do something about it.
(Or the shorter version: if you're going to get blamed for it anyways, it might as well actually be your fault.)
The third is that this is at least partly a relic of both the development history of these browsers and, for many of them, their cross-platform nature. Not all operating systems supported by browsers such as Firefox and Opera have any concept of an OS-level CA root list (especially back at the time of their early versions), and so those browsers necessarily have to have their own list on some platforms. Once you are going through the work to have your own list of trusted CAs on some platforms, you might as well do it on all of them (it's less code overall). As a bonus, you make your browser behave the same on all of the platforms that you support; imagine the fun of a bug report of the form 'Firefox accepts this https website on my Mac, but not on three out of five of my Windows machines'.
The department's model for providing computing support
In many university departments, there's a constant tension between working on the computing infrastructure that is used by the entire department, and working on things for individual professors and research groups. To put it more concretely, do you work on upgrading the departmental mailserver or do you set up Professor X's new cluster that just got dropped off at the loading dock?
(This tension is increased when Professor X's grant funding is helping pay for computing support, as it often is. Professor X may well feel that, well, she'd like some of what her money bought. Now.)
Locally, we (the Department of Computer Science) have evolved an interesting approach to deal with this problem that we call the 'Point of Contact' model. In this model, departmental computing support is split into two parts, Core and Points of Contact.
(There is a third and entirely separate group that supports undergraduate Computer Science students.)
The Core group is responsible for all of the common departmental infrastructure; we run the network, the firewalls, the general login servers and the fileservers, the general user webserver, the mailserver, and so on. It's funded from base budget funds, and does whatever the departmental computing committee thinks should be centrally provided.
By contrast, each Point of Contact works directly with specific research groups and researchers (and their grad students) to do, well, whatever those professors want them, whether this is setting up compute clusters, configuring Windows machines, or building custom programs for grad students. Points of Contact are paid for the grant funding of their professors and research groups and effectively work for them. While it's a departmental mandate that everyone has a Point of Contact (and helps pay for theirs), it's up to the research groups to decide things like how senior a person they need and how much time they can pay for and so on.
Points of Contact are called that partly because they are everyone's first level of contact for all computing support; the Core group is not supposed to deal directly with users. Instead, people go to their local person (most of the Points of Contact have office areas that are physically close to most of their professors and grad students), their Point of Contact does the initial troubleshooting and diagnosis, and only then is the distilled problem passed to the Core group if it turns out to be a problem involving Core stuff instead of a purely local issue.
(As you can imagine this works slightly better in theory than it does in practice, although it actually does mostly work in practice.)
From my perspective, I feel that this does two really useful things. First and obviously, it solves the 'what do we work on' problem; Core works on central things and Points of Contact work on whatever their professors want them to. As part of this, I think that it makes professors feel that they really do own and control what their grant money is buying; while they have to spend it, they get transparent and direct results for what they spend.
Second, it personalizes the computing environment as a whole. Computing and support doesn't come from some faceless or hard to remember revolving group of people that you deal with at a distance, mostly through email. Instead, it comes from a specific person that you know and that you deal with all of the time, frequently in person (and certainly it's expected that you can drop by their office and talk to them directly), and they're your agent (or at least your professor's agent) when something needs to get done beyond them. In a visceral way, they're your person.
Now, the necessary disclaimer: I had nothing to do with coming up with this model; it was developed before I came here. I'm just writing it up for WanderingThoughts because I think it's nifty (and a cool solution to the overall problem).