Chrome's sync will support apps following the update. Of course, this won't really do much good until Google opens the Store and allows us to install apps from an official location but this is still an important addition. 7.0.517.0 is slated as the next Chrome beta version, so with app support looking good it would make sense for the arrival of the next beta browser to coincide with the beta testing of some actual apps, too.

One final change you may notice is a tweak to the design of the new tab page. Your installed apps and most visited sites are now collapsible (as they have been in Chromium builds for a few days now) and a shadow effect has been added to the horizontal separators. You currently can't have both sections expanded at once, but they can both be collapsed. The sections also auto-collapse -- click to show apps, and your sites will iconize, and vice versa.

About:Labs has also arrived in Chrome dev, so you can now take side tabs for a test drive by visiting the Labs page instead of adding a command line switch.

Now, back to the update process itself...

This is also the first time I've had trouble retrieving a Chrome update. Google's Anthony Laforge announced the release last night, but Chrome still tells me that the update server is not available. There could be any number of reasons for the hold-up, but with the arrival of the Web Store just around the corner and the possibility of Chrome OS hardware on the way, Google may be rolling out additional hardware or battening down the hatches on current servers in preparation.

Patience, young padawan. Your dev channel update will arrive soon if you're getting the "not available" message -- try restarting Chrome and see if that fixes things.

 

Google Chrome's context menu doesn't present a wide array of functions -- copy, search, and inspect elements are about all you get when selecting text. The SmartSelect extension, however, lets you set up as many custom search options as you want.

By default, SmartSelect can search selected text with Google, Google Maps/Directions, Dictionary.com, and Wikipedia. Adding new search engines is incredibly simple via the extension's options page. Just name your entry, paste in the appropriate search URL, and add [selected] where the highlighted text needs to appear.

Unfortunately, it's not so easy to add an icon for your newly-created search just now. If you want to add an icon, you'll need to drop a .PNG into the extension's folder (mine is located at C:\Users\Lee\AppData\Local\Google\Chrome\User Data\Default\Extensions\ppogmggnjkiajddfecpjbjicpcobmaefitem.0.2_0\img), and then enter the filename minus the extension on SmartSelect's options screen (download, not download.png).

You may also want to enable the Ctrl+click option to activate the extension; I found that the menu was a bit to eager to spring into action otherwise.

 

Chromium -- Google Chrome's open source cousin -- recently debuted the new about:labs page which brings easier access to bleeding-edge features. The Labs page provides a simpler, GUI-based system for enabling things like side tabs which you previously had to activate via command line switches.

In the latest Chrome Canary update, Labs has arrived. That means Mac users can now enable tab overview (an Expose-like feature which shows all your open tabs) and Windows users can play around with side tabs -- no switches required! Just enable the feature on about:labs and restart, and you're good to go.

Remember, this has just hit Canary -- but the dev channel shouldn't be too far behind.

Hopefully Google will begin adding other features to the page now that it's made the jump to Chrome. First on our wish list; hardware acceleration!

 

There are a lot of great extensions in the Chrome Gallery. However, as the Chrome APIs round out and extensions have increased access to things like your history, cookies, and file system you may want to take a closer look at what a particular extension can do before you install it.

Fortunately there's a new extension which can do just that. What?! An extension to peek under the hood of other extensions? Yep. It's called Extension Gallery Inspector, and it's pretty slick.

Install the Inspector and head to the Chrome Extensions Gallery. When you browse an extension's detail page, the lightning bolt icon will appear in your Omnibar. Click it, and Inspector will unpack the .CRX file and scan for API calls, permissions, and OAuth support. It also tells you the uncompressed size of the extension and whether or not it has an options page and browser action icon.

Still not enough info for you? Click the view files link and you can actually check out the extension's source code, icons, and manifest file.

You'll obviously need a bit of technical knowledge to benefit from Extension Gallery Inspector as it stands right now. Still, for power users who want to know what an extension has access to -- or developers who are just curious how a particular extension works -- Inspector is a must-have Google Chrome extension.

 

I've asked about this before, and I'll pose the question one more time: if you're not going to put Chrome themes where the other Chrome themes go, shouldn't you at least create a category, Google?

Google has introduced half a dozen new official Chrome themes, but you won't find them if you click the get themes link on your Personal Stuff menu. No, like the scores of user-created themes out there these new themes from Google have been dropped into the Extensions Gallery.

I'm sure the plan is to list everything in the Gallery at some point (possibly once it's re-branded as the Web Store?), but it really shouldn't be hard to give themes their own section on the existing Gallery. Or, you know, post them on the page Chrome takes you to when you click get themes.

The new themes are called Modern, Adaptive, Vibrant, Inventive, Fresh, and Orkut_Hudson. They're artist-created, and generally not for those of you who like Chrome's interface to be as unobtrusive as possible -- some are downright loud.

Beauty is in the eye of the beholder of course -- tell us what you think of the new themes in the comments.

 

