It's not $400 per bug. Many of the bugs were discovered by Google employees, who don't get rewards. That pushes the average down. However, it also makes Google possibly the only company that appears to report all vulnerabilities they internally discover. MS doesn't report any internally discovered vulnerabilities, and even Mozilla will lump numerous internal discoveries under a single bug ID and CVE.

FWIW, they thanked members of the Chrome team a few months ago when they announced sandboxing support in an upcoming version of Acrobat Reader.

You forgot the part where the hypothetical researcher has privately reported numerous critical vulnerabilities to the hypothetical company and waited months or years for fixes. You also missed the researcher providing two different fixes for this particular vulnerability in his disclosure announcement. But hey, why make a fair comparison when you can resort to sensationalist slander?

That should be the first thing anyone familiar with Windows architecture notices. It means that it's an escalation from an account that's already running at elevated privilege (at least, it is on Vista and beyond).

So, it's definitely a security bug. But it seems like a disproportionate amount of noise for a local privilege escalation requiring higher than normal privilege to start with.

You have this backwards. I can point to every major browser, along with research directly addressing the topic. Whereas you haven't provided one iota of evidence to back up your misguided and ignorant statements.

Since it's obvious you have nothing of value to contribute, I'm just going to close this out with a suggestion. When confronted with a topic you obviously know nothing about, please resist the temptation to make noise just so people will notice you. It just wastes everyone's time and prevents you from actually learning anything.

You're conflating a few different things. There's origin security and there's local client security. Origin security is what protects you from one site accessing browser data from another site. Any discussion of extension permissions would apply primarily to origin security, because once you install anything with local client access you've already lost control. And when considering origin security, separate profiles within the same OS-level user account provide one method of strict enforcement.

Now, if your concern is client level security against exploits (not malicious extensions or plugins), then you're far better off relying on the Chrome sandbox over a separate user account. The sandbox provides vastly lower privilege and much smaller attack surface than a normal user token, and OS-level privilege escalation vulnerabilities are far more common than sandbox bypasses. You can certainly use your approach in conjunction with the --no-sandbox option in Chrome, which should allow Chrome to work with runas. However, you'd be downgrading your security with that approach.

The important thing to consider, however, is that no user should be expected to invest their own effort in a multiple profile solution. So, until someone creates something like the Chrome sandbox but with per-process origin isolation, there won't really be a general purpose solution providing a superior form of origin based security.

Not only have I read the paper, I've worked with a few of the authors on this subject matter. And that's why I know that it's essentially impossible to provide a useful extension API that is not also vulnerable to intentional abuse. Claiming the opposite is akin to claiming you've refuted Gödel's first incompleteness theorem. And if you've succeeded at either, I'd like to see the evidence. (Just a heads-up, you're starting to line up a pretty tall list of things you'll need to accomplish to support your arguments here.)

There isn't anything like "reads password data," nor could there be without drastic changes to the DOM standard and how JavaScript is implemented in modern browsers. The way the system works is that the installation manifest states what origins a content script will run in. And any script executing within an origin has access to all that origin's data. This is conveyed to the user with a message like "this extension can access data from site X.com" or "this extension can access data from all sites."

If you have a proposal for something better, then please share it. But the Chrome extension security model was well researched. And it was apparently considered good enough that Apple and Mozilla are creating similar models with Safari and JetPack.

I think you may have intended to reply to someone else. I was simply answering a question on NoScript's capabilities.

Also I'm quite familiar with running multiple profiles; my job would actually be impossible without it. In Chrome you simply pass the --user-data-dir switch. I don't see how that's any worse than running Firefox with the -P and -no-remote switches (or the old way requiring env vars). I am curious how you run IE under a separate profile without using a different Windows accounts. I didn't think that was possible, and instead use runas to get an alternate profile in IE.

It's just sad that you find it perfectly acceptable to comment like this on an application you obviously know absolutely nothing about. Chrome actually does run extensions in a sandbox. It also warns on installation of an extension, and explains what permissions that extension requires. If an extensions attempts something require a privilege that wasn't in its installation manifest the operation fails. As I said in another comment, the UI has issues and could certainly be improved, but the fact is that Chrome currently does everything you just implied it fails at.

Chrome already lists the permissions an extension requests at installation. The UI on that interaction is junk, so you need to be a fairly knowledgeable user to make heads or tails of it, but the information is definitely there.

NoScript does nothing whatsoever to restrict extensions or plugins. Nor would it even possible for it to do so without a major redesign of Firefox's extension system including the introduction of a security model with trust levels.

There's nothing wrong with installing a program in the Application directory; it's pretty much the norm on Windows for per-user installations. Think of it as equivalent to ~/bin on Unix systems. Of course that doesn't fit in well for enterprise environments, but Google does provide a pack installer for managed systems, which installs under "Program Files" and lets you disable auto-updates. And while the current version of Chrome is lacking other enterprise features, the next version will have full support for GPO configuration, Admin templates, and all the other things you'd expect in an enterprise.

As for your absurd claim that per-user installations are somehow a security vulnerability, you're going to have to provide something to back that up. Because I've spent about 15 years in the information security field I can't even get close to a rationale for that one.

Actually, Tavis specifically suggested disabling the hcp: protocol handler. His statement on the hotfix was:

In the unlikely event that you heavily rely on the use of hcp://, I have
created an unofficial (temporary) hotfix. You may use it under the terms of
the GNU General Public License, version 2 or later. Of course, you should only
use it as a last resort, carefully test the patch and make sure you understand
what it does (full source code is included). It may be necessary to modify it
to fit your needs.

MS are the ones focusing on the hotfix and claiming it's flawed without providing an explanation. MS are also the ones desperately trying to frame this as Google, when it was Tavis operating independently on his own time.

I'm not saying I agree with what Tavis did, but MS' shady response certainly isn't making me less inclined to side with Tavis.

Actually, he recommended against using the hotfix, and instead suggested disabling the protocol handler. Speaking of, is anyone aware of the hcp: protocol being used for anything other than security exploits? Because in its 10 years of existence I've never once seen it used legitimately, but I've repeatedly seen it expose security vulnerabilities.