another way of looking at it ... is that in some cases, the browser vendors have charged CAs quite a bit of money to get their (self-signed) certificate included in the browser.

These aren't x.509 identity digital certificates in the traditional sense ... these tend to be self-signed digital certificates ... which turn out to be a convenient packaging technique for public keys that are to be included in a trusted repository (of public keys) ... aka rather than these digital certificates being a trust mechanism ... these kinds of digital certificates are purely public key packaging mechanism ... and the act of including the public key in the (browser's) trusted repository of public keys is the trust mechanism.

Now the certification authorities (CA), who have typically paid money to have their public key included in the browser's repository of trusted public keys, ... can turn around and charge their clients money for digitally signed (trust) digital certificates (verifiable by one of the public keys included in a browser's repository of trusted public keys).

So the ability to remove a (certification authorities) public key from a browser's repository of trusted public keys ... might also be interpreted as impacting a whole economic ecosystem (since the CA's clients stop receiving benefit from having the certificates, they paid for, being accepting ... which in turn impacts the economic operation of the CA that had paid money to have their public key included in the browser's trusted public key repository).

Having the browser vendor automatically reload public keys into the browser's repository of public keys ... might be construed as the browser vendor actually maintaining the master copy of trusted public keys (which they probably have charged quite a bit of money to include a public key) ... and any specific browser's copy is purely a "local" cache. While it might superficially appear that a browser's local copy of trusted public keys is purely autonomous ... protocols implemented by the browser software could actually manage cache consistency with the vendor's master copy. In theory, not only could a cache consistency algorithm reload trusted public keys that have been deleted from the local cache ... but might also load new public keys that had never been in a local cache. Such an hypothetical cache consistency implementation could also do away with any certificate revocation kludge for certification authority public keys (we've made past claims that our repeated criticism of certificate revocation operation led to the OCSP effort).

In any case, the whole public key reload effort might possibly be a browser vendor, certification authority, CA-client economic ecosystem ... having little or nothing to do directly with PKI relying parties.

This is orthogonal to the traditional trusted 3rd party certification authority having no real business foundation ... aka the relying party typically doesn't have any sort of contractual relationship or other mechanism on which to base liability and/or recourse with regard to anything done by the certification authority.

This is somewhat highlighted by the federal PKI operation where the GSA (as agent for federal gov. relying parties) has contracts with the various approved certification authorities (creating a basis for legal reliance between the relying parties and the certifying operations). These "contracts" bridge the legal and contractual gap with regard to reliance that occurs in many of the deployed PKI operations

misc. past posts mentioning the contractual work around in the federal PKI to the typical trusted 3rd party kludge:
http://www.garlic.com/~lynn/aadsm12.htm#29 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm16.htm#16 Ousourced Trust (was Re: Difference between TCPA-Hardware and a smart card and something else before
http://www.garlic.com/~lynn/aadsm17.htm#9 Setting X.509 Policy Data in IE, IIS, Outlook
http://www.garlic.com/~lynn/aadsm18.htm#7 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
http://www.garlic.com/~lynn/aadsm26.htm#1 Extended Validation - setting the minimum liability, the CA trap, the market in browser governance
http://www.garlic.com/~lynn/2003l.html#45 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005f.html#62 single-signon with X.509 certificates
http://www.garlic.com/~lynn/2005i.html#12 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005i.html#21 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#1 Creating certs for others (without their private keys)
http://www.garlic.com/~lynn/2007l.html#2 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#6 John W. Backus, 82, Fortran developer, dies

Mozilla doesn't charge CAs for inclusion in Firefox.

- A

Neither does Microsoft; at least directly. What they do is demand annual audits from CAs whose root certificate include in IE. However, I agree that this practice of reinstalling deleted certificates was most probably decided _in part_ on the basis of avoiding economic conflicts.

Is this more evidence of CA-like behaviour?