Chromium Blog: googlechrome

A Mini-Newsletter From Your Google Chrome Security Team

Tuesday, March 8, 2011

We’re always working hard to enhance the Chrome browser with bug fixes, new defenses and new features. The

9.0.597.107 release notes that our our job posting?
Posted by Chris Evans, Google Chrome Security Team, Bernhard Bauer, Software Engineer, and Carlos Pizano, Software Engineer

Chrome@GDC2011

Wednesday, February 9, 2011

Games are some of the most popular apps on the web platform. Representatives from the Chrome team will be at the Game Developers Conference, to connect with game developers and deliver tech talks on some of the latest web technologies.
On February 28th, as part of Google Developer Day at GDC, Vincent Scheib will present an overview of how the latest HTML5 technologies can be used to create games. On the same day, Gregg Tavares will explain how to get GPU-accelerated graphics with WebGL, and Bill Budge will show how you can program Web games in C++ using Native Client. For a full list of other Google talks check out google.com/gdc2011.
We will also be present at Google’s booth on the GDC expo floor. Representatives from our 3D Graphics, Native Client, HTML5 and Chrome Web Store teams will be there to answer your questions on how you can use web technologies to create compelling games for Chrome’s 120+ million active users.
We can’t wait to see you there!Posted by Ian Lewis, Developer Advocate

Chromium to Feature in Pwn2Own Contest!

Monday, February 7, 2011

We’re excited that the Google Chrome browser will Chromium Security Reward program. Sponsoring this contest to discover more bugs was a logical step. We thought we’d answer some frequently asked questions in the form of a Q&A session:
Q) Is Chrome OS a target?A) No, not this year, as Chrome OS is still in beta. Per HP TippingPoint / ZDI guidelines, the actual target will be the latest stable version of the Chrome browser at the time, running on an up-to-date Windows 7 system. A Chrome OS device will, however, be awarded in addition to the prize money.
Q) Are you betting that Chrome can’t be hacked?A) No. We think the Chrome browser has a strong security architecture, and Chrome has fared well in past years at Pwn2Own. But we know that web browsers from all vendors are very large pieces of software that invariably do have some bugs and complex external dependencies. That’s why the Chromium Security Reward program exists, along with our newer The program still pays up to $3,133.7 per bug. As always, submissions to the program don’t require exploits in order to be rewarded. In addition, we continue to reward classes of bugs (such as cross-origin leaks) that would otherwise not be eligible for prizes at Pwn2Own. We encourage researchers to continue submitting their bugs through the Chromium Security Reward program.
Posted by Chris Evans, Google Chrome Security Team

Do You Know How Slow Your Web Page Is?

Wednesday, July 28, 2010

The 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 <script> block at the top of the document).
Unfortunately, that is too late to include a significant portion of the time web surfers spend waiting for the page: much of the time is spent fetching the page from the web server. To address this shortcoming, some clever web developers work around the problem by storing the navigation start time in a cookie during the previous page’s onbeforeunload handler. However, this doesn’t work for the critical first page load which likely has a cold cache.
Web Timing now gives developers the ability to measure the true page load time by including the time to request, generate, and receive the HTML document. The timeline below illustrates the metrics it provides. The vertical line labeled "Legacy navigation started" is the earliest time a web page can reliably measure without Web Timing. In this case, instead of a misleading 80ms load time, it is now possible to see that the user actually experienced a 274ms time. Including this missing phase will make your measurements appear to increase. It’s not because pages are getting slower – we’re just getting a better view on where the time is actually being spent.
work is underway to add window.mozPerformance to Firefox. The specification is still being finalized, so expect slight changes before the browser prefixes are dropped. If you’re running a supported browser, please try the Web Timing demonstration and send us feedback.
Posted by Tony Gentilcore, Software Engineer

Release Early, Release Often

Thursday, July 22, 2010

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!
Posted by Anthony Laforge, Program Manager

Celebrating Six Months of Chromium Security Rewards

