Today we are releasing version 7 of the V8 Benchmark Suite. This new version adds Oliver Hunt’s 2D Navier-Stokes fluid dynamic simulation, which stresses intense double array computations. These complex double array computations are today common in games, graphic and scientific applications.

The new test shows the recent improvements V8 has made in handling advanced physics computations: the current Chrome 18 (today in beta) delivers a 5% score improvement compared to the current Chrome 17. Chrome 19 (today in canary), where the full set of improvements is being released, delivers a whopping 25% score improvement compared to Chrome 17.

With these additions, the V8 Benchmark Suite is now a more comprehensive collection of eight tests, including OS kernel simulation, crypto and string operations, memory management stress-tests, and as of today, double array computations.

We plan to keep updating the suite by adding more tests. These updates are a reflection of Chrome’s commitment to keep pushing the boundaries of speed, optimizing the engine for today’s more demanding web apps.

A few weeks ago one of my developer friends was gushing about the capabilities of his favorite native platform. After every point I felt obliged to point out that the web platform either already had or was actively developing precisely the same capabilities—and then some. He was incredulous. "Prove it," he said.

So I pulled together a few of my favorite examples from the cutting edge of the web platform and recorded three screencasts to help my friend—and others—meet the web platform again for the first time.

The first video, Building on Foundations, goes over how the web platform has been fixing various historical shortcomings and building upon its core strengths, like complicated graphical effects, composability, and advanced text layout.

The next video, Learning from Other Platforms, reviews how the web platform offers new capabilities inspired by successes on other platforms with things like push notifications, payment APIs, and web intents.

Security is one of our core values, alongside speed, stability and simplicity. From day one, we’ve designed Chrome’s extension system with security in mind. Since we launched the extension system, the state of the art in web security has advanced with technologies like Content-Security-Policy (CSP). Extension developers have been able to opt into these features, and now we’re enabling these security features by default.

Unfortunately, securing extensions with CSP by default is incompatible with the legacy extension system. We’re passionate about extension compatibility, so we’re going to make this change gradually to minimize pain for users and developers.

Users can continue to install extensions that are available in the store regardless of whether they are secured with CSP or not. This means they will not lose any of the functionality they've added to Chrome.

Developers will be able to choose when to enable the new behavior. To ease the transition, we've introduced a new manifest version attribute in the extension manifest in Chrome 18 (currently in beta). When a developer updates his or her extension to use manifest_version 2, Chrome will enforce the following CSP policy by default:

script-src 'self'; object-src 'self' 

This policy imposes the following restrictions on extensions:

1. Extensions can no longer use inline scripts, such as 
   
   . Instead, extensions must use out-of-line scripts loaded from within their package, such as 
   . 
2. Extensions can no longer use eval(). Note: If you’re using eval to parse JSON today, we suggest using JSON.parse instead. 
3. Extensions can load plug-ins, such as SWF files, only from within their package or from a whitelist of HTTPS hosts. 

A recent study from researchers at UC Berkeley suggested that these restrictions, taken together, would substantially improve the security of the extension system:

These defenses are extremely effective: adopting one of the recommended CSPs would prevent 96% (49 out of 51) of the core extension vulnerabilities we found. 

For most extensions, updating them to manifest_version 2 will require the developer to move inline scripts out-of-line and to move scripts loaded from the network into the extension package. Developers are not required to update their extensions to manifest_version 2 immediately, but, over time, more of the extension ecosystem will encourage developers to update their extensions. For example, at some point, we’ll likely start requiring new extensions uploaded to the web store to use manifest_version 2. You can find a complete list of changes and more details about CSP in the extension documentation.

This year at the CanSecWest security conference, we will once again sponsor rewards for Google Chrome exploits. This complements and extends our Chromium Security Rewards program by recognizing that developing a fully functional exploit is significantly more work than finding and reporting a potential security bug.

The aim of our sponsorship is simple: we have a big learning opportunity when we receive full end-to-end exploits. Not only can we fix the bugs, but by studying the vulnerability and exploit techniques we can enhance our mitigations, automated testing, and sandboxing. This enables us to better protect our users.

While we’re proud of Chrome’s leading track record in past competitions, the fact is that not receiving exploits means that it’s harder to learn and improve. To maximize our chances of receiving exploits this year, we’ve upped the ante. We will directly sponsor up to $1 million worth of rewards in the following categories:

$60,000 - “Full Chrome exploit”: Chrome / Win7 local OS user account persistence using only bugs in Chrome itself.

