Actually, Flash has been sandboxed in Chrome for about a year, but it's not fully sandboxed. To explain, the Chrome sandbox architecture supports five levels on Windows. Chrome's web content and its native PDF reader run at USER_LOCKDOWN and JOB_LOCKDOWN (level 5), which means a deny-only token. Right now Chrome's Flash sandbox runs at USER_INTERACTIVE (level 2) plus low-integrity level (just a bit better than IE's sandbox). However, we've been working for almost two years on a version of Flash that runs in as strong a sandbox as native Chrome content. My post was explaining how to test an alpha release of that improved Flash sandbox.

It is the Chrome sandbox, but the architecture lets you select the degree of sandboxing. IIRC the Reader X sandboxed process runs at sandbox::USER_LIMITED, which means it can access resources as the Users and Everyone SIDs, and it runs on the interactive desktop. Whereas Chrome runs its sandbox at sandbox::USER_LOCKDOWN, which is a deny only token plus an isolated window station and desktop (along with some additional restrictions).

I don't want to undersell Adobe's accomplishment with Reader X, however. It's a good sandbox and a serious improvement over Windows Low IL on its own. But sandboxing is always a matter of degrees, and the more you can lock it down the better.

I don't see innuendo or unsubstantiated accusations as adding anything to the conversation. But I do think it's useful to address the technical portion of your claim.

I think you undermine the legitimacy of your question by trying to manufacture some evil ulterior motive here. The simple fact is that people often mistype URLs (or clip portions when pasting them), so it's helpful when the correct URL can be easily determined. And if you read through the privacy policy I linked above, you'll see that it very clearly describes what occurs in this scenario:

So, the submission of the URL is no different than if you'd stripped the parameters and pasted the URL into Google from an anonymous incognito window. If you're uncomfortable with that, then the same link provides instructions for disabling the feature.

Flash is not yet in the Chrome sandbox (except on Chrome OS), but there's a work in progress that you can experiment with on canary or dev channels.. On Windows, Chrome stable's Flash is in an enhanced Low IL sandbox, which is a bit tighter than the Internet Explorer sandbox, but much weaker than the full Chrome sandbox. (Basically, sandboxing an existing piece of software takes quite a bit of work to get right.)

You may personally have the expertise to make good security decisions about your browser. However, all empirical evidence shows that the vast majority of users are not capable of that, and are much better served by a browser that manages updates for them.

That said, you can disable automatic updates and perform them manually if you choose. However, I also consider myself capable of making those security decisions, and I still prefer the silent update dramatically over manually updating.

As an engineer on Chrome security this particular FUD really bothers me. The BSI takes privacy very seriously, and would never make such a recommendation if Chrome did anything like what you suggest. To the contrary, Chrome has an exceptionally responsive privacy team and a very clear and simple privacy policy. It identifies any feature that can exchange data with Google services, and provides clear instructions for opting out. More importantly, the vast majority of features that can exchange any such data are explicitly opt-in.

You can't implement ActiveX in another browser. You can instantiate an ActiveX control on Windows in any application you want, but that's an entirely different thing. To implement ActiveX on another platform you'd have to also implement all of Windows, because that's the platform and API that ActiveX is written to. So, the comparison isn't really valid.

They shouldn't unless they have a compelling reason. If NaCl proves itself viable and and develops a broad base of supporting apps, then other browser makers might certainly find that to be a compelling reason to add support--hopefully using the open source code and documentation already available.

The parts of Chrome that differ from Chromium don't have anything to do with NaCl. The extras in Chrome amount to branding, settings, and plugins that cannot be distributed under an open source license (ie. Flash, PDF).

I can appreciate your confusion, but comparing NaCl to ActiveX doesn't really make sense. Once you instantiate an ActiveX control it runs arbitrary code at your full user privilege. Whereas NaCl is much more accurately compared to the restricted execution environment of a virtual machine, such as Java, .NET CLR, or even JITed JavaScript. It's just that NaCl virtualizes a well-defined subset of an existing hardware instruction set, rather than one developed specifically for it. That virtualization (and the associated instruction validation) is the primary security mechanism, and is typical of a VM environment. The process sandbox is just a defense-in-depth measure (and a very strong one) layered underneath an existing VM sandbox.

However, there's no reason to take my word for it. If you research it a bit you should find that NaCl has a comparable or (in most cases) a more robust security model compared to the web-delivered execution environments most people are already running.