With Chrome 10, our first cut of the previously announced Flash sandboxing initiative is now enabled by default for the Windows platform on Vista and newer. Additionally, because we automatically update Flash to the latest and most secure version, this should provide useful defense in depth.
Chrome 10: Out-of-date plug-in warnings
As we previously mentioned, we believe that some of the most significant opportunities to increase user security revolve around plugins. We’ve made a number of improvements in this area, including actively encouraging users to update their plug-ins to the most secure version. Chrome now detects when a plug-in is out of date and blocks it with a simple infobar. This infobar helps guide the user towards updating their plug-in with the latest security fixes.
Chrome 10: Plug-in blocking enhancements
Some of our more advanced users prefer fine-grained control over which plug-ins they wish to run -- which can have security and privacy benefits. Chrome has long had a feature which blocks plug-ins by default (Wrench menu -> Preferences -> Under the hood -> Content Settings -> Plug-ins). We’ve improved this feature by adding a context menu to the blocked plug-in placeholder. This menu lets users control which plug-ins do and do not run. Using a context menu helps prevent clickjacking attacks that try to bypass the block. Plug-in placeholders can also be hidden (for example, if they are floating over and obscuring real content), and the actual plug-in that wishes to run is made apparent.
Chromium Security Rewards program still going strong
We mentioned in passing in the 9.0.597.107 release notes that our rewards program has passed $100,000 of rewards. We’d like to re-iterate our thanks to all the named researchers in our Hall of Fame. We’re continually delighted with the stream of interesting and clever bugs that we receive, so it will be exciting to see what the rest of 2011 brings. Remember, we love giving out money!
Still hiring!
We are always looking to expand the Google Chrome Security Team, and we’re looking for a wide range of talents. We can promise exciting and varied work, working to protect hundreds of millions of users and working alongside the best in the industry. Why not have a look at our job posting?
Posted by Chris Evans, Google Chrome Security Team, Bernhard Bauer, Software Engineer, and Carlos Pizano, Software Engineer
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.
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 web application reward program. As a team comprised largely of security researchers, we think it’s important to reward the security community for their work which helps us learn. Naturally, we’ll learn the most from real examples of Chrome exploits.
Q) How do the rules work?
A) We worked with ZDI to come up with a rules structure that would reward exploits in code specific to Chromium and in third-party components such as the kernel or device drivers.
Of course, we prefer to pay rewards for bugs in our own code because we learn more and can make fixes directly. On day 1 of the competition, Google will sponsor $20,000 for a working exploit in Chrome, if it uses only Chrome bugs to compromise the browser and escape the sandbox. Days 2 and 3 will also allow for bugs in the kernel, device drivers, system libraries, etc., and the $20,000 prize will be sponsored at $10,000 by Google and $10,000 by ZDI to reflect the occurrence of the exploit partially outside of the Chrome code itself.
Note that ZDI is responsible for the rules and may change them at their own discretion.
Q) Does this competition impact the Chromium Security Reward program?
A) 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
Measuring web page load time is a notoriously tricky but importantendeavor. 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.
Across other browsers: Web Timing metrics are under window.msPerformance in the third platform preview of Internet Explorer 9 and 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.
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!
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!
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.
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:
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.
Upcoming developer events
For those of you based in New York, there’s an upcoming Chrome Extensions hackathon in our local office on June 10, 2010. We also have a five day DevFest starting June 28, 2010 in Sydney, Australia. Google Chrome will be featured on Wednesday, June 30. Stay tuned for more details!
For the latest news and upcoming developer events, subscribe to this blog and follow us on Twitter @ChromiumDev.
Posted by Eric Bidelman, Google Chrome Developer Relations
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.
Today, we’ve open-sourced the code that generates the RLZ parameter that sometimes appears in Google search queries. We’ve made the RLZ library its own 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
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:
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:
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.
Our next and last stop was Buenos Aires for Google DevFest Argentina. Google DevFests are more focused versions of Google Developer Days. On November 17th, another 800 or so developers attended this event. There, we covered the Google Chrome platform in a couple sessions — on HTML5 and extensions. Below are slides from the talk Mihai gave on HTML5. You can also view slides from the extension talk.
For us, the best part of being at these events was seeing and hearing about all the interest in Google Chrome from developers everywhere and all the cool things those developers are building with the browser. If you'd like to get involved too, there are a bunch of community-organized Google Chrome events going on now. Check out the Google Technology User Group site to find a group or Meetup to find an event near you. And if there isn't a nearby group or event already, why not create your own! We have a collection of hackathon-in-a-box resources to help you do so.
Posted by Brian Kennish and Mihai Ionescu, Developer Advocates
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 valid security 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.
Q) What bugs are eligible?
A) Any security bug may be considered. We will typically focus on 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 Google Security "thank you" section.
Q) What about bugs in channels other than Stable?
A) We are interested in bugs in the Stable, Beta and Dev channels. It's best for everyone to find and fix bugs before they are released to the Stable channel.
Q) What about bugs in third-party components?
A) These bugs may be eligible (e.g. WebKit, libxml, image libraries, compression libraries, etc). Bugs will be ineligible if they are part of the base operating system as opposed to part of the Chromium source tree. In the event of bugs in a component shared with other software, we are happy to take care of responsibly notifying other affected parties.
Q) Who determines whether a given bug is eligible?
A) The panel includes Adam Barth, Chris Evans, Neel Mehta, SkyLined and Michal Zalewski.
Q) Can you keep my identity confidential from the rest of the world?
A) Yes. If selected as the recipient of a reward, and you accept, we will need your contact details in order to pay you. However — at your discretion, we can credit the bug to "anonymous" and leave the bug entry private.
Q) No doubt you wanted to make some legal points?
A) Sure. We encourage participation from everyone. However, we are unable to issue rewards to residents of countries where the US has imposed the highest levels of export restriction (e.g. Cuba, Iran, North Korea, Sudan and Syria). We cannot issue rewards to minors, but would be happy to have an adult represent you. This is not a competition, but rather an ongoing reward program. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon local law.
We look forward very much to issuing our first reward and featuring it on our releases blog. We're happy to take questions at [email protected]. Alternatively, feel free to leave a comment. We will update this blog post with answers to any popular questions.
Finally, if you're interested in helping out Chromium security on a more permanent basis, we have open positions.