$40,000 - “Partial Chrome exploit”: Chrome / Win7 local OS user account persistence using at least one bug in Chrome itself, plus other bugs. For example, a WebKit bug combined with a Windows sandbox bug.

$20,000 - “Consolation reward, Flash / Windows / other”: Chrome / Win7 local OS user account persistence that does not use bugs in Chrome. For example, bugs in one or more of Flash, Windows or a driver. These exploits are not specific to Chrome and will be a threat to users of any web browser. Although not specifically Chrome’s issue, we’ve decided to offer consolation prizes because these findings still help us toward our mission of making the entire web safer.

All winners will also receive a Chromebook.

We will issue multiple rewards per category, up to the $1 million limit, on a first-come-first served basis. There is no splitting of winnings or “winner takes all.” We require each set of exploit bugs to be reliable, fully functional end to end, disjoint, of critical impact, present in the latest versions and genuinely “0-day,” i.e. not known to us or previously shared with third parties. Contestant’s exploits must be submitted to and judged by Google before being submitted anywhere else.

Originally, our plan was to sponsor as part of this year’s Pwn2Own competition. Unfortunately, we decided to withdraw our sponsorship when we discovered that contestants are permitted to enter Pwn2Own without having to reveal full exploits (or even all of the bugs used!) to vendors. Full exploits have been handed over in previous years, but it’s an explicit non-requirement in this year’s contest, and that’s worrisome. We will therefore be running this alternative Chrome-specific reward program. It is designed to be attractive -- not least because it stays aligned with user safety by requiring the full exploit to be submitted to us. We guarantee to send non-Chrome bugs to the appropriate vendor immediately.

Drop by our table at CanSecWest to participate and check the latest news.

Cross posted to the Google Code Blog

An attractive feature of Web programming is a rapid development cycle. Reloading the application after the source code has changed takes a fraction of a second. We want to offer you that same experience when using Dart, and today we’re making Mac and Linux binaries available that integrate the Dart VM into Chromium.

This technology preview allows you to run your Dart programs directly on the Dart VM in Chromium and avoid a separate compilation step. Over time, these programs will take advantage of the VM’s faster performance and lower startup latency.

Dart has been designed from the start to work with the entire modern web, and we’re simultaneously continuing to improve our fast Dart-to-JavaScript compiler. Both the Dart VM and modern JavaScript engines are first-class targets for Dart.

This release of Chromium with Dart VM integration is a technology preview, and should not be used for day-to-day browsing. After more testing and developer feedback, we plan to eventually include the Dart VM in Chrome.

Today’s release of the Chromium + Dart VM integration is another step forward for the open source "batteries included" Dart platform. Our goal is to help you build complex, high performance apps for the modern web, and we encourage you to try Dart and let us know what you think.

When we launched the Chrome Web Store a year ago, our app taxonomy system reflected the apps that were available in the store at the time. However, since then, the store’s app inventory has grown and changed in composition. So, yesterday we made important changes in the Chrome Web Store’s app category system to allow more great apps of all kinds to stand out.

Until now, you could list your app into two categories. With the new category structure, we will show your app only in the primary category that you select for your app in the developer dashboard. We've found that secondary app categories contributed to a confusing experience for Chrome users and developers so from now on, we're going to start ignoring the secondary category.

We also updated the list of top level app categories and created multiple sub categories in each of them.

More specifically, given the growing use of Chrome and Chromebooks in large and small businesses, we created a new category called “Business Tools” that can help enterprise focused developers target these users. Also, “Shopping” has been reclassified as a subcategory, within the “Lifestyle” category.

The new structure of the store will improve discoverability for apps. For example, users searching for a photo album app can now easily drill down to the “Photos” subcategory level and track down the app they are looking for. At the same time, apps assigned to a subcategory show up in the category page as well giving them wider exposure; an app in "Photos" will appear on both the "Photos" page and the "Entertainment" page.

The categories will continue to evolve over time. To that effect, in the Developer Dashboard you will see a few more subcategory options than the ones that are live in the Chrome Web Store today. We plan to expose these subcategories to users once we confirm we have enough interesting apps in each one of them. In the meantime, items assigned to these subcategories will show up at a related subcategory. For example all items on “Online Documents & File Storage” will show up for now in “Office Tools”.

This transition required our team to take a stab at automatically assigning all apps to one of our new categories / subcategories. Please take a look at the developer dashboard and make sure the placement of your app accurately reflects your business goals and the experience you offer.

All good things come in threes. So, this week, the Chrome Developer Relations team is releasing three new resources for developers.

