Slashdot Mirror

Chrome may be controlled by Google, but it is built on Chromium, which is at least open source: http://www.chromium.org/ FireFox stopped being the best browser for a whole lot of folks before this whole version number nonsense started. I had switched to Chrome before then, but when I checked out 4.0, I was shocked at how much slower it was than Chrome.

I am no fan of giving corporations singular control over things, but I'm not going to let that prevent me from using a product that is superior for my needs compared to the competition. I do hope FireFox returns to being a lean, fast browser that can retain a lot of market share. I prefer to see a variety of "platforms" pushing forward, as that will ensure standards take hold of the web, and that we never end up with another situation with IE6.

Your last statement, that "Google's offering is preventing it [Firefox] from becoming dominant." is absurd. I could say the same about FireFox having prevented IE from remaining dominant five years ago. Or about any other industry in which there is no pure monopoly. I do not want FireFox to be dominant. I do not want Chrome to be dominant. I want standards to be dominant. I want the web to be browser-agnostic.

[GLSL] code is C-like and has things like pointer arithmetic. Validating it is about as hard as validating arbitrary C code - and if you can work out a way of doing that then you can make a lot of money.

Google Native Client defines a safe subset of x86 machine language into which C can be compiled. Google will make a lot of money.

It's passed to the driver after a token amount of validation.

Firefox and Chrome appear to use a library called ANGLE to translate GLSL into DirectX shader language. How is this translation merely "a token amount of validation"? If it is in fact more than "a token amount of validation", then what is passed to the kernel is not untrusted code. Can you recommend any web pages explaining GLSL validation or lack thereof in practical implementations of WebGL? Is there a better way for untrusted code to draw 3D graphics, and if so, what is it?

In a typical GPU, there is either no MMU or a badly designed, badly tested, buggy MMU

Then the "badly designed, badly tested, buggy MMU" should be replaced.

How about getting your FAQs straight?

I'm pretty sure Google has the Chrome trademark. Since the maker is suing because their "Chromium" is too much like "Chrome"

For that matter, I'm pretty sure Google owns the trademarks on Chromium and Chromium OS as well.

Ummm, Chrome /= Chromium, right? So while the names are similar, and the devices are similar (both netbooks/laptops), what drives them is technically different.

This article discusses Chrome/Chromium , Google's browser-centric operating system. Google owns trademarks on "Chromium" (the contested word).

The Webian Shell basically consists of a browser which will replace the traditional desktop, and web applications are given more importance than the native applications.

This idea seems so familiar...

The original blog post notes that the sandbox for Flash is a "first iteration" and that there is "more work to be done".

Yes, all engineers like to pull that excuse if all else fails. I'm pretty sure Windows Vista was the first iteration of Windows Vista with more work to be done too. I've probably used that excuse myself a few times too. It is quite brazen to make that argument when you're talking about version 11 of your product though (he says, checking the "About Google Chrome..." box)

The original blog post notes that the sandbox for Flash is a "first iteration" and that there is "more work to be done". NPAPI plugins are a huge pain point for browser security since they've traditionally been able to do whatever they want; just throwing them in the normal Chrome sandbox would break them. Sandboxing a plugin like Flash happens in several steps.

Does the initial sandbox have holes? Yes. Does it reduce the attack surface though? Yes. Is it going to be improved further to close those holes? Yes.

From TFA:

"The Flash sandbox blog post went to pains to call it an initial step," said Evans [from Google]. "It protects some stuff, more to come. Flash sandbox [does not equal] Chrome sandbox."

The blog Evans referred to was published in December 2010, where Schuh and another Google developer, Carlos Pizano said, "While we've laid a tremendous amount of groundwork in this initial sandbox, there's still more work to be done."

So yeah, but no, Google never claimed the flash plugin was inside the Chrome sandbox, it's still a work in progress apparently. Of course that doesn't negate the fact that flash is bundled with Chrome and therefor all Chrome users are vulnerable. Still, most users would've installed Flash anyway, this way Google has at least some control over the security issues (though obviously not enough).

Flash is not going away for awhile, especially as long as people keep using outdated browsers en masse and HTML5's implementation isn't (at least somewhat) unified crossbrowser... so with other words it's going take a looooooooong time before Flash is a distant memory. Your best bet is that Google finds a way to *really* sandbox Flash in, so this can't happen anymore. We'll see if they're able to.

Uh, the sandbox is also provided by the OS, not just ASLR and DEP.

