Chromium Blog
News and developments from the open source browser project
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
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!
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
Making Chrome more accessible with extensions
Wednesday, June 30, 2010
Personalizing the web to match the needs and abilities of users is a big part of improving overall web accessibility. While we continue to
work hard
on making core Google Chrome more accessible, we're really excited about using browser extensions to improve the accessibility of the web for millions of users.
There are already
some extensions
among the more than 5,000 in the
gallery
that can benefit users with special needs. Some of these extensions use Chrome APIs and content scripts to alter the browser and manipulate the DOM of pages, offering users almost unlimited flexibility for viewing the web. Other extensions choose to implement altenative workflows, instead of adapting existing web page UIs, to give users faster access to content. These extensions benefit not just users of assistive technologies like screen readers but everyone who prefers access modes like keyboard shortcuts and captions.
If you are interested in making your extensions more accessible, we’ve created a new
Accessibility implementation guide
in the Chrome Extensions
Developer's Guide
that gives you an overview of accessibility best practices such as keyboard navigation, color contrast and text magnification. We’ve also
open sourced
the code behind
ChromeVis
, a new extension for users with low vision, so that you can use some of its code for manipulating text selection and magnification in your own extensions.
Already the NPR team has implemented some accessibility best practices in their
extension
. We hope to see more extensions adopting them. From our end, we're sponsoring a
Summer of Code project
to produce an extension that helps users produce custom style sheets and plan to create additional extensions that make navigating the web through Chrome easier.
We've also set up a
Google Moderator topic
where everyone can submit ideas for extensions that improve web accessibility. We hope these ideas will inspire extensions developers who are looking to create something useful for the community.
Stay tuned for future updates about Chrome Extensions and accessibility!
Posted by Rachel Shearer, Software Engineer
Enabling Adobe Flash Player support in Google Chrome’s stable channel
Wednesday, June 30, 2010
In March, we
announced
that we would be bringing improved support for Adobe Flash Player to Google Chrome. Along with driving the development of a
next generation browser plug-in API
, this integration will eliminate the need to install Flash Player separately and reduce the
security risk
of using outdated versions. In the near future, we will extend Chrome’s “
sandbox
” to web pages with Flash content to further protect users from malicious content.
We have been testing the integration in Google Chrome’s dev and beta channels over the last few months in order to ensure a quality experience for all our users. Over the last week, we have enabled the integration by default in the stable channel of Chrome.
Users who do not wish to use the built-in version of Flash Player in Chrome can disable the integration via the chrome://plugins manager. In this case, Chrome will fall back to the system-installed version of Flash Player, if it exists.
Posted by Jeff Chang, Product Manager
Improving plug-in security
Monday, June 28, 2010
Bad guys want to install persistent malware on your machine. Once they achieve this, they are free to do a variety of bad things such as steal your banking passwords, abuse your network connection, and rifle through your sensitive files.
Bad guys will install malware via the easiest path available. Traditionally, the easiest attack was to simply get a user to run an untrusted executable. Not all users fall for this. And modern operating systems and e-mail systems make this harder to do and restrict the permissions that the downloads run with -- making it less attractive. Next easiest is to exploit a disclosed vulnerability which is not yet patched by all users. The industry’s response to this is to autoupdate its users with security patches;
browsers including Firefox and Chrome
have demonstrated success at keeping the majority of their user bases current.
More advanced attacks involve finding undisclosed vulnerabilities in the browser. Despite being harder, there has been a lot of user damage due to exploitation of non-public bugs in browsers. Pleasingly, there’s a trend in modern browsers to integrate sandboxing. IE7 on Vista (and newer combinations) plus Google Chrome already have built-in sandboxes of varying strength. This makes many latent browser bugs incapable of persistently installing malware without a lot of additional effort to find a second bug to break out of the sandbox. Again, attackers favor the easiest attack so the increasing robustness of browsers is causing them to look elsewhere for ways to compromise user machines.
This brings us to the present time. We’re seeing a
remarkable swing
towards attacks that target pieces of browsing infrastructure
such as plug-ins
. This may be because browsers are taking the lead on auto-update and sandboxing. Since many plug-ins are ubiquitous, they pose the most significant risk to our user base. To better protect Google Chrome users from the threat of plug-in exploits, we have already announced a couple of initiatives:
More powerful plug-in controls
: Google Chrome now has the ability to disable individual plug-ins (about:plugins) or to operate in a “domain whitelist” mode whereby only trusted domains are permitted to load plug-ins (Options->Content Settings->Plug-ins).
Autoupdate for Adobe Flash Player
: By including Adobe Flash Player -- the most popular plug-in -- with Google Chrome, we can re-use Google Chrome’s powerful autoupdate strategy and minimize the window of risk for patched vulnerabilities.
There are more ways we are attacking the problem:
Integrated, sandboxed PDF viewing
: We have
announced
an integrated PDF viewer plug-in running inside Google Chrome’s sandbox. This will make it harder for PDF-based vulnerabilities to result in the persistent installation of malware.
Protection from out-of-date plug-ins
: Medium-term, Google Chrome will start refusing to run certain out-of-date plug-ins (and help the user update).
Warning before running infrequently used plug-ins
: Some plug-ins are widely installed but typically not required for today’s Internet experience. For most users, any attempt to instantiate such a plug-in is suspicious and Google Chrome will warn on this condition.
A next generation plug-in API
: “
Pepper
” makes it easier to sandbox plug-ins.
User safety is of paramount importance to us, including threats to our users caused by plug-ins outside of our direct control. We are working hard to improve the security of the entire browser ecosystem for Google Chrome users.
Posted by Chris Evans, Julien Tinnes, Michal Zalewski; Google Security Team
A fresh coat of chrome
Friday, June 25, 2010
As part of our continual work on Google Chrome’s user interface, we’ve been trying to streamline the toolbar, make the
Omnibox
more approachable, and communicate site security information more clearly. Users on our
dev channel
may have noticed some of these experiments already:
When you are typing into the Omnibox, an icon to the left will show how your input will be interpreted - such as a magnifying glass for search queries (
), and a globe for URLs (
). When you’re not typing, the same icon can be dragged to another document to copy the current page’s URL, or clicked to reveal information about the current site.
When on a secure (SSL) site, this icon changes to a lock (
) - previously we displayed the lock icon at the end of the Omnibox, but now it’s closer to the URL and in a more obvious place.
We’ve added a clearer presentation of Extended Validation (EV) certificate holder names (
), which, like the lock, are now at the beginning of the Omnibox.
We’ve changed the colors and icons used with secure sites to make mixed content more obvious, and avoid confusion about ambiguous colors.
In some situations, we’ve stopped displaying “http://” and/or a slash after the hostname. This makes the hostname more prominent and the URL more readable, and provides more visual distinction between regular and SSL websites (which keep their “https://” prefix). We’ve also done a lot of work to make sure that copying and pasting of these URLs continue to work as you would expect.
The bookmark star icon (
) has joined the other “page actions” at the right-hand side of the Omnibox.
Stop and Reload have been combined, and Go eliminated, to make things simpler and keep all the navigation-related toolbar buttons together.
Here’s a screenshot of the old interface in the stable channel (5.0), followed by the current interface on the dev channel (6.0):
More experiments are on the way to all platforms, like simplifying our menu structure, and further reducing visual noise in the toolbar:
In all these cases, we may tweak or even revert experiments before settling on a final solution. We’ve found that living with a new design is more informative than merely discussing it, so thanks to all our dev channel users for your patience and feedback as we test out these changes.
Posted by Nicholas Jitkoff, User Experience Designer
Extensions in Incognito
Thursday, June 24, 2010
When we first released extension support in Chromium, we left out all support for running extensions in incognito mode. This meant I had to live without handy extensions like
Mouse Stroke
and
PasswordMaker
(shameless plug) whenever I opened an incognito window, and that made me sad. When your muscle memory is trained to expect certain features, it's pretty jarring to find them missing. So in the latest stable version of Google Chrome, I added support for running extensions while in incognito.
One of the main reasons we delayed adding incognito support was that Chrome has no way to ensure that extensions obey the incognito rules: in short, that your browsing data is not saved after you close the incognito window. After much debate, we finally decided to let users decide which extensions they were comfortable using in incognito. You should only enable extensions that you trust and that don't save sensitive information. For example, an extension named Save All Your History would probably not be a good idea to run in incognito, since it would defeat the entire purpose of opening an incognito window. (This is not always the case: if the extension is written with incognito support in mind, it could avoid saving sensitive information, but it is up to the extension developer.)
To allow an extension to run while incognito, open the Extensions management page (accessible from the Tool menu -> Extensions). Each extension has an option to "Allow in incognito". Turning this on will let the extension display page and browser actions in incognito windows, and give them access to browser information originating from an incognito tab. It's just as easy to remove this access any time by following the same steps and unchecking the "Allow in incognito" option.
Note to extension developers:
Try to be a good citizen by only persisting browsing information collected from non-incognito windows. You can determine this by examining the
incognito
property on tab and window objects, or checking
chrome.extension.inIncognitoTab
from within a content script. For more information, see the extension documentation section on
Saving data and incognito mode
.
Posted by Matt Perry, Software Engineer
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
21
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
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
.