Chromium Blog
News and developments from the open source browser project
Get your apps ready for the Chrome Web Store!
Thursday, August 19, 2010
Since our
announcement
of the Chrome Web Store at Google I/O, our team has been hard at work preparing for our launch later this year. Today we’re making the first step towards this milestone by making available a
developer preview of the Chrome Web Store
.
Developers can now start uploading apps and experiment with packaging them, installing them in Chrome (using the latest Chrome dev channel) and integrating our payments and user authentication infrastructure.
To get started, take a look at our recently updated documentation for
installable web apps
, which explains how to prepare and package your apps. You should also review some additional documentation we just released on the store’s
licensing
and
user authentication
features.
To upload your app, you’ll need to use the upload flow of the
Google Chrome Extensions Gallery
.
When the Chrome Web Store launches, it will replace the current gallery, featuring a completely new design for users to discover great apps, extensions and themes all in one place. Until then, only you can see the apps you upload - they will not be visible to other visitors of the gallery during this developer preview. In the meantime, you can continue to use the gallery for publishing Chrome extensions and making them available to Chrome users.
We look forward to sharing more news about the store and its features over the next weeks. Meanwhile, we encourage you to subscribe to our
developer discussion group
for apps and look for updates on the
Chromium blog
.
Posted by Michael Noth, Software Engineer
Security improvements and registration updates for the Google Chrome Extensions Gallery
Thursday, August 19, 2010
Since we introduced extensions in Google Chrome, we focused on making the platform more robust, by continuously exposing new APIs to developers. This has helped our
extensions gallery
blossom where more than 6,000 extensions are listed today and more than 10 million extensions are downloaded by Chrome users every month.
We designed security into the extensions system
from day 1
but we’re always looking for more ways to protect users. So, today, we are introducing two significant changes in the Google Chrome Extensions Gallery: a developer signup fee and a domain verification system.
The developer signup fee is a one-time payment of $5. It is intended to create better safeguards against fraudulent extensions in the gallery and limit the activity of malicious developer accounts. Starting today, this fee will be required to publish extensions, themes and soon apps in the gallery. We are waiving the fee for developers who already registered with the gallery (specifically before 11am PST today), so that they can continue to update their extensions and publish new items without paying the fee.
Domain verification is another addition that we believe will protect users and developers alike. Developers will be able to associate their extensions (and soon their apps) with domains they own or manage using
Google’s Webmaster Tools
. This way, they can clearly associate their extension with their brand and website, which in turn will help users identify “official” extensions in the gallery.
We believe that these are important improvements to the security of the gallery. We understand that changes like these can create a lot of questions, so please reach out to us on our
developer discussion group
for extensions.
Posted by Gregor Hochmuth, Product Manager
HTML5Rocks v2 - More Guides, New Studio
Friday, August 13, 2010
We think HTML5 will make your work more engaging and create a faster, more responsive experience for your users, so we're happy to add today a slew of new content to
html5rocks.com
.
If you want to not only get up to speed, but understand the browser differences and techniques for a robust implementation, please take a look through the new guides for implementing
HTML5 video
,
understanding "offline,"
auditing your webapp
with the Chrome developer tools, and using
web workers
and
@font-face
. You can now comment about your experiences with these features and stay up to date on new content via our new
RSS feed
.
We're also sharing the new
HTML5 Studio
, a collection of samples of these features in use, with code you can learn from and hack on.
If you'd like to contribute code, guides, or samples, please get in touch on the
bug tracker
or on
@ChromiumDev
. We'd love to incorporate your work.
Posted by Paul Irish, Google Chrome Developer Relations
Google Chrome in a Coal Mine
Monday, August 2, 2010
Since Google Chrome launched almost 2 years ago, the team has embraced the “launch early and often” strategy by releasing Dev channel builds almost weekly. But sometimes, such as when we’re in the process of moving a Dev channel release to the Beta channel, we’re unable to release a new Dev channel build, and other times, even a week is too long to wait to get feedback from the field on a change.
The team considered updating the Dev channel more frequently, but doing so would require us to forgo our manual testing pass on these builds. Even though the Dev channel is often rough around the edges, we realized that this lack of testing would result in a Dev channel that’s too unstable even for early adopters and developers. That’s why, a few days ago, we released a new experimental version of Google Chrome called Google Chrome Canary Build. We plan to update the Canary Build more frequently than the Dev channel, with riskier changes, and usually without a human being ever verifying that it works, so the Canary Build is only for users who want to help test Google Chrome and are comfortable using a highly unstable browser that will often break entirely. To enable you to continue using the same browser you love when the canary croaks, we’ve made it possible to install the Canary Build in addition to the Dev, Beta or Stable channel versions of Google Chrome.
The Canary Build is still brand new so it currently has a few limitations. Currently, it’s only available for Windows and cannot be set as your default browser. You can star the issues for
Mac
and
Linux
support, as well as the
issue
for default browser support to cast your vote and be notified of progress there.
If you like to live on the bleeding edge, give the
Google Chrome Canary Build
a shot and let us know what you think. The early feedback on crashes, performance regressions, broken features and other problems is incredibly valuable to us, so thanks!
Posted by Henry Bridge, Product Manager
Do You Know How Slow Your Web Page Is?
Wednesday, July 28, 2010
The
Web Timing
draft specification presents a standard set of metrics for measuring web page load time across browsers. We’re happy to announce that in
Chrome 6
, web developers can now access these new metrics under
window.webkitPerformance
.
Measuring web page load time is a notoriously tricky but
important
endeavor
. One of the most common challenges is simply getting a true start time. Historically, the earliest a web page could reliably begin measurement is when the browser begins to parse an HTML document (by marking a start time in a
<script>
block at the top of the document).
Unfortunately, that is too late to include a significant portion of the time web surfers spend waiting for the page: much of the time is spent fetching the page from the web server. To address this shortcoming, some clever web developers work around the problem by storing the navigation start time in a cookie during the previous page’s
onbeforeunload
handler. However, this doesn’t work for the critical first page load which likely has a cold cache.
Web Timing now gives developers the ability to measure the true page load time by including the time to request, generate, and receive the HTML document. The timeline below illustrates the metrics it provides. The vertical line labeled "Legacy navigation started" is the earliest time a web page can reliably measure without Web Timing. In this case, instead of a misleading 80ms load time, it is now possible to see that the user actually experienced a 274ms time. Including this missing phase will make your measurements appear to increase. It’s not because pages are getting slower – we’re just getting a better view on where the time is actually being spent.
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
.
Posted by Tony Gentilcore, Software Engineer
Release Early, Release Often
Thursday, July 22, 2010
Over the next few months, we are going to be rolling out a new release process to accelerate the pace at which Google Chrome stable releases become available. Running under ideal conditions, we will be looking to release a new stable version about once every six weeks, roughly twice as often as we do today.
So why the change? We have three fundamental goals in reducing the cycle time:
Shorten the release cycle and still get great features in front of users when they are ready
Make the schedule more predictable and easier to scope
Reduce the pressure on engineering to “make” a release
The first goal is fairly straightforward, given our pace of development. We have new features coming out all the time and do not want users to have to wait months before they can use them. While pace is important to us, we are all committed to maintaining high quality releases — if a feature is not ready, it will not ship in a stable release.
The second goal is about implementing good project management practice. Predictable fixed duration development periods allow us to determine how much work we can do in a fixed amount of time, and makes schedule communication simple. We basically wanted to operate more like trains leaving Grand Central Station (regularly scheduled and always on time), and less like taxis leaving the Bronx (ad hoc and unpredictable).
The third goal is about taking the pressure off software engineers to finish features in a single release cycle. Under the old model, when we faced a deadline with an incomplete feature, we had three options, all undesirable: (1) Engineers had to rush or work overtime to complete the feature by the deadline, (2) We delayed the release to complete that feature (which affected other un-related features), or (3) The feature was disabled and had to wait approximately 3 months for the next release. With the new schedule, if a given feature is not complete, it will simply ride on the the next release train when it’s ready. Since those trains come quickly and regularly (every six weeks), there is less stress.
So, get ready to see us pick up the pace and for new features to reach the stable channel more quickly. Since we are going to continue to increment our major versions with every new release (i.e. 6.0, 7.0, 8.0, 9.0) those numbers will start to move a little faster than before. Please don’t read too much into the pace of version number changes - they just mean we are moving through release cycles and we are geared up to get fresher releases into your hands!
Posted by Anthony Laforge, Program Manager
Celebrating Six Months of Chromium Security Rewards
Tuesday, July 20, 2010
It has been approximately six months since we launched the
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
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
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
.