Chrome's sandbox is Windows' sandbox, so that's perfectly possible.

Even as rivals like Mozilla and Google have introduced bug bounty program, the Redmond Washington giant has stuck doggedly with a position it articulated almost a decade ago, refusing to offer monetary rewards for information on software holes. But security experts say that position may have to change.

Here is the source for Mozilla projects. Here is the source for Google Chrome. And where do I find Internet Explorer's source code? Oh, right. Well, I'm sure if they truly wanted my help making their browser better and more secure, they'd be okay with letting me take a peek at the source code. How can they start a bug bounty program when they won't even trust the community with seeing their code?

To put it another way: when you practice security through obscurity, offering monetary incentives for bug discovery is not a financially sound decision.

Furthermore, there have been times when a bug submitted to Google was deemed not a bug and a discussion ensued why that was with the source code referenced. I believe Microsoft could just say, "Oh, sorry, we don't owe you anything for discovering that feature but since you can't see the source code you'll have to take our word for it."

Microsoft doesn't need bug bounties. They need to achieve the prerequisite of code inspection before they can even consider putting their money where their mouth is.

What do you think of the SPDY protocol, listed as Chrome's unique feature?

Even if it's faster, is it a good idea for the unity of the web Google to have come up with, and push this idea all on their own?

What would we think if M$ or Compu$erve had come up with their own protocol, to be accessed by their own application program?

http://www.chromium.org/Home

APK

P.S.=>

"Yeah. I love Chrome, but if Google doesn't bite the bullet and respect users' wishes for even a flag request for privacy... they can fuck off." - by osgeek (239988) on Thursday April 14, @10:19AM (#35817582) Homepage

Because I do NOT believe that the folks that built CHROMIUM adhere to the same stuff you're bitching about (rightfully so, & imo too) that Google's CHROME does... apk

You should read the whitepaper at http://www.chromium.org/spdy/spdy-whitepaper [chromium.org] - it's quite interesting.

It's really not that interesting. They make a lot of claims without sources or any support whatsoever and won't answer questions about it, for instance see threads here or on reddit where google employees post about SPDY (ie are reading the thread) but won't answer questions about methods and sources or defend their theories.

Sorry that you feel this way - we've been very explicit about how to contact us, and many many people have found us without trouble. If you've got a question that you want answered, the discussion is on spdy-dev@google.com, and we've always been very open about that fact.

The problem that SPDY is supposed to solve in it's overly complicated way has a simple solution: tweak HTTP pipelining so that the server can respond in any order it wants to.

Well, you should go implement that and come back with some data. If you're right, I'd love to see it. But before you do, you might want to ask yourself, why none of IE, Firefox, nor Chrome ship with pipelining turned on, even though we all want to be fast?

The answer is that pipelining has serious deployment problems, which you can read more about these within the IETF HTTP working group if you wish. Here is a quick list:
    * client-side proxies and intermediaries sometimes just fail to process the requests correctly
    * the responses must come back in the order which they are sent by the client
    * you can't start pipelining until you finish receiving at least one HTTP/1.1 response from a server
    * server farms sometimes loadbalance requests across HTTP/1.1 and HTTP/1.0 servers
    * pipelining requests behind a hanging GET (or any high-latency request) completely breaks.

These might be surmountable - but I assure you that the complexity of implementing pipelining in a way that works on the web today is pretty much on par with the complexity of SPDY. Up until just a few years ago, major sites in the top-100 could not handle pipelining. And when it fails, the user is left with a hung browser, or worse, garbled data. That is why it isn't implemented.

Then servers can send resources when they are available, in smallest-first order, or whatever and the pipeline doesn't block on ad.doubleclick.net (it's just sent last when it is finally finished profiling you).

This is just incorrect information - you should re-read the pipelining specification.

That's all there is to it. The HTTP designers didn't do it because they didn't want to go far enough with changes, instead just tacking pipelining on almost as an afterthought. Maybe Google invented SPDY because they are afraid of tweaking HTTP or think standards move too slowly? I don't know, all I know is that SPDY is bad news.

If you've got data to back that up, I'm listening.

1. It can specify other needed files in header, so browser can start loading them before it gets the http page

This is only a benefit if the resources are already cached locally anyway, so the browser could start loading a .png for instance while the main page html downloads. And there's cost not a benefit if the resource is already in memory. And browsers could do this anyway most of the time by just remembering what resources were used on a page even if the page itself is not cached. So this is an extremely marginal benefit at the cost of some complexity and bandwidth.