Many of our readers have been frustrated by having to add command line switches to Google Chrome in order to try out a new feature. In truth, it's really not a difficult procedure (though Windows and Linux users have it far easier than those on Mac) -- but wouldn't it be cool if you could just click something to turn them on?

Starting soon, you just might be able to do that. Google OS spotted a new addition to the Chromium browser: an about:labs page. Load it up, and you'll see experimental browser features which you can enable -- like side tabs on Windows and tab expose on Mac.

At least, very soon you'll be able to turn the features on via this page. Right now, it's not functional. Clicking enable on tabs on the left didn't actually activate the feature for me -- I still had to add the --enable-vertical-tabs switch to my shortcut.

The addition of about:labs is a nice touch, and will allow more users to kick the tires on cutting-edge features. That, of course, is a good thing for Google. A larger group of testers should allow them to tackle bugs more quickly and push features from the dev and canary builds to the beta and stable channels even more quickly.

 

The Web Timing draft specification presents a standard set of metrics for measuring web page load time across browsers. We’re happy to announce that in Chrome 6, web developers can now access these new metrics under window.webkitPerformance.

Measuring web page load time is a notoriously tricky but important endeavor. One of the most common challenges is simply getting a true start time. Historically, the earliest a web page could reliably begin measurement is when the browser begins to parse an HTML document (by marking a start time in a block at the top of the document).

Over the next few months, we are going to be rolling out a new release process to accelerate the pace at which Google Chrome stable releases become available. Running under ideal conditions, we will be looking to release a new stable version about once every six weeks, roughly twice as often as we do today.

 

So why the change? We have three fundamental goals in reducing the cycle time:

• Shorten the release cycle and still get great features in front of users when they are ready
• Make the schedule more predictable and easier to scope
• Reduce the pressure on engineering to “make” a release

The first goal is fairly straightforward, given our pace of development. We have new features coming out all the time and do not want users to have to wait months before they can use them. While pace is important to us, we are all committed to maintaining high quality releases — if a feature is not ready, it will not ship in a stable release.

 

The second goal is about implementing good project management practice. Predictable fixed duration development periods allow us to determine how much work we can do in a fixed amount of time, and makes schedule communication simple. We basically wanted to operate more like trains leaving Grand Central Station (regularly scheduled and always on time), and less like taxis leaving the Bronx (ad hoc and unpredictable).

 

The third goal is about taking the pressure off software engineers to finish features in a single release cycle. Under the old model, when we faced a deadline with an incomplete feature, we had three options, all undesirable: (1) Engineers had to rush or work overtime to complete the feature by the deadline, (2) We delayed the release to complete that feature (which affected other un-related features), or (3) The feature was disabled and had to wait approximately 3 months for the next release. With the new schedule, if a given feature is not complete, it will simply ride on the the next release train when it’s ready. Since those trains come quickly and regularly (every six weeks), there is less stress.

 

So, get ready to see us pick up the pace and for new features to reach the stable channel more quickly. Since we are going to continue to increment our major versions with every new release (i.e. 6.0, 7.0, 8.0, 9.0) those numbers will start to move a little faster than before. Please don’t read too much into the pace of version number changes - they just mean we are moving through release cycles and we are geared up to get fresher releases into your hands!

 

It has been approximately six months since we launched the Chromium Security Reward program. Although still early days, the program has been a clear success. We have been notified of numerous bugs, and some of the participants have made it clear that it was the reward program that motivated them to get involved with Chromium security.

 

We maintain a list of issued rewards on the Chromium security page. As the list indicates, a range of researchers have sent us some great bugs and the rewards are flowing! This list should also help answer questions about which sort of bugs might qualify for rewards.

 

Today, we are modifying the program in two ways:

1. The maximum reward for a single bug has been increased to $3,133.7. We will most likely use this amout for SecSeverity-Critical bugs in Chromium. The increased reward reflects the fact that the sandbox makes it harder to find bugs of this severity.
2. Whilst the base reward for less serious bugs remains at $500, the panel will consider rewarding more for high-quality bug reports. Factors indicating a high-quality bug report might include a careful test case reduction, an accurate analysis of root cause, or productive discussion towards resolution.

Thanks to everyone who contributes to Chromium security, and here’s looking forward to our first elite entrant!

 

If you missed the Day 1 keynote this year, it was all about the open web. There were some amazing demos from Mugtug, TweetDeck, Adobe, and Sports Illustrated demonstrating the full potential of HTML5. There was a preview of WebM/VP8, a high-quality, open, and web-optimized video format. We saw the announcement of the Chrome Web Store, which later this year will provide a new and exciting channel for developers to distribute their web apps and reach new users. We also launched the Google Font API, which allows you to add high-quality web fonts to any web page. Lastly, there were all of the great Chrome sessions. Videos have been posted on the Google I/O website:

