Chrome was the first browser to do this, and has been blocking out-of-date and commonly exploited plugins (like Java) since 2010.
Here's every "security" report he's made against Chrome. None were valid.
netflix and amazon are subscription services, not individual movie downloads. itunes is an awesome service, but it's expensive - $5 per movie. So the only conclusion is freetards.
Amazon, Youtube, iTunes and others all let you legally rent or buy digital copies of newly released movies. The prices and quality are competitive or better than DVD rentals, but the convenience factor of digital is the huge differentiator.
Sorry, the antecedent in my response was a bit misleading. What I was correcting was the claim that the PDF reader wasn't a plugin. It's in fact a plugin that ships with the browser (like the Flash plugin does). Third party plugins have always been a difference between Chromium and Chrome, because there's no license to distribute the binaries outside of the official Chrome builds.
That's incorrect. There's never been a PDF reader built into Chromium. The Chrome PDF reader (added in Chrome 8) has always been licensed third-party code in a plugin that ships with Chrome. It's fully sandboxed using PPAPI and has been aggressively audited and fuzzed (this latest round of fuzzing just used a more advanced toolset, so it found new things).
Google uses Chrome to track user's browsing habits for the purpose of targeted advertising.
This is simply not true and never has been. If you are interested in the facts, the Chrome Privacy Team thoroughly explains every feature that can be configured to exchange information with external services: http://www.google.com/chrome/intl/en/privacy.html
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.
No, the sandbox in adobe reader X is the chrome one.
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.
If I hit a 404, Chrome phones home with the URI I was trying to reach. And what do you do with that data, I wonder?
In order to offer suggestions of alternative or similar webpages, the browser sends Google the URL of the page you're trying to reach whenever the web address does not resolve or a connection cannot be made. Information is logged and anonymized in the same manner as Google web searches. Any parameters in the URL are removed before the URL is sent. The logs are used to ensure and improve the quality of the feature.
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.
That still doesn't change anything. Microsoft lets other browsers implement ActiveX too if they want to. But they don't.
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.
Why would other browsers suddenly start supporting everything Google does, especially non-standard stuff?
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,
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.