2. It can send more than one file at a time. It can mux multiple files, while pipelining only allows you to transfer files one at a time.

If multiple files are multiplexed then when the connection drops then multiple files have to be restarted in the middle instead of just one, and dynamically generated resources need to be redone from scratch. The only practical benefit to sending multiple files at once is that the browser could start processing them with just partial data (with an image header for instance it could allocate the memory for the image). This again is very marginal compared to the transfer time and also more complex.

3. It can prioritize some files over others.

So can pipelining (in general, not "HTTP pipelining"). Browser sends server a list of resource, it replies back sending whole files in smallest-first order for instance. The difference is that if you are sending whole files at once pipelined then you don't have to explicitly state priorities and have mechanism for setting and adjusting them so pipelining is less complex.

4. It can compress the HTTP headers. Modern browsers send their life history, the weather outside, everything that have ever been installed on the computer, every language / encoding it can possibly use, cookies, referer, when it saw the content last, what the etag of that context was, and so on. Header compression can actually make a difference.

So can SSL, which SPDY basically requires anyway because of proxies. Enable deflate compression over SSL and it compresses headers.

You should read the whitepaper at http://www.chromium.org/spdy/spdy-whitepaper [chromium.org] - it's quite interesting.

It's really not that interesting. They make a lot of claims without sources or any support whatsoever and won't answer questions about it, for instance see threads here or on reddit where google employees post about SPDY (ie are reading the thread) but won't answer questions about methods and sources or defend their theories.