First, we are making available a brand new Field Guide to Web Applications, to help developers create great web apps. This guide walks you through topics like app design fundamentals, tips for creating great experiences and a few case studies that put the best practices to use. Whether you're building your first web app or are just looking for ways to improve your existing apps, we hope you'll find the field guide useful.

Second, our popular HTML5 site, HTML5Rocks.com, was also remodeled to better organize the site's content. You’ll now find new "persona pages" with catered content in 3 different verticals (Games, Business, Mobile). In addition, we consolidated many of the different components, and deeply integrated the HTML5 technology classes to bring a better identity to the site.

Finally, we've also joined Google+ with a new page specifically for Chrome Developers. Whether you’re building modern web apps, using Dart or WebRTC, we’ll be there to help you! Keep your eyes open for our weekly hangouts and add us to your circles.

The ECMA committee is working hard on designing the next version of JavaScript, also known as "Harmony". It is due by the end of next year and it is going to be the most comprehensive upgrade in the history of this language.

Chrome and V8 are committed to pushing JavaScript forward and have already started implementing the new features. You can try some of them today in the latest dev channel release. Here’s a summary:

• Lexical scoping. Now "let" is the new "var" – traditional "var" declarations are complemented with "let" and "const". Both are properly block-scoped bindings, eliminating a common source of errors and weird behaviour. Function declarations are now officially allowed in local scope as well, and also obey lexical scoping. (Note: Lexical scoping is only available in ES strict mode.)

• Collections. Efficient maps and sets will make your life easier. Any value can be used as a key or element, including objects. No surprises, no more need to abuse objects as dictionaries. (Caveat: Iteration over collections is not yet specified.)

• Weak maps. A special kind of map for which the garbage collector determines when a key is no longer reachable, so that the key-value pair can be removed from the map automatically. This goes a long way towards avoiding memory leaks in long-lived tables and relieves the developer from worrying about stale entries.

• Proxies. A proxy simulates a JavaScript object or function, and can customize just about any aspect of their behaviour that you can imagine. This is a real power feature, that takes reflection to a new level and can be used to implement various advanced abstractions and interfaces. 

 ...and there is a lot more to come, as the V8 team will continue working on bringing new Harmony features to you.

To enable Harmony features in the latest dev channel release of Chrome, go to chrome://flags and toggle on "Experimental JavaScript features". We encourage you to try them out and give us feedback!

It’s hard for us to believe, but it’s been just over two years since we first announced the Chromium Security Rewards Program.

We’ve been delighted with the program’s success; we’ve issued well over $300,000 of rewards across hundreds of qualifying bugs, all of which we promptly fixed. It also helped inspire a wave of similar efforts from companies across the web, including Google’s own vulnerability reward program for web properties, which has also been

We’ve been fascinated by the variety and ingenuity of bugs submitted by dozens of researchers. We’ve received bugs in roughly every component, ranging from system software (Windows kernel / Mac OS X graphics libraries / GNU libc) to Chromium / WebKit code and to popular open source libraries (libxml, ffmpeg). Chromium is a more stable and robust browser thanks to the efforts of the wider security community.

Today we’re expanding the scope of the Chromium program to formally include more items that deserve recognition:

• High-severity Chromium OS security bugs are now in scope. Chromium OS includes much more than just the Chromium browser, so we’re rewarding security bugs across the whole system, as long as they are high severity and present when “developer mode” is switched off. Examples of issues that may generate a reward could include (but are not limited to): 
  • Renderer sandbox escapes via Linux kernel bugs. 
  • Memory corruptions or cross-origin issues inside the Pepper Flash plug-in. 
  • Serious cross-origin or memory corruption issues in default-installed apps, extensions or plug-ins. 
  • Violations of the verified boot path. 
  • Web- or network-reachable vulnerabilities in system libraries, daemons or drivers.

Chromium OS security bugs should be reported in the Chromium OS bug tracker, whilst security bugs affecting the desktop Chromium browser should be reported in the Chromium bug tracker.

• We may elect to issue “bonuses” ranging from $500 to $1000 if a bug reporter takes on fixing the bug they have found themselves. For eligibility, this process involves working with the Chromium community to produce a peer reviewed patch. These bonuses are granted on top of the base reward, which typically runs between $500 and $3133.70. 

• The base reward for a well-reported and significant cross-origin bug (for example a so-called UXSS or “Universal XSS”) is now $2000. 

Perhaps most importantly, this program reflects several of our core security principles: engaging the community, building defense in depth, and particularly making the web safer for everyone.