• Developing with HTML5
• Developing web apps for the Chrome Web Store
• Beyond JavaScript: programming the web with native code
• Chrome extensions - how-to
• Google Chrome's Developer Tools
• Using Google Chrome Frame
• HTML5 status update
• WebM Open Video Playback in HTML5

 

The Google Chrome Dev channel is now up to 6.0.422.0. It includes a bunch of new features to think about when developing your apps:

• Desktop notifications (new since our last developer update)
• File API and FileReader API: Drag and drop files from the desktop to the browser!
• Native Client (NaCl) SDK and ports: Run with --enable-nacl.
• HTML5 sandbox attribute
• Integrated Flash Player plugin: Run dev channel with --enable-internal-flash.

In addition to the above, there are new experimental extension APIs:

• chrome.experimental.cookies
• chrome.experimental.clipboard
• chrome.experimental.omnibox

You can try out these features by launching a Dev-channel version of Google Chrome with the --enable-experimental-extension-apis flag and adding the ‘experimental’ permission in your manifest.json file. Please keep in mind that these features are still under development and are not 100% stable yet.

When we released a new stable version of Google Chrome last March, we tried to improve the transparency and privacy options of Google Chrome. One area where we’ve seen a lot of interest and questions is the RLZ library that is built into Google Chrome. RLZ gives us the ability to accurately measure the success of marketing promotions and distribution partnerships in order to meet our contractual and financial obligations. It assigns non-unique, non-personally identifiable promotion tracking labels to client products; these labels sometimes appear in Google search queries in Google Chrome.

 

Documenting Google Chrome’s use of promotional tags and tokens was a good start, but we wanted to take this transparency a step further. Our goal was to not only show you exactly how we were sending distribution information, but also what information was included and how it was generated.

 

 

The Google Chrome Dev channel has been updated to 5.0.356.2 for all platforms since our last developer post. It includes a few new goodies for developers:

• Geolocation API: Run with the --enable-geolocation flag.
• Incognito extensions
• Unpacked extensions are now remembered across browser restarts.
• Favicons for extension pages (define with a 16x16 image in your manifest.json).
• setPopup() was added to browserAction and pageAction for dynamically changing which popup to show based on the selected tab.

Please keep in mind that these features are still under development and are not 100% stable yet. In addition to the above, there are a few new experimental features baking in /trunk. You can try them out with the --enable-experimental-extension-apis flag:

• chrome.experimental.infobars
• chrome.experimental.contextMenu

 

We’ve added a few new sample extensions tutorials to get you started:

• Sample and tutorial to demonstrate using Google Analytics in your extensions
• Extension to display, create, and update your Google Documents
• Tutorial to demonstrate using OAuth in your extensions

At the end of 2009, we traveled around the world — to the Czech Republic, Russia, and Argentina — meeting with developers and talking to them about Google Chrome Extensions and HTML5.

 

In the first leg of our trip, we headed to Europe for Google Developer Day Prague and Google Developer Day Moscow on November 6th and 10th. Google Developer Days are one-day events featuring seminars and office hours about Google developer products like Android, Google App Engine, and of course Google Chrome! More than 800 developers were on hand in Prague and more than 1,500 in Moscow to learn, among lots of other things, how to develop extensions for Google Chrome. Below is video of the talk Brian gave about extensions in Moscow. You can also watch video of this talk translated into Russian or video of a similar talk from Prague and view slides from Prague or slides from Moscow.

 

 

 

In designing Chromium, we've been working hard to make the browser as secure as possible. We've made strong improvements with the integrated sandboxing and our up-to-date user base. We're always looking to stay on top of the latest browser security features. We've also worked closely with the broader security community to get independent scrutiny and to quickly fix bugs that have been reported.

 

Some of the most interesting security bugs we've fixed have been reported by researchers external to the Chromium project. For example, this same origin policy bypass from Isaac Dawson or this v8 engine bug found by the Mozilla Security Team. Thanks to the collaborative efforts of these people and others, Chromium security is stronger and our users are safer.

 

Today, we are introducing an experimental new incentive for external researchers to participate. We will be rewarding select interesting and original vulnerabilities reported to us by the security research community. For existing contributors to Chromium security — who would likely continue to contribute regardless — this may be seen as a token of our appreciation. In addition, we are hoping that the introduction of this program will encourage new individuals to participate in Chromium security. The more people involved in scrutinizing Chromium's code and behavior, the more secure our millions of users will be.

 

Such a concept is not new; we'd like to give serious kudos to the folks at Mozilla for their long-running and successful vulnerability reward program.

 

Any bug filed through the Chromium bug tracker (under the template "Security Bug") will qualify for consideration. As this is an experimental program, here are some guidelines in the form of questions and answers:

 

A) As per Mozilla, our base reward for eligible bugs is $500. If the panel finds a particular bug particularly severe or particularly clever, we envisage rewards of $1337. The panel may also decide a single report actually constitutes multiple bugs. As a consumer of the Chromium open source project, Google will be sponsoring the rewards.