The problem that SPDY is supposed to solve in it's overly complicated way has a simple solution: tweak HTTP pipelining so that the server can respond in any order it wants to. Then servers can send resources when they are available, in smallest-first order, or whatever and the pipeline doesn't block on ad.doubleclick.net (it's just sent last when it is finally finished profiling you). That's all there is to it. The HTTP designers didn't do it because they didn't want to go far enough with changes, instead just tacking pipelining on almost as an afterthought. Maybe Google invented SPDY because they are afraid of tweaking HTTP or think standards move too slowly? I don't know, all I know is that SPDY is bad news.

Some tricks:

1. It can specify other needed files in header, so browser can start loading them before it gets the http page
2. It can send more than one file at a time. It can mux multiple files, while pipelining only allows you to transfer files one at a time.
3. It can prioritize some files over others.
4. It can compress the HTTP headers. Modern browsers send their life history, the weather outside, everything that have ever been installed on the computer, every language / encoding it can possibly use, cookies, referer, when it saw the content last, what the etag of that context was, and so on. Header compression can actually make a difference.

You should read the whitepaper at http://www.chromium.org/spdy/spdy-whitepaper - it's quite interesting.

Some quotes:

We downloaded 25 of the "top 100" websites over simulated home network connections, with 1% packet loss. We ran the downloads 10 times for each site, and calculated the average page load time for each site, and across all sites. The results show a speedup over HTTP of 27% - 60% in page load time over plain TCP (without SSL), and 39% - 55% over SSL.

--------

Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers. On the lower-bandwidth DSL link, in which the upload link is only 375 Kbps, request header compression in particular, led to significant page load time improvements for certain sites (i.e. those that issued large number of resource requests). We found a reduction of 45 - 1142 ms in page load time simply due to header compression.

-------

We discovered that SPDY's latency savings increased proportionally with increases in packet loss rates, up to a 48% speedup at 2%. (The increases tapered off above the 2% loss rate, and completely disappeared above 2.5%. In the real world, packets loss rates are typically 1-2%, and RTTs average 50-100 ms in the U.S.)

I'm not sure there's really a security issue here. From the spec, all its doing is letting the server send back multiple items in response to a request for one item. So if you request X, and the server knows you're going to need Y too, it can send both at once.

If server "knows" that I "need" 2MB of flash ads to see the 40K html page, it would send them to me. IOW browser is out of control what server sends, browser can only discard the content which has wasted my bandwidth and isn't going to be displayed.

It's not like the server can connect to you out of nowhere and start firing stuff at you. And since a server can already send malicious content back in response to a request, the security aspect isn't really worse then it already is.

With HTTP, there is no way server can send me something my browser didn't asked for. It can send something bad *instead* of what my browser asked - but only once and with user visible effect. With SPDY, server can send me loads of junk *silently*, still appearing to be serving legit content.

For static content, it is even worse: first time I visit the page it is cached and then a cached copy used. With SPDY, bandwidth is going to be always wasted for transferring the static content. Yes, I need it to display the page - but no, I have already local cached copy.

Yeah, and by their own testing, the push features only resulted in an additional -1% to +3% improvement (yes it made things slightly slower in one case). The additional complexity added by those features is not justified by their benefits. They should just drop them.

It is kind of funny, because this is in Chrome. Thus it is in Chromium, thus it is already in the open.

And the website has a whitepaper trying to explain it and lists all the drafts being worked on for submissing to the IETF:
http://www.chromium.org/spdy
http://www.chromium.org/spdy/spdy-whitepaper
http://www.chromium.org/spdy/spdy-protocol

It is kind of funny, because this is in Chrome. Thus it is in Chromium, thus it is already in the open.

And the website has a whitepaper trying to explain it and lists all the drafts being worked on for submissing to the IETF:
http://www.chromium.org/spdy
http://www.chromium.org/spdy/spdy-whitepaper
http://www.chromium.org/spdy/spdy-protocol

It is kind of funny, because this is in Chrome. Thus it is in Chromium, thus it is already in the open.

And the website has a whitepaper trying to explain it and lists all the drafts being worked on for submissing to the IETF:
http://www.chromium.org/spdy
http://www.chromium.org/spdy/spdy-whitepaper
http://www.chromium.org/spdy/spdy-protocol

1. SPDY uses 1 TCP-connection, instead of many. Which makes it faster. The time to establisch a new TCP-connection is a lot of overhead when you visit a webpage which has many small elements on it. It also has a big advantage when using HTTPS. Again because you just use the one TCP-connection (no extra SSL-connections to establish):

http://www.chromium.org/spdy/spdy-whitepaper

2. It is backwardscompatible and doesn't need any operating system changes like SCTP or different firewall settings and so on.

Yes, I know backwardscompatiblity is a big issue on the internet, but we have to live with it.

3. I think they also submitted their proposed changes for HTTPS to the IETF, like False-Start which helps establish HTTPS (and thus SPDY) connections faster, I think it saves one round-trip.

I'm not sure there's really a security issue here. From the spec, all its doing is letting the server send back multiple items in response to a request for one item. So if you request X, and the server knows you're going to need Y too, it can send both at once.

It's not like the server can connect to you out of nowhere and start firing stuff at you. And since a server can already send malicious content back in response to a request, the security aspect isn't really worse then it already is.

I'll take a stab at it :

Everything is sent through an encrypted channel making it difficult to filter out ads before they hit the client (like with privoxy for example.)
No cashing ("Since we're proposing to do almost everything over an encrypted channel, we're making caching either difficult or impossible." -Protocol Draft) means you'll be served "fresh" ads every time.

So it looks like this would be good news for Google's core business.

A proof-of-concept Apache mod, complete with source to analyze.

The whitepaper on SPDY, open for anyone to read and implement, patent-free.

The client code exists, open and available, in Chromium's trunk.

Please try to at least competently troll next time.

http://www.chromium.org/spdy/spdy-whitepaper

It used to be versions were about feature sets. If you added a small feature to a program you'd increment the minor version, if you added big features you'd release a major update. The idea of having versions increase on specific dates seem weird.

It's for many reasons - especially to cut down on the QA wind-down time that keep stalling the trunk (less features at a time means less time spent winding down and testing - a long time doing that means web standards will race ahead before you've even tested the version you were working on... the other extreme causes the "Internet Explorer effect" - often outdated before it's done, and not because the devs suck, but because the releases are too rare which causes a crapload of testing requirements for each release).

So this is a more "organic" model that should be able to follow new web standards better, and the needs and wants of Mozilla's user base.

Google explained all this pretty well too when they also moved to this model:

http://blog.chromium.org/2010/07/release-early-release-often.html

So, you're saying that the Google funded, closed source, web browser "Chrome" is capable of quickly catching up to the features that the free donation & ads supported Firefox took so long to develop.

Basically you're saying: more money and developers == Faster Development. Thanks for your input Mr. Obvious.

P.S. Yeah, that's right: I said, "Chrome is closed source". Chromium is open source, and Chrome may or may not be a direct derivative of the open source Chromium. Needless to say, Google adds their own proprietary bits to Chromium before they ship it as Chrome, ergo: Chrome = Close Source.

Don't get me wrong, I like Chromium. Chrome is a joke -- Why anyone would want to use the closed / proprietary version (with Google's late-night secret sauce added), when there's a clean open source version available is beyond me.