Related to this third core principle, we’re particularly excited by all the work that has been done on shared components. For example, a more robust WebKit not only helps users of two major desktop browsers, but also a variety of tablet and mobile browsers.

Today, we introduced Chrome for Android Beta, which brings Chrome’s capabilities to phones and tablets running Android 4.0, Ice Cream Sandwich. This is made possible by a range of innovative features and by building a mobile browser from the ground up that makes full use of the underlying architecture built into Android 4.0.

Chrome for Android brings support for many of the latest HTML5 features to the Android platform. With hardware-accelerated canvas, overflow scroll support, strong HTML5 video support, and new capabilities such as Indexed DB, WebWorkers and Web Sockets, Chrome for Android is a solid platform for developing web content on mobile devices.

In addition to support for the latest web technologies, we hope to make interactive web content super easy to develop. Chrome for Android introduces remote debugging through Chrome Developer Tools to make it simple for developers to debug web sites running live on their mobile devices.

Much of the code for Chrome for Android is already shared with Chromium and over the coming weeks, the Chromium team will be upstreaming many new components developed for Chrome for Android to Chromium, WebKit and other projects.

We’ve got a lot more planned to make Chrome as feature-rich on mobile devices as it is on the desktop. We encourage you to follow any of the ongoing development via the issue tracker or join in on chromium-dev@chromium.org.

While the web is a virtual treasure trove of great content, it’s also used by bad guys to steal personal information. One of Chrome’s most advanced security features, Safe Browsing, helps protect against the three most common threats on the web: phishing, drive-by malware, and harmful downloads. We recently announced some new enhancements to Safe Browsing, so we thought we’d offer an inside look into how it works.

Safe Browsing downloads a continuously-updated list of known phishing and malware websites, generated by an automated analysis of our entire web index. Each page you visit, and each resource (such as pictures and scripts) on the page, are checked against these lists. This is done in a way that does not reveal the websites you visit, and is described in more detail in our video on Safe Browsing. If Chrome detects that you’ve visited a page on the list, it warns you with a large red page that helps you get back to safety.

Of course, this only helps for dangerous content that Google already knows about. To provide better protection, Safe Browsing has two additional mechanisms that can detect phishing attacks and harmful downloads the system has never encountered before.

Phishing attacks are often only active for a few short hours, so it’s especially important to detect new attacks as they happen. Chrome now analyzes properties of each page you visit to determine the likelihood of it being a phishing page. This is done locally on your computer, and doesn’t share the websites you visit with Google. Only if the page looks sufficiently suspicious will Chrome send the URL of that page back to Google for further analysis, and show a warning as appropriate.

Malicious downloads are especially tricky to detect since they’re often posted on rapidly changing URLs and are even “re-packed” to fool anti-virus programs. Chrome helps counter this behavior by checking executable downloads against a list of known good files and publishers. If a file isn’t from a known source, Chrome sends the URL and IP of the host and other meta data, such as the file’s hash and binary size, to Google. The file is automatically classified using machine learning analysis and the reputation and trustworthiness of files previously seen from the same publisher and website. Google then sends the results back to Chrome, which warns you if you’re at risk.

It’s important to note that any time Safe Browsing sends data back to Google, such as information about a suspected phishing page or malicious file, the information is only used to flag malicious activity and is never used anywhere else at Google. After two weeks, any associated information, such as your IP address, is stripped, and only the URL itself is retained. If you’d rather not send any information to Safe Browsing, you can also turn these features off.

This multi-pronged protection combines to make you much safer against the most prevalent attacks on the web while carefully guarding your privacy. We’ve always believed in making the web a safer place for everyone, so we also make the Safe Browsing API available for free to other browsers and websites.

Safe surfing!

Cross posted to: dartlang.org and the Google Code Blog

It took approximately 2000 years for the original Rosetta Stone to be discovered, which helped translate the Egyptian Hieroglyphs. We couldn’t wait that long to bridge the Dart and JavaScript worlds, so today we are releasing the JavaScript to Dart Synonym app.

Like most web developers, we are familiar, comfortable, and productive with JavaScript. We were curious about Dart, and thanks to a recent Dart hackathon, we had the chance to play with the language and libraries. The problem was, as JavaScript developers, we didn’t know how to map common JavaScript idioms to Dart. Hence the idea for this synonym app was born.

We started with the basics that every JavaScript and jQuery developer knows: variables, arrays, functions, classes, DOM manipulation, and many more. Then, with the help of the Dart team, we recorded the corresponding Dart versions of each idiom. To practice what we learned, we wrote this app with Dart.

