googlechrome
Do You Know How Slow Your Web Page Is?
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).
Release Early, Release Often
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!
Celebrating Six Months of Chromium Security Rewards
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:
- 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.
- 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!
Google Chrome Developer Update - Google I/O recap, new APIs
Google I/O recap
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:
What's new for developers in Google Chrome?
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:
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.
In The Open, For RLZ
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.
Turn Google Chrome's search bar into a powerful Quix command line
I'm a big fan of Quix, the handy scriptable bookmarklet that works like a command line from your browser.
Wouldn't it be cool if you could use the search bar as a command line, though, instead of triggering a Quix window? If you use Google Chrome, you can. This neat little hack requires setting up Quix as the default search engine, which will require copy-pasting a little bit of code.
To get Chrome to recognize Quix as a search engine, grab the code from this intrepid coder's blog and follow the detailed instructions there. It actually doesn't take long to set up, and anybody who's savvy enough to use Quix can probably manage it. If you're worried that using Quix as your default search will make Googling tougher, don't sweat it too much: simply putting a g in front of your search is the default Quix command for Google.
[via Lifehacker]
Instachrome adds Instapaper support to Google Chrome
Instapaper is the creme-de-la-creme of web clipping services, and now it's got its own Chrome extension. Instachrome gives Chrome users a quick way to save and read articles, right from the menubar. You can also use it to view a webpage in Instapaper's highly-readable text view.
Instachrome has two modes: one is a basic click-to-save button, and the other is a full pop-up menu with several Instapaper options. You can switch between the two in the extension's options menu. Instachrome is free, but you'll need an Instapaper account to use it. Fortunately, Instapaper accounts are free, too.
[via Lifehacker]
Google Chrome Developer Update - Geolocation and Incognito Extensions
What's New in Google Chrome?
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:
Samples and Tutorials
We’ve added a few new sample extensions tutorials to get you started:
Extending Google Chrome 25,621 Miles
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.
Encouraging More Chromium Security Research
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:
Q) What reward might I get?
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.
Drive co-workers mental with the Farty extension for Google Chrome!
There are plenty of apps for my iPod Touch that I'd like to be able to run on my desktop. You know what's tops on the list? A fart app!
No, not really. In fact, I can't imagine anyone bothering to create something like that -- but as we've seen with just about every other app store or extension repository, if an app is extensible, someone's going to code a fart add-on for it.
Google Chrome users can now get in on the fun(?) with Farty! Install the extension, wait five minutes, and your computer will let one rip. Oh, the hilarity!
Wait a minute...Actually, since it doesn't install a toolbar button this could be just thing to drive your Chrome-surfing co-workers insane. Sadly, it does cause a pop-up window to appear, but it's still a decent one-time gag.