Whilst you are partially correct, your post sounds like a troll. Dont like closed source?, I hope you're not using windows or OSX. Dont like company-funded things? I really hope you're not even using a computer...or a phone...hell, I guess you could be labelled a hypocrite in any case (I'm not going that far...but just so you know, your arguments are paper-thin at best).

You suggest that Chromium is GREAT while Chrome is BAD, and also that Google add closed-source stuff to chromium which is also somehow bad.

That kind of paints a different picture to the truth, when you realise that Google are behind the development of Chromium too (not just chrome), and about the only difference between chrome and chromium (from a user perspective) is the google logo. Sure there are more differences but in my experience it is Chrome, and NOT Chromium that has always been the more polished, stable version.

So, you're saying that the Google funded, closed source, web browser "Chrome" is capable of quickly catching up to the features that the free donation & ads supported Firefox took so long to develop.

Basically you're saying: more money and developers == Faster Development. Thanks for your input Mr. Obvious.

P.S. Yeah, that's right: I said, "Chrome is closed source". Chromium is open source, and Chrome may or may not be a direct derivative of the open source Chromium. Needless to say, Google adds their own proprietary bits to Chromium before they ship it as Chrome, ergo: Chrome = Close Source.

Don't get me wrong, I like Chromium. Chrome is a joke -- Why anyone would want to use the closed / proprietary version (with Google's late-night secret sauce added), when there's a clean open source version available is beyond me.

Latency, most of these sites care about performance.

SSL/TLS is still a bit slower to make a connection because of the back and forth communication that needs to happen.

Google has done a lot of (backwardscompatible) work on improving that and some other stuff. One of their efforts is called SPDY and can even load a page in less time than normal HTTP:
http://www.chromium.org/spdy