We hope our app that maps between JavaScript and Dart eases your introduction to Dart and gives you a sense of where the project is going. We know the team is eager to hear your feedback. Don’t hesitate to join the conversation or file a new issue for either Dart or the Synonym app. And remember, Dart isn’t set in stone, so your feedback counts.

In the two years since we announced SPDY, we’ve been working with the web community on evolving the spec and getting SPDY deployed on the Web.

Chrome, Android Honeycomb devices, and Google's servers have been speaking SPDY for some time, bringing important benefits to users. For example, thanks to SPDY, a significant percentage of Chrome users saw a decrease in search latency when we launched SSL-search. Given that Google search results are some of the most highly optimized pages on the internet, this was a surprising and welcome result.

We’ve also seen widespread community uptake and participation. Recently, Firefox has added SPDY support, which means that soon half of the browsers in use will support SPDY. On the server front, nginx has announced plans to implement SPDY, and we're actively working on a full featured mod-spdy for Apache. In addition, Strangeloop, Amazon, and Cotendo have all announced that they’ve been using SPDY.

Given SPDY's rapid adoption rate, we’re working hard on acceptance tests to help validate new implementations. Our best practices document can also help website operators make their sites as speedy as possible.

With the help of Mozilla and other contributors, we’re pushing hard to finalize and implement SPDY draft-3 in early 2012, as standardization discussions for SPDY will start at the next meeting of the IETF.

We look forward to working even closer with the community to improve SPDY and make the Web faster!

To learn more about SPDY, see the link to a Tech Talk here, with slides here.

One of my favorite features of Chrome got a boost earlier today, as we announced support for an experimental new “autocomplete type” attribute for form fields. The new attribute will allow web developers to unambiguously label text and select fields with common data types such as ‘full-name’ or ‘street-address’ and guarantee that their site’s forms work correctly with Chrome Autofill and other form-filling providers.

We’ve been working on this design in collaboration with several other autofill vendors. Like any early stage proposal we expect this will change and evolve as the web standards community provides feedback, but we believe this will serve as a good starting point for the discussion on how to best support autofillable forms in the HTML5 spec. For now, this new attribute is implemented in Chrome as x-autocompletetype to indicate that this is still experimental and not yet a standard, similar to the webkitspeech attribute we released last summer.

For more information, you can read the full text of the proposed specification, ask questions on the Webmaster help forum, or you can share your feedback in the standardization discussion!

Since we open sourced WebRTC this past summer, we’ve been working hard with browser vendors to integrate WebRTC technology in their products. Today, we reached an important milestone: WebRTC is now integrated in the Chrome browser available on the dev channel.

Building industry-leading voice and video capabilities into the browser makes it easier for web developers to incorporate real time communications in their apps. Instead of relying on custom, OS specific, proprietary plug-ins, they can now easily build and maintain their apps using a few simple JavaScript APIs and have the browser do the heavy lifting.

Even though WebRTC is still evolving, we are receiving feedback from the standards process in W3C and IETF and there are already plenty of apps in development. For example, companies like Polycom, Vonage, Vehix.com, Firespotter, Siemens, Nimbuzz and PCCW are currently actively developing browser based solutions using WebRTC.If you are interested to learn more on how you can use WebRTC in your app, review our documentation, join our developer discussion group and go to the WebRTC blog for more details. We are looking forward to seeing what you come up with!

When we first set out to design Chrome, we knew we had a unique opportunity to improve the security of the web. In addition to speed and simplicity, we’ve been adamant that security be a central tenet of everything we build. Chrome and the web have since come a long way, and we’ve been challenged to protect a complex and rapidly changing browser against the many threats that emerge on the web.

After spending tens-of-thousands of hours working on ways to make users safer on the web, we thought it might be worth sharing the Chrome security principles that guide the work that we do.

There are lots of technical details, but the fundamentals have always been simple. Security should compliment your browsing experience, not detract from it, and your browser should be secure by default -- no configuration required. No defense is ever perfect, so we rely on multiple layers of protection to help guard against single points of weakness. We support and fund the security research community in their work to identify weaknesses, and when vulnerabilities are found, we pride ourselves on patching them faster than any other browser.

These principles have served us well in protecting users while keeping Chrome super fast and easy to use. If you develop software, we hope you find them helpful in securing your own product, and if you’re a Chrome user, that they give some insight into the many ways we work to help you surf with confidence.

• Ease of use: the short payment process for consumers takes place right in the developer’s app or site.
• Large existing user base: there are millions of Google Wallet online users in over 140 countries.
• Low fees: developers pay just 5% on all transactions.