Chromium Blog
News and developments from the open source browser project
UA String Changes Coming In Chrome 11
Thursday, March 31, 2011
When websites want to know what browser you're using, they often examine the "user agent", or "UA" string. This is a string that provides information about what browser and operating system you're using. Beginning with Chrome 11, we're making some changes to our UA string, which can affect website compatibility.
For reference, here is what the current (Chrome 10) UA string looks like on a few different platforms:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
And in comparison, here are the UA strings for Chrome 11 on the same platforms:
Mozilla/5.0 (Windows NT 6.0; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.16 Safari/534.24
Let's break down the differences in detail. We've made four changes, two of which are Windows-specific:
On Windows, the initial "
Windows
;
" platform identifier has been removed. This was redundant with the subsequent OS version identifier, and makes us more compatible with Internet Explorer, whose UA string doesn't have this initial token.
The "
U
" SSL encryption strength token has been removed. This token dates from more than a decade ago, when U.S. export laws limited the encryption strength that could be built into software shipped to various other countries; the valid values are "
U
" (for "USA" 128-bit encryption support), "
I
" (for "International" 40-bit encryption support), and "
N
" (for "None", no encryption support). These days, every browser ships with 128-bit SSL support everywhere, so it's not necessary to advertise it.
On 64-bit versions of Windows, tokens have been added after the OS version. For 32-bit Chrome builds running on 64-bit Windows, we've added "
WOW64
". (
WOW64
" stands for "Windows 32-bit On Windows 64-bit" and is the name Microsoft gives its 32-bit compatibility subsystem.) In our source code, we've also added identifiers for 64-bit native builds, specifically "
Win64
; x64
" for x64-based processors and "
Win64; IA64
" for Itanium systems. (However, we don't currently ship such builds, or have any immediate plans to.) These tokens are useful for sites that need to provide download links for native executables, and match what Internet Explorer uses.
The locale has been removed. Web authors who want to know what languages a browser supports should use the HTTP
Accept-Language
header instead, which can supply multiple locales. In fact, websites that relied on the UA string locale probably had some very unhappy visitors, because Chrome always had a bug where the UA string locale was reported as "
en-US
", regardless of the user's desired locale(s)!
One more question remains: why are we making these changes now? Because websites tend to use common pieces of code to check all browsers' UA strings, it's important for browsers to stay in sync with each other. Mozilla has made the above changes in Firefox 4 (and more; see
http://hacks.mozilla.org/2010/09/final-user-agent-string-for-firefox-4/
for details), which was released recently, and we wanted to change Chrome to match as soon as possible, to minimize the disruption to web authors.
As the changes above have trickled into our Canary and Dev builds, we've already found and fixed some problems in Google's UA string parsing libraries that have caused compatibility issues with Google sites (though not all of the affected sites have updated yet). If you see problems on other sites you think might be caused by the new UA string, try running Chrome with an alternate UA string using the
--user-agent="<Put older UA string here>"
command line flag. (You can double-check the UA string Chrome sends to websites by typing
about:
in your address bar and hitting <enter>.) If that fixes the problem, please let us know by filing a bug in our bug tracker at
http://crbug.com/
.
Posted by Peter Kasting, Software Engineer
Getting smoother animated web content while reducing CPU usage
Tuesday, March 29, 2011
The web is becoming more interactive and animated day by day. Many web pages use the
Canvas
element to draw rich 2D content via the
2D context
or modify DOM elements on the fly. These pages generally use the
setTimeout
or
setInterval
APIs to receive frequent callbacks, allowing them to redraw their content periodically, or use DHTML to move elements on the page. As 3D content drawn using the
WebGL API
increases in popularity, it will use similar animation techniques.
Unfortunately, setTimeout and setInterval don’t take into consideration whether the destination element, or even the tab that contains it, is actually visible. So, pages with high-frequency timers will consume CPU resources even if the tab is in the background. On laptops, netbooks, and mobile devices of all kinds, reducing CPU consumption is essential in order to prolong battery life. Additionally, excess CPU consumption by background tabs reduces the smoothness of animations on the foreground tab.
Excessive CPU consumption by timers on web pages is not a theoretical problem. We have measured web sites containing mostly static text content firing timers at a rate of over two hundred per second.
Mozilla recently introduced the experimental
mozRequestAnimationFrame API
, which has different semantics than setTimeout or setInterval. Instead of the developer specifying a target frame rate, the browser runs the given callback when it is ready to produce the next animated frame. The callbacks are specifically known to be relevant to the animation of the page, and don’t run too often.
An experimental webkitRequestAnimationFrame API has been upstreamed to WebKit, and is available starting in Chrome 10. This is essentially the same as mozRequestAnimationFrame, but supports an optional second argument which is the element that the callback intends to animate. This additional information will allow the browser to avoid animating elements that are not visible to the user. See this
bug report
for more details. Chrome doesn’t run requestAnimationFrame callbacks for background tabs at all, which dramatically reduces CPU consumption when multiple tabs containing animated content are in the same window.
The
WebGL samples
project contains a three dimensional graphics library that has been modified to use requestAnimationFrame rather than setTimeout or setInterval. Take a look at this library for a good example of how to convert existing timeout based animations to the new style, while preserving compatibility with browsers that don’t support requestAnimationFrame.
In the forthcoming Chrome 11 release, we plan to reduce CPU consumption even for pages that are using setTimeout and setInterval. For background tabs, we intend to run each independent timer no more than once per second. This change has already been implemented in the Chrome dev channel and canary builds. While there may be some compatibility impact for web pages, we believe that improving the user experience for the foreground tab, and increasing battery life, are problems needing to be addressed. Please
send us your comments
on this planned change.
Posted by Kenneth Russell, Software Engineer
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
release of Chrome 10
is no different, and there are some items worth highlighting:
Chrome 10: Flash sandboxing
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
GPU acceleration old drivers = :(
Tuesday, March 1, 2011
Over the last few months, we’ve made a lot of progress using graphics hardware (commonly referred to as the GPU) to make Chrome faster and more power-efficient. However, as we’ve rolled out features like WebGL and GPU-accelerated HTML5 video, we noticed a troubling trend: users with old graphics drivers experienced a significant increase in crashes when using these features. Because stability is one of Google Chrome’s core principles, we’ve recently become stricter about requiring up-to-date drivers and graphics hardware by adding ranges of old drivers to Google Chrome’s software rendering list.
Developers should continue to ensure that the software-rendered version of their sites work properly for users without GPU-accelerated browsers, so we expect most content to continue to function normally for Google Chrome users with out-of-date drivers -- albeit, without the same performance you might expect from Chrome. WebGL content on out-of-date systems will currently not display, but we are working to provide a software path so that these systems can run basic 3D applications.
As our ability to determine whether a machine can reliably use GPU features improves, we hope to extend hardware acceleration support to more and more users. Here are some steps you can take to maximize the chances that Chrome will run fully hardware-accelerated on your computer:
Use the latest major version of your operating system (such as Windows 7 or Mac OS 10.6)
Install
all system updates and driver updates
that are available for your system.
Posted by Henry Bridge, Product Manager
Chrome Developer Tools: Back to Basics
Thursday, February 24, 2011
It’s been an exciting past few months in the
Google Chrome Developer Tools
world as we keep adding new features, while polishing up existing ones to respond to your feedback.
One of the areas we have focused a lot of our energy is on network instrumentation. Recently we’ve made many improvements that will hopefully improve your experience when using Chrome Developer Tools. These improvements include:
Network aspects of your web page are now inspected in the
Network panel
. This gives you access to even more information at a single glance. You can sort and clear data, preserve log information upon navigation and even export network data into
HAR
format.
All the timing information about your resource loads now comes from the network stack, not WebKit, so timing information now adequately represents raw network timing. You can see detailed timing for different phases of the loading by hovering over the log entry.
We now push raw HTTP headers and status messages into Chrome Developer Tools. As a result, you now see precisely what the browser received from the server and not just how the rendering engine interpreted that information.
Similarly to the old Resources panel, you can see syntax-highlighted resource contents.
We’ve also made CSS editing a whole lot easier. In particular, you’ll now find separate fields for property names and values instead of a single field for both. As you type, you will see suggestions of available keywords for property values.
But that’s only the tip of the iceberg. Similar to the changes in the network panel, the
CSS sidebar
now shows the raw information that the browser gets from the server - not the rendering engine’s interpretation of the information. As a result, you can use Chrome Developer Tools to see CSS properties that are not recognized by WebKit (e.g., engine-specific or simply erroneous properties). This finally puts an end to the nightmare of disappearing invalid properties.
For a more complete reference on working with the Chrome Developer Tools, check out our new
home page
. The CSS improvements that we implemented upstream in WebKit are further described in our
WebKit blog post
. And for even more tips on how to use Chrome Developer Tools, watch the new video below.
Posted by Pavel Feldman and Alexander Pavlov, Software Engineers
Amping Up Chrome’s Background Feature
Wednesday, February 23, 2011
Many users rely on apps to provide timely notifications for things like calendar events and incoming chat messages, but find it cumbersome to always keep a Chrome window open. Extensions and packaged apps can already display notifications and maintain state without any visible windows, using
background pages
. This functionality is now available to hosted apps - the most common form of apps in the
Chrome Web Store
- via a new background window mechanism.
Apps and extensions that use the new “background” feature can continue to run in the background—even if the user closes down all of Chrome’s windows. “Background apps” will continue to run until Chrome exits. The next time Chrome starts up, any background windows that were previously running will also be re-launched. These windows are not going to be visible but they will be able to perform tasks like checking for server-side changes and pre-emptively loading content into local storage.
One way you can use background windows is to preload content and data so that they are immediately available when the user opens your app. You could also issue HTML5 notifications to alert the user when important events occur—for example, a friend wants to initiate a chat session. There are plenty of possibilities here, and we look forward to seeing what you’ll do.
To protect our users’ privacy, we’ve made this functionality available only to apps and extensions; regular websites will not be able to open background windows. Developers will also need to declare the “background” capability on their apps.
Users can easily see which background apps (and extensions) are running in their system through the “Background Apps” menu of the Chrome icon in the system tray (Windows/Linux) or dock (Mac). Chrome will automatically load background components when the user logs in, and the Chrome icon will remain in the system tray or dock as long as background apps are running- even if all Chrome windows are closed. To close all background components, a user just needs to exit Chrome.
The feature is already available in Chrome’s Dev channel. For details on the API, check out our
developer’s guide
, which also includes sample apps to try out.
Posted by Andrew Wilson, Software Engineer and Michael Mahemoff, Developer Relations
Extending the Omnibox
Tuesday, February 22, 2011
One of the most powerful aspects of Google Chrome is the omnibox, also known as the address bar. You can type URLs and searches into one unified place and it all just works. With the new
omnibox API
, extension developers can make the omnibox even more powerful.
The omnibox API lets extension developers add their own keyword command to the omnibox. When the user types a query prefixed by this keyword, the extension can suggest potential completions and react to the user's input.
For example,
this extension
lets you search and switch between your open tabs from the omnibox:
Keep an eye out for cool new extensions as developers get their hands on this API!
Posted by Matt Perry, Software Engineer
Native Client: Getting Ready for Takeoff
Friday, February 18, 2011
Over the last few months we have been hard at work getting
Native Client
ready to support the new
Pepper
plug-in interface. Native Client is an open source technology that allows you to build web applications that seamlessly and safely execute native compiled code inside the browser. Today, we’ve reached an important milestone in our efforts to make Native Client modules as portable and secure as JavaScript, by making available a first release of the revamped
Native Client SDK
.
The SDK now includes support for a comprehensive set of Pepper interfaces for compute, audio, and 2D Native Client modules. These interfaces are close to being stable, with some important exceptions that are listed in the
release notes
.
In addition, we’ve focused on improving security. We have enabled auto-update and an outer sandbox. This allowed us to remove the
expiration date
and localhost security restrictions we had adopted in previous research-focused releases. Beyond security, we’ve also improved the mechanism for fetching Native Client modules based on the instruction set architecture of the target machine, so developers don’t need to worry about this any more.
We are excited to see Native Client progressively evolve into a developer-ready technology. In the coming months we will be adding APIs for 3D graphics, local file storage, WebSockets, peer-to-peer networking, and more. We’ll also be working on Dynamic Shared Objects (DSOs), a feature that will eventually allow us to provide Application Binary Interface (ABI) stability.
Until the ABI becomes stable, Native Client will remain off by default. However, given the progress we’ve made, you can now sticky-enable Native Client in Chrome 10 through the about:flags dialog. Otherwise, you can continue using a command line flag to enable Native Client when you want to.
A big goal of this release is to enable developers to start building Native Client modules for Chrome applications. Please watch this blog for updates and use our
discussion group
for questions, feedback, and to engage with the Native Client community.
Posted by Christian Stefansen, Product Manager
Chrome Web Store International Support: Developer Preview
Thursday, February 17, 2011
When we
recently announced
the availability of the Chrome Web Store to Chrome users in the US, we mentioned that we were hard at work making the store available globally. Today we’re excited to announce a preview release of the upload flow for several international markets as a step towards that goal.
Starting today, when you upload an app via the
developer dashboard
, you’ll have the option of selecting from the following sixteen countries to list your app: Argentina, Australia, Brazil, Canada, France, Germany, India, Italy, Japan, Mexico, Netherlands, Poland, Portugal, Spain, United Kingdom and the United States. If you are using
Chrome Web Store Payments
to charge for your app, you will also be able to set the app price for each country although if you’re not based in the United States you will not be able to complete your merchant account sign up just yet (this will be enabled soon).
Note that these apps will not yet be published to countries outside the United States. This will happen when the Chrome Web Store opens to consumers in these countries later this year. We are releasing this developer preview ahead of the consumer release so you have enough time to prepare your apps for international users.
We hope you can use this release to get familiar with the app upload process and take time to
localize your app listing
to make it accessible to more people. If you have additional questions, please take a look at
our FAQ
or join our
developer discussion group
.
Posted by Qian Huang, 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
feature in this year’s Pwn2Own contest
. Chrome wasn’t originally going to be included as a target browser in the competition, but Google volunteered to sponsor Chrome’s participation by contributing monetary rewards for Chrome exploits. For the past year we’ve enjoyed
working with the security community
and
rewarding researchers
for high quality work through our
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
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
Cloud printing on the go
Monday, January 24, 2011
Last month, we
opened Google Cloud Print
to users in the Chrome notebook pilot program.
Google Cloud Print
allows printing from any app on any device, OS or browser without the need to install drivers. Today, we are very pleased to announce the beta launch of Google Cloud Print for mobile documents and Gmail for mobile, which we will be rolling out to users throughout the next few days. To read more about how to use Google Cloud Print for these mobile use cases, read more in the
Google Mobile blog
.
Posted by Tyler Odean, Product Manager
More about the Chrome HTML Video Codec Change
Friday, January 14, 2011
There has been a lot of discussion regarding this week’s
announcement
of upcoming changes to HTML video codec support in Chrome. The future of web video is an important topic, we welcome the debate, and want to address some of the questions raised.
Why is Google supporting WebM for the HTML
<video>
tag?
This week’s announcement was solely related to the HTML
<video>
tag, which is part of the emerging set of standards commonly referred to as “HTML5.” We believe there is great promise in the
<video>
tag and want to see it succeed. As it stands, the organizations involved in defining the HTML video standard are at an impasse. There is no agreement on which video codec should be the baseline standard. Firefox and Opera support the open WebM and Ogg Theora codecs and will not support H.264 due to its licensing requirements; Safari and IE9 support H.264. With this status quo, all publishers and developers using the
<video>
tag will be forced to support multiple formats.
This is not an ideal situation and we want to see a viable baseline codec that all browsers can support. It is clear that there will not be agreement to specify H.264 as the baseline codec in the HTML video standard due to its licensing requirements. Furthermore, we genuinely believe that core web technologies need to be open and community developed to enable the same great innovation that has brought the web to where it is today. These facts led us to join the efforts of the web community and invest in an open alternative, WebM.
Why didn’t you select H.264 as the baseline codec for the HTML
<video>
tag in Chrome?
We acknowledge that H.264 has broader support in the publisher, developer, and hardware community today (though
support
across the ecosystem for WebM is growing rapidly). However, as stated above, there will not be agreement to make it the baseline in the HTML video standard due to its licensing requirements. To use and distribute H.264, browser and OS vendors, hardware manufacturers, and publishers who charge for content must pay significant royalties—with no guarantee the fees won’t increase in the future. To companies like Google, the license fees may not be material, but to the next great video startup and those in emerging markets these fees stifle innovation.
But it's not just the license fees; an even more important consideration is the pace of innovation and what incentives drive development. No community development process is perfect, but it’s generally the case that the community-driven development of the core web platform components is done with user experience, security and performance in mind. When technology decisions are clouded by conflicting incentives to collect patent royalties, the priorities and outcome are less clear and the process tends to take a lot longer. This is not good for the long term health of web video. We believe the web will suffer if there isn't a truly open, rapidly evolving, community developed alternative and have made significant investments to ensure there is one.
Does this mean I will no longer be able to play H.264 videos in Chrome?
H.264 plays an important role in video and the vast majority of the H.264 videos on the web today are viewed in plug-ins such as Flash and Silverlight. These plug-ins are and will continue to be supported in Chrome. Our announcement was only related to the
<video>
tag, which is part of the emerging HTML platform. While the HTML video platform offers great promise, few sites use it today and therefore few users will be immediately impacted by this change.
Isn’t this just an effort by Google to control the web video format?
WebM is backed by many in the web community. Google views its role like any other community member and has no desire or intent to control the WebM format. Our goal is to see the HTML
<video>
tag become a first-class video platform. As with many other web platform efforts, we expect the majority of organizations and individuals contributing to WebM won’t be affiliated with Google or any single entity.
Developers have already
created
high-quality alternative (yet compatible) implementations of WebM, and we think that kind of choice is great for everyone.
Won’t this decision force publishers to create multiple copies of their videos?
Some have expressed concern that our announcement will force publishers and developers to maintain multiple copies of their content when they otherwise would not have had to. Google is among the largest publishers of video content in the world, and as such we are sympathetic to this concern. Remember, Firefox and Opera have never supported H.264 due to its licensing requirements, they both support WebM and Ogg Theora. Therefore, unless publishers and developers using the HTML
<video>
tag don’t plan to support the large portion of the desktop and mobile web that use these browsers, they will have to support a format other than H.264 anyway (which is why we are working to establish a baseline codec for HTML video). More broadly, given the proliferation of devices, platforms, and connectivity types used to access the web, most content providers already produce multiple versions of their videos to optimize for these devices. We’re confident that the rapid evolution of HTML video and WebM over the coming year will make the combination a compelling solution for content providers and developers and the proliferation of WebM capable devices will make their investments highly leveraged.
Bottom line, we are at an impasse in the evolution of HTML video. Having no baseline codec in the HTML specification is far from ideal. This is why we're joining others in the community to invest in WebM and encouraging every browser vendor to adopt it for the emerging HTML video platform (the WebM Project team will soon release plugins that enable WebM support in Safari and IE9 via the HTML standard
<video>
tag). Our choice was to make a decision today and invest in open technology to move the platform forward, or to accept the status quo of a fragmented platform where the pace of innovation may be clouded by the interests of those collecting royalties. Seen in this light, we are choosing to bet on the open web and are confident this decision will spur innovation that benefits users and the industry.
Posted by Mike Jazayeri, Product Manager
Updated: Clarified that the Safari and IE9 plug-ins to be released by the WebM Project Team enable WebM playback via the HTML standard
<video>
tag canPlayType interface and not an alternate non-standard method.
HTML Video Codec Support in Chrome
Tuesday, January 11, 2011
The web’s open and community-driven development model is a key factor in its rapid evolution and ubiquitous adoption. The
WebM Project
was
launched
last year to bring an open, world-class video codec to the web. Since the launch, we’ve seen first-hand the benefits of an open development model:
Rapid
performance improvements
in the video encoder and decoder thanks to contributions from dozens of developers across the community
Broad
adoption
by browser, tools, and
hardware vendors
Independent
(yet compatible) implementations that not only bring additional choice for users, publishers, and developers but also foster healthy competition and innovation
We expect even more rapid innovation in the web media platform in the coming year and are focusing our investments in those technologies that are developed and licensed based on open web principles. To that end, we are changing Chrome’s HTML5
<video>
support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.
These changes will occur in the next couple months but we are announcing them now to give content publishers and developers using HTML
<video>
an opportunity to make any necessary changes to their sites.
Posted by Mike Jazayeri, Product Manager
WebGL now in Beta: here comes the 3D web!
Thursday, December 16, 2010
We’re happy to announce that WebGL is now on by default in Google Chrome’s
beta channel
, with some
shiny new demos
to show off what the technology can do.
WebGL
is a 3D graphics API for JavaScript that developers can use to create
fully 3D web apps
. It is based on the
OpenGL ES 2.0 API
, which should be familiar to many 3D graphics developers. Google, Mozilla, Apple, Opera and graphics hardware vendors have been working together to standardize WebGL for over a year now, and since the
spec
is just about final at this point, we wanted to get our implementation out there for feedback.
While you may not find much WebGL content on the web, we expect developers to quickly create a lot of content given the power and familiarity of the API. To inspire developers and give users a taste of the kind of apps they can expect in the near future, we’ve worked with a few talented teams to build a few more 3D web apps:
Body Browser
, a human anatomy explorer built by a team at Google as a 20% project
Nine Point Five
, a 3D earthquake map by Dean McNamee
Music Visualizer
, a jukebox that synchronizes 3D graphics to the beat of the music by Jacob Seidelin
You can find these and other demos in the new
Chrome Experiments Gallery for WebGL demos
. Now that WebGL is enabled in the
beta channel
, the Chrome Experiments team is looking for your cool WebGL app submissions to show off this slick technology, so don’t forget to
submit your cool 3D apps
!
Posted by Kenneth Russell, Software Engineer
Chrome is Ready for Business
Wednesday, December 15, 2010
Since we launched the
Chromium project
over
two years ago
, we’ve been hearing a lot of feedback from IT administrators who want to manage and configure Google Chrome. Of course, we were eager to do what we could to help them get Chrome deployed inside their organizations.
Today, after talking directly to administrators and testing the features extensively with other organizations, we believe the first set of features is ready for prime-time. Both Chrome and Chromium are now manageable through Group Policy objects on Windows, plist/MCX configuration on Mac, and special JSON configuration files on Linux. We polished up the
NTLM and Kerberos protocol
support, and created a
list of supported policies
and
administrative templates
to help administrators deploy. For users needing access to older web applications not yet qualified for Chrome, we also developed
Chrome Frame
, an Internet Explorer (TM) plug-in that provides Chrome-quality rendering for the broader Web, while defaulting to host rendering for any web applications that still require IE.
No feature is really useful to an administrator without great documentation, so we wrote
articles
to help admins in the configuration and deployment of both Google Chrome and Chromium. We also documented
answers to the top questions
testers encountered when deploying.
Even though the first set of features is done, we still have a lot more we’d like to do. We have some interesting ideas that we’re working on, including more policies to manage everything in the content settings and authentication protocols, and interesting new ways to deploy policy cross-platform. But we could use your help: please try out the new features by checking out the documentation,
downloading the MSI installer
, and
filing bugs
. And let your administrator know to give it a try and let us know what they think.
Posted by Glenn Wilson, Product Manager and Daniel Clifford, Software Engineer
Break on UI and network events in Chrome Developer Tools
Monday, December 13, 2010
Chrome Developer Tools
' Scripts panel provides a graphical JavaScript debugger and allows you to set breakpoints in the JavaScript source code. However, setting breakpoints in the source code does not always work well, especially when the application is large and you are not familiar with the entire code base. To better support this use case, we are introducing a new set of breakpoints that allow you to break on UI and network events.
Suppose you need to find the piece of code that modifies a specific node in a document. Right-click on that node in the Elements panel and select the appropriate “Break on...” context menu option and you are all set. The debugger will pause JavaScript execution right before the node gets modified next time.
To learn more about DOM breakpoints and other new kinds of breakpoints, visit our
Breakpoints Tutorial
page.
Posted by Pavel Podivilov, Software Engineer
A Year of Extensions
Thursday, December 9, 2010
It’s hard to believe, but it’s already been a full year since we launched the Google Chrome extensions gallery.
It’s been a busy twelve months:
The gallery has grown to over 8,500 extensions and 1,500 themes.
A third of Chrome users have at least one extension installed.
Over 70 million extensions and themes have been installed.
On the client side, we added features like:
New APIs for things like
context menus
,
history
, and
cookies
.
Integration between extensions and HTML5 features like
notifications
and
geolocation
.
Extension sync, so your favorite extensions are always with you.
Native support for Greasemonkey
user scripts
.
Looking forward, we’re very excited about the
Chrome Web Store
, where developers will be able to easily sell their apps, extensions, and themes.
And we’re not going to slow down on the features, either. The next Chrome release will add API support for the
omnibox
and
pinned tabs
. Beyond that, we’re hard at work on popular requests like
network interception
and download management APIs, as well as new experimental APIs for
sidebars
and development tools.
Thanks for all your support over the last year, from bug reports to testing new APIs. It’s been a bit frantic at times, but mostly it’s been fun.
Posted by Aaron Boodman, Software Engineer
A New Crankshaft for V8
Tuesday, December 7, 2010
Today we are introducing Crankshaft, a new compilation infrastructure for V8, Google Chrome’s JavaScript engine. By using aggressive optimizations, Crankshaft dramatically improves the performance of compute-intensive JavaScript applications - often by more than a factor of two! This will give users a faster and more responsive experience loading web pages and applications built with complex JavaScript. Here is a comparison of Chrome with and without Crankshaft on the
V8 benchmark suite
:
The benchmarks that benefit the most from Crankshaft are Richards, DeltaBlue and Crypto. This shows that we have taken the performance of JavaScript property accesses, arithmetic operations, tight loops, and function calls to the next level. Overall, Crankshaft boosts V8’s performance by 50% on the V8 benchmark suite. This is the biggest performance improvement since we launched Chrome in 2008.
In addition to improving peak performance as measured by the V8 benchmark suite, Crankshaft also improves the start-up time of web applications such as GMail. Our
page cycler
benchmarks show that Crankshaft improves the page load performance of Chrome by 12% for pages that contain significant amounts of JavaScript code.
Crankshaft uses adaptive compilation to improve both start-up time and peak performance. The idea is to heavily optimize code that is frequently executed and not waste time optimizing code that is not. Because of this, benchmarks that finish in just a few milliseconds, such as SunSpider, will show little improvement with Crankshaft. The more work an application does, the bigger the gains will be.
Crankshaft has four main components:
A
base compiler
which is used for all code initially. The base compiler generates code quickly without heavy optimizations. Compilation with the base compiler is twice as fast as with the V8 compiler in Chrome 9 and generates 30% less code.
A
runtime profiler
which monitors the running system and identifies hot code, i.e., code that we spend a significant amount of the time running.
An
optimizing compiler
which recompiles and optimizes hot code identified by the runtime profiler. It uses
static single assignment
form to perform optimizations such as
loop-invariant code motion
, linear-scan
register allocation
and
inlining
. The optimization decisions are based on type information collected while running the code produced by the base compiler.
Deoptimization support
which allows the optimizing compiler to be optimistic in the assumptions it makes when generating code. With deoptimization support, it is possible to bail out to the code generated by the base compiler if the assumptions in the optimized code turn out to be too optimistic.
V8 with Crankshaft for the 32-bit Intel architecture is available today in the V8
bleeding edge repository
and in
canary builds
of Chrome. Work on the ARM and 64-bit ports has started.
We are excited about the JavaScript speed improvements we are delivering with Crankshaft today. Crankshaft provides a great infrastructure for the next wave of JavaScript speed improvements in V8 and we will continue to push JavaScript performance to enable the next generation of web applications.
Kevin Millikin, Software Engineer and Florian Schneider, Software Engineer
Rolling out a sandbox for Adobe Flash Player
Wednesday, December 1, 2010
Since this past
March
, we’ve been working closely with Adobe to allow Flash Player to take advantage of new sandboxing technology in Chrome, extending the
work we’ve already done
with sandboxing for HTML rendering and JavaScript execution. This week, we’re excited to roll out the initial Flash Player sandbox for our dev channel users on Windows XP, Vista and 7.
This initial Flash Player sandbox is an important milestone in making Chrome even safer. In particular, users of Windows XP will see a major security benefit, as Chrome is currently the only browser on the XP platform that runs Flash Player in a sandbox. This first iteration of Chrome’s Flash Player sandbox for all Windows platforms uses a modified version of Chrome’s existing sandbox technology that protects certain sensitive resources from being accessed by malicious code, while allowing applications to use less sensitive ones. This implementation is a significant first step in further reducing the potential attack surface of the browser and protecting users against common malware.
While we’ve laid a tremendous amount of groundwork in this initial sandbox, there’s still more work to be done. We’re working to improve protection against additional attack vectors, and will be using this initial effort to provide fully sandboxed implementations of the Flash Player on all platforms.
We’ll be posting updates as we continue working with Adobe to add new security improvements to the Flash Player sandbox. For those of you on the dev channel for Windows, you’ll be automatically updated soon, and we look forward to your feedback as you test it out. If you prefer to disable this initial sandbox in your Chrome dev experience, add --disable-flash-sandbox to the command line.
Posted by Justin Schuh and Carlos Pizano, Software Engineers
Labels
$200K
1
10th birthday
4
abusive ads
1
abusive notifications
2
accessibility
3
ad blockers
1
ad blocking
2
advanced capabilities
1
android
2
anti abuse
1
anti-deception
1
background periodic sync
1
badging
1
benchmarks
1
beta
83
better ads standards
1
billing
1
birthday
4
blink
2
browser
2
browser interoperability
1
bundles
1
capabilities
6
capable web
1
cds
1
cds18
2
cds2018
1
chrome
35
chrome 81
1
chrome 83
2
chrome 84
2
chrome ads
1
chrome apps
5
Chrome dev
1
chrome dev summit
1
chrome dev summit 2018
1
chrome dev summit 2019
1
chrome developer
1
Chrome Developer Center
1
chrome developer summit
1
chrome devtools
1
Chrome extension
1
chrome extensions
3
Chrome Frame
1
Chrome lite
1
Chrome on Android
2
chrome on ios
1
Chrome on Mac
1
Chrome OS
1
chrome privacy
4
chrome releases
1
chrome security
10
chrome web store
32
chromedevtools
1
chromeframe
3
chromeos
4
chromeos.dev
1
chromium
9
cloud print
1
coalition
1
coalition for better ads
1
contact picker
1
content indexing
1
cookies
1
core web vitals
2
csrf
1
css
1
cumulative layout shift
1
custom tabs
1
dart
8
dashboard
1
Data Saver
3
Data saver desktop extension
1
day 2
1
deceptive installation
1
declarative net request api
1
design
2
developer dashboard
1
Developer Program Policy
2
developer website
1
devtools
13
digital event
1
discoverability
1
DNS-over-HTTPS
4
DoH
4
emoji
1
emscriptem
1
enterprise
1
extensions
27
Fast badging
1
faster web
1
features
1
feedback
2
field data
1
first input delay
1
Follow
1
fonts
1
form controls
1
frameworks
1
fugu
2
fund
1
funding
1
gdd
1
google earth
1
google event
1
google io 2019
1
google web developer
1
googlechrome
12
harmful ads
1
html5
11
HTTP/3
1
HTTPS
4
iframes
1
images
1
incognito
1
insecure forms
1
intent to explain
1
ios
1
ios Chrome
1
issue tracker
3
jank
1
javascript
5
lab data
1
labelling
1
largest contentful paint
1
launch
1
lazy-loading
1
lighthouse
2
linux
2
Lite Mode
2
Lite pages
1
loading interventions
1
loading optimizations
1
lock icon
1
long-tail
1
mac
1
manifest v3
2
metrics
2
microsoft edge
1
mixed forms
1
mobile
2
na
1
native client
8
native file system
1
New Features
5
notifications
1
octane
1
open web
4
origin trials
2
pagespeed insights
1
pagespeedinsights
1
passwords
1
payment handler
1
payment request
1
payments
2
performance
20
performance tools
1
permission UI
1
permissions
1
play store
1
portals
3
prefetching
1
privacy
2
privacy sandbox
4
private prefetch proxy
1
profile guided optimization
1
progressive web apps
2
Project Strobe
1
protection
1
pwa
1
QUIC
1
quieter permissions
1
releases
3
removals
1
rlz
1
root program
1
safe browsing
2
Secure DNS
2
security
36
site isolation
1
slow loading
1
sms receiver
1
spam policy
1
spdy
2
spectre
1
speed
4
ssl
2
store listing
1
strobe
2
subscription pages
1
suspicious site reporter extension
1
TCP
1
the fast and the curious
23
TLS
1
tools
1
tracing
1
transparency
1
trusted web activities
1
twa
2
user agent string
1
user data policy
1
v8
6
video
2
wasm
1
web
1
web apps
1
web assembly
2
web developers
1
web intents
1
web packaging
1
web payments
1
web platform
1
web request api
1
web vitals
1
web.dev
1
web.dev live
1
webapi
1
webassembly
1
webaudio
3
webgl
7
webkit
5
WebM
1
webmaster
1
webp
5
webrtc
6
websockets
5
webtiming
1
writable-files
1
yerba beuna center for the arts
1
Archive
2024
Jun
May
Apr
Mar
Feb
2023
Nov
Oct
Sep
Aug
Jun
May
Apr
Feb
2022
Dec
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2021
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2020
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2019
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2018
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2017
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2016
Dec
Nov
Oct
Sep
Aug
Jun
May
Apr
Mar
Feb
Jan
2015
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2014
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2013
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2012
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2011
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2010
Dec
Nov
Oct
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2009
Dec
Nov
Sep
Aug
Jul
Jun
May
Apr
Mar
Feb
Jan
2008
Dec
Nov
Oct
Sep
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.