Chromium Blog
News and developments from the open source browser project
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
HTML5 Rocks!: A resource for open web developers
Tuesday, June 22, 2010
Because HTML5 and its related technologies cover so much ground, it can be a real challenge to get up to speed on them. That’s why today we're sharing
HTML5 Rocks
, a great new resource for developers and teams looking to put HTML5 to use today, including more information on specific features and when to use them in your apps.
We're launching the site with
nine tutorials
on specific HTML5 features. For example, you can learn how to successfully
take your application offline
,
access the user's location with Geolocation
, and even
read local files from within JavaScript
. In the site, we’ve also included a number of APIs that are defined outside the W3C HTML5 Spec, but kept them within this site as next-generation web applications span many specs. Watch the site as we’ll soon be adding more guides.
The
Interactive Presentation
, written in HTML5, demonstrates a number of features with examples you can toy with. You can use this presentation to learn more about HTML5, but also to conduct presentations with your team. Feel free to share it; all the content here is licensed
Creative Commons Attribution
.
The
code playground
lets you take working examples and edit them live, so you can get a feel for how the browser reacts to these APIs. And after you’ve hacked with, for example, the Notifications API, you can explore
handpicked resources
that include reference guides, development tools, and other community sites.
Send us a tweet at
@ChromiumDev
or post to the
Chromium HTML5 group
to let us know how we can improve the site for you. We look forward to seeing you experiment and build apps with these features!
Posted by Paul Irish, Google Chrome Developer Relations
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
28
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
2026
Mar
2025
Oct
Jul
Jun
May
Jan
2024
Dec
Aug
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
.