Tuesday, July 20, 2010

It has been approximately six months since we launched the 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!

UPDATE: We've had a few questions about whether we pay rewards in cases where the bug comes to us via a vulnerability broker. Bugs reported in this way are not likely to generate Chromium rewards. We encourage researchers to file bugs directly with us, as doing so helps us get started sooner on fixes and removes questions about who else may have access to the bug details. We'd also remind researchers that we don't necessarily require a working exploit in order to issue a reward. For example, evidence of memory corruption would typically be sufficient.

Posted by Chris Evans, Google Chrome Security

Google Chrome Developer Update - Google I/O recap, new APIs

Monday, June 7, 2010

Google I/O recap
If you missed the Google Font API, which allows you to add high-quality web fonts to any web page. Lastly, there were all of the great Beyond JavaScript: programming the web with native code

HTML5 status update

File API and --enable-nacl.

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 @ChromiumDev.
Posted by Eric Bidelman, Google Chrome Developer Relations

In The Open, For RLZ

Wednesday, June 2, 2010

When we project on the Google Code site, since this is the same library that is used in other Google products. This is analogous to how we opened Omaha, the Google Updater technology, as its own open-source project.
Chromium will also continue to exist as it always has, without any RLZ library included. And, you can still download a Google Chrome with no RLZ behavior at www.google.com/chrome. But now that RLZ is open, Google Chrome distributed through promotional means will include this open-source implementation of RLZ.
It is our hope that we are not only opening up a previously-closed part of Google Chrome and providing better transparency, but that we’re also offering up potentially useful code to others who may use it in their own projects.
We know this is just a small step, but we think that the RLZ project will provide better transparency and value to the community. We want to hear what you think, so please keep the feedback coming!
Posted by Roger Tawa, Software Engineer, and Glenn Wilson, Product Manager

Google Chrome Developer Update - Geolocation and Incognito Extensions

Friday, March 26, 2010

What's New in Google Chrome?
The Google Chrome Dev channel has been updated to Favicons for extension pages (define with a 16x16 image in your manifest.json).

Sample and @ChromiumDev!

Posted by Eric Bidelman, Developer Advocate

Extending Google Chrome 25,621 Miles

Thursday, February 4, 2010

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 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 slides from Moscow.

Encouraging More Chromium Security Research

Thursday, January 28, 2010

In designing Chromium, we've been working hard to make the browser as secure as possible. We've made strong improvements with the this same origin policy bypass from Isaac Dawson or High and Critical impact bugs, but any clever vulnerability at any severity might get a reward. Obviously, your bug won't be eligible if you worked on the code or review in the area in question.
Q) How do I find out my bug was eligible?A) You will see a provisional comment to that effect in the bug entry once we have triaged the bug.
Q) What if someone else also found the same bug?A) Only the first report of a given issue that we were previously unaware of is eligible. In the event of a duplicate submission, the earliest filed bug report in the bug tracker is considered the first report.
Q) What about bugs present in Google Chrome but not the Chromium open source project?A) Bugs in either build may be eligible. In addition, bugs in plugins that are part of the Chromium project and shipped with Google Chrome by default (e.g. Google Gears) may be eligible. Bugs in third-party plugins and extensions are ineligible.
Q) Will bugs disclosed publicly without giving Chromium developers an opportunity to fix them first still qualify?A) We encourage responsible disclosure. Note that we believe responsible disclosure is a two-way street; it's our job to fix serious bugs within a reasonable time frame.
Q) Do I still qualify if I disclose the problem publicly once fixed?A) Yes, absolutely. We encourage open collaboration. We will also make sure to credit you in the relevant Google Chrome release notes and nominate you for the we have open positions.
Posted by Chris Evans, Google Chrome Security

Google Chrome for Linux goes beta!

Tuesday, December 8, 2009

simplethanks to Ibrar and Paweł for our FTP stacklet us know what you thinkPosted by Dan Kegel and Evan Martin, Software Engineers

Chromium Blog