As the Firefox Security Manager I completely and vehemently disagree. I employ a team that spends 100% of their time "going on bug-hunts" looking for security bugs in Firefox, and I know my counter-part at Google is doing the same for Chrome. Our Bug Bounty programs (VRP? ugh, so very corporate) are an incentive for people who stumble on neat stuff to pass it on, not a substitute for doing the work ourselves.
Mozilla isn't too keen on that, either: we're quite serious about wanting this to be a distributed system. Announcing Yahoo as an Identity Provider is an important step toward that. Another important step will be native navigator.id support in the browser so sites don't need to load the polyfill from persona.org.
"According to Mozilla, the B2G platform can run acceptably well in an environment with as little as 256MB of RAM." from http://arstechnica.com/gadgets/2012/07/mozillas-b2g-to-be-called-firefox-os-will-ship-in-2013/
No browser would accept a *.* certificate. According to the spec '*' can only appear in the leftmost label and can match only within that label. Long ago Netscape originally supported an expressive regexp syntax; modern browsers follow the RFC.
Mozilla is working on a short-term patch to TLS that will prevent the attack in the browser (see the bug), and in the longer term will implement TLS 1.2 (but if you don't prevent TLS downgrades you haven't fixed anything, and if you do you break all the version-intolerant servers out there).
No browser fix can prevent this attack from using a vulnerable plugin such as Java since Java is making these network requests on its own. Either the plugin vendor issues a fix, or you fix it by disabling the plugin.
If there were "better" ways that didn't require a plugin they would have demoed that. Maybe there are such ways, but not through simple <script> or <img> tags. In some ways I wish that is what they used: we could have fixed that ourselves rather than being at the mercy of plugin vendors.
The "pressure from advertisers" came after the feature was turned off because it didn't work right: https://bugzilla.mozilla.org/show_bug.cgi?id=570630#c15
We're also investigating a different approach of double-keying cookies with the primary and 3rd-party domains, which has the advantage of preventing advertisers from correlating your visits across sites within a session. This breaks even more legitimate things (as Opera also found when they experimented with this) so we're still brainstorming.
Actually, the reason Google knows that bit more about sites people visit, is that Firefox, Chrome and Safari all send each and every domain you visit to Google's Safebrowsing servers before they connect to it.
That is not how SafeBrowsing works. Firefox downloads a large database of hash prefixes. If the hashes of the domain and url are not in the list you go to the site and nothing is sent to Google. If the first bit of the hash matches an entry in the list Firefox asks Google for the list of complete hashes that start with that prefix. If the site's hash matches then you're blocked, if it doesn't you're not, but nothing more is sent.
To further obfuscate things, when Firefox finds a prefix match it doesn't just ask for the hashes matching that prefix, it also asks for the hashes matching a couple other random prefixes from the list.
Google may still know all the sites you visit through cookies on google-analytics or AdSense, but they're not getting that information from SafeBrowsing.