(because you don't need to open several TCP-connections, it uses multiplexing)

If you visit gmail in Chrome you might even already be using SPDY as both support it.

Code verification in this context doesn't imply an attempt to understand the intent of code before running it. Rather, they verify that the code sticks to a safe subset of possible operations that effectively sandbox it out of being able to do anything nasty. They seem to have thorough design documentation on their wiki. I have no prior familiarity with NaCl, but this seems like an appropriate page to look at: http://www.chromium.org/nativeclient/design-documents/nacl-sfi-model-on-x86-64-systems

Looks to me like they know what they're doing:

Our validator implementation requires less than 600 C statements (semicolons), including an x86 decoder and cpuid decoding.

. which I figure is simple enough to tempt lots of smart people into trying to break it for kudos.

A link I didn't save says the implemented safe subset is complete enough that porting even many substantial libraries to the NaCl runtime takes no more than a recompile.

Native Client was designed to easily allow portability across all popular current platforms using cross-compilation. On a single development machine you can currently build executables for x86-32, x86-64, and arm. There is currently support for Windows, Linux, and OSX. Here is an article on the generals.

Much more excitingly though, the team is working hard on integration with LLVM so that you will be able to compile your application into a single LLVM bytecode package. This bytecode would then be sent to any current or future architecture and the final compilation step would occur on that architecture. Here is a pdf concerning that effort.

You are also significantly underestimating the effort that they have put into this BSD licensed project.

Doing it optimally probably isn't possible, but you can statically transform code so it's guaranteed safe by doing somewhat pessimistic transformations, things like replacing every store instruction with a sequence of "safely store" instructions. As long as the analysis and transformations are at the assembly level and don't require recognizing higher-level patterns, obfuscated code isn't really an issue; the main issue is making sure you correctly analyze what safe and unsafe asm instructions are, and what transformations are guaranteed to result in safe code.

There's a nice writeup here of how they do the transformations on ARM.

That's been around for a while. x86 machine code has to be written in a special way which prevents certain problems, such as buffer overflows into return addresses. Google has a modified GCC for this. Read the research paper. It uses the rarely-used segmentation protection features of x86 CPUs to help provide an inner section of sandboxing. That's not enough, though; static analysis of the code, to check that all branches go to valid instructions, is necessary. This works much like the Java byte code verifier, the checker that runs as Java code loads. All returns and calls have to go through some extra code to insure that control goes where it is supposed to.

The 64-bit extensions to the x86 instruction set don't have the segmentation machinery. The AMD designer of that mode once told me "nobody uses that". So this approach doesn't translate well to 64-bit code, and all code under this system runs in 32 bit mode.

This comes with an API and an OS shim. Executable modules can make about a hundred system calls, which are portable across Windows and Linux. In the original version, you couldn't get at the graphics hardware, so it wasn't a suitable delivery mechanism for games. But now, Google has a connection to OpenGL in the thing. That makes it more useful. Games with full system performance could be delivered through this approach, while appearing to run within the browser. The performance is about 90 to 98% of unprotected code.

It's very clever, and a good idea from a security standpoint. Untrusted processes communicating through narrow interfaces are always a good thing from a security perspective. The problem is that it doesn't solve a problem that anybody really seems to have - there's little demand for higher performance apps in the browser.

If you search for the actual source instead of the silly, unsourced article at ConceivablyTech, you'll notice that it talks about Chromium OS, not Chromium (Chrome). So ignore the sensationalism by CT, and go to the actual source.

If you search for the actual source instead of the silly, unsourced article at ConceivablyTech, you'll notice that it talks about Chromium OS, not Chromium (Chrome). So ignore the sensationalism by CT, and go to the actual source.

While I wholeheartedly agree that this is incredibly stupid, I have to wonder where all the ranting about this was a year ago when it was posted.

(This is how old these mockups are.)

Microsoft ... have chosen H.264 as the only one they will support

BZZT! WRONG!

[Citation needed] Everything I've read says they will support H.264, and also allow whatever you want to install otherwise. Defaults matter.

I believe Google might add H.264 support back into Chrome

People also believe virgins can give birth to sons of imaginary etheral entities and that clinically dead people can be arisen just by magical mumbling. That doens't make it a rational belief. Google is removing support for H.264 to kill it as a distribution codec. No more, no less.

My opinion, your opinion. Both are rational. Mine happens to be supported: http://blog.chromium.org/2011/01/more-about-chrome-html-video-codec.html But thanks for the insults anyway.

Graits standards should be mandatory

A business as an individual should be free to operate within .the law. "Should be mandatory" is something that Kim Il Jung and Joseph Stalin likes but that has somehow fallen out of favor among the thinking population.

I would never presume to say anything about what Google should and should not do, but I can analyze their motives.

So sorry. "Ideally, for the benefit of future innovation, gratis standards should be incentivised in the present market." You like that wording better? Creating an incentive for WebM adoption is exactly what Google has done.

I believe that is the goal of the action Google is taking

Google cares about ruling the world according to the book of Google and about selling your personal information to as many advertisers as they can. They don't give a flying dung pile about Gratis or Free.

They claim to. Their stated reasons lines up 100% with my guesses. Strange that... http://blog.chromium.org/2011/01/more-about-chrome-html-video-codec.html

You're allowed to be sceptical, but you could try to be less of a dick about it.

Microsoft ... have chosen H.264 as the only one they will support

BZZT! WRONG!

[Citation needed] Everything I've read says they will support H.264, and also allow whatever you want to install otherwise. Defaults matter.

I believe Google might add H.264 support back into Chrome

People also believe virgins can give birth to sons of imaginary etheral entities and that clinically dead people can be arisen just by magical mumbling. That doens't make it a rational belief. Google is removing support for H.264 to kill it as a distribution codec. No more, no less.

My opinion, your opinion. Both are rational. Mine happens to be supported: http://blog.chromium.org/2011/01/more-about-chrome-html-video-codec.html But thanks for the insults anyway.

Graits standards should be mandatory

A business as an individual should be free to operate within .the law. "Should be mandatory" is something that Kim Il Jung and Joseph Stalin likes but that has somehow fallen out of favor among the thinking population.

I would never presume to say anything about what Google should and should not do, but I can analyze their motives.

So sorry. "Ideally, for the benefit of future innovation, gratis standards should be incentivised in the present market." You like that wording better? Creating an incentive for WebM adoption is exactly what Google has done.

I believe that is the goal of the action Google is taking

Google cares about ruling the world according to the book of Google and about selling your personal information to as many advertisers as they can. They don't give a flying dung pile about Gratis or Free.

They claim to. Their stated reasons lines up 100% with my guesses. Strange that... http://blog.chromium.org/2011/01/more-about-chrome-html-video-codec.html

You're allowed to be sceptical, but you could try to be less of a dick about it.

Actually, neither Firefox nor Chrome is completely Free Software. However, both are based on a majority of Free code, so you can use a build of Chromium or IceCat if you want to use 100% Free Software. I mostly use Firefox, but I'm not opposed to using Chromium or Chrome. While choice among standards is not always a good thing, choice among implementations of standards is.

http://www.chromium.org/

just thought you should know, as well as relevant plugins and extensions for chrome, which does now have an ad-blocker

Chrome != Chromium; Just thought you should know, Google's proprietary executable that is based on Chromium has extra unreleased source code added, and only Google knows what it does.

If I sold you a car with a lock on the hood, would that be okay with you? Come on, when I was developing the prototype I let you peek under the hood! I promise that I didn't install any secret remote kill switches, tracking or recording devices. Trust me!

What? No, you can still not look under the hood of this car, but you should buy it because I'm Google! You can trust me to "not be evil" because that used to be our company motto (well, more of a recommendation...) -- Besides, If you have nothing to hide, you have nothing to fear!

Chrome == Chromium + proprietary Google juice == DO NOT WANT.

Chromium is OK I guess, but as a developer I contribute to Firefox because they don't just adopt and/or drop support for things that they are committed to without at least consulting the (dev) community... ::cough:: H.264 ::cough::

Chrome is completely open source! Essentially: high performance, multiprocess webkit-based browser with a crazy good autoupdate system running its own diff algorithm, and sandboxing everywhere to keep users secure. Its a much better architecture than Firefox, which has so much legacy code dating back to when they though Netscape 6 was a good idea.

http://www.chromium.org/developers/design-documents

There's a variety of licenses, since they use Webkit (GPL) and some Mozilla stuff (MPL), but most of the Google-authored stuff is BSD.

Also, Mozilla never supported h.264 because they were financially unable to do so. Google dropping support and switching to WebM - the free format, is doing nothing but helping them. The losers here are Apple and Microsoft.

http://www.chromium.org/

just thought you should know, as well as relevant plugins and extensions for chrome, which does now have an ad-blocker

As a business tool, it's all but useless. Google provides no mechanism for installing even standard Linux VPN software which most companies provide for their remote employees. Or any other software, for that matter. Also, no company with a brain in their head is going to allow employees to be storing internal data on another company's servers. This might be a little more useful if a company could customize it to use internal servers rather than Google's, but as far as I've been able to tell, that option just doesn't exist.

This was addressed in the December 7 launch event. Google has deals worked out with a number of businesses (they had a list, it was at least one or two dozen) that are extremely interested in replacing as many of their machines as possible with Chrome OS notebooks. In addition to Google Apps and internal company websites, it will support Citrix, which they had a demo of: you can log into the company's servers and run Office or any of dozens of other major corporate applications remotely. (I can't find a link to the video, sadly; I watched it live and the URL stopped working after it was over.)

The major advantage is zero maintenance burden. By design, Chrome OS notebooks are totally interchangeable. You can chuck it out the window, grab another one, enter in your Google login info, and you won't be able to tell the difference. It also will never get viruses; it updates itself without user intervention; and the lack of customizability means it's unlikely users will be able to mess it up to the point that IT has to get involved. There go all your OS-level customer support costs.

Chrome (thus presumably Chrome OS too) is also deploying features that will allow corporate admins to lock down the browser, the way IE has supported for years. The employer can require that certain extensions be installed, disable the password manager, and much more, with more features to be added as time goes on. And you can't get around it by installing another browser, because you can't install anything.

No, Chrome OS is a corporation's dream. Idiot-proof, tamper-resistant, and zero-maintenance.

No. This was actually announced 2 weeks ago by Google and Adobe, not today. http://blog.chromium.org/2010/12/rolling-out-sandbox-for-adobe-flash.html

In case you missed it, the Chromium Blog talked about this in their December 1st blog entry.

Referring to this from the chrome os architecture pages

If verification fails, the user can either bypass checking or boot to a safe recovery mode.

That's the step where the system checks it's integrity. Google has said all along that users would not be forced out of their own devices by overzealous security measures.

http://www.chromium.org/chromium-os/chromiumos-design-docs/security-overview

The headline's a bit misleading. Users _can_ replace the OS. However, the BIOS will check signatures on the OS, and offer to restore from a known-good backup on boot (without destroying user data). This ensures that if the OS is infected by a virus or something, it's very, very easy to restore.
There are specific points in the design docs where they make it clear that they do want to support advanced users installing their own OS, to the extent that that does not cause trouble for less advanced users.