Chromium Blog
News and developments from the open source browser project
Get more data about your extensions with Google Analytics
Thursday, September 9, 2010
If you’re using the Google Chrome Extensions Gallery to publish your extensions, we just added support for
Google Analytics
, which can help you better understand how many people visit your extension pages, where they’re coming from and more.
Starting today, you can specify a Google Analytics profile for each of your extensions. This will start tracking the extension’s page in your Google Analytics account as if that page was part of your own site. See these
instructions
for more information on how to set this up.
You can also use Google Analytics to track the usage of your extension once it’s installed. Check out this
tutorial
that explains how to integrate Google Analytics such that you can analyze how users interact with the features of your extensions.
For questions about this new feature, we encourage you to visit our
developer discussion group
and share your feedback with us.
Posted by Qian Huang, Software Engineer
An overview of the Chrome Web Store Licensing API
Friday, September 3, 2010
We recently released a
developer preview
of the
Chrome Web Store
, which included new documentation about our upcoming payments and licensing API. With this blog post, we wanted to share a quick overview and some tips about this API so that you can start developing your apps with it.
The Chrome Web Store will offer a built-in payments system that allows you to charge for apps, making it easy for users to pay without leaving the store. If you want to work with this payments system in your apps, you can use the
Chrome Web Store Licensing API
to verify whether a given user has paid and should have access to your app. Here’s how the API works:
The Licensing API has two inputs: the app ID and the user ID. The app ID is a unique identifier that’s assigned to each item uploaded to the store. You can see it most easily in the URL of your detail page—for example, .../detail/aihcahmgecmbnbcchbopgniflfhgnkff.
The user ID is the OpenID URL corresponding to the user’s Google Account. You can get the OpenID URL for the current user either by using Google App Engine’s built-in OpenID support or by using a
standard OpenID library
and
Google’s OpenID endpoint
.
Given the app ID and the user ID, you make Licensing API requests using this URI:
https://www.googleapis.com/chromewebstore/v1/licenses/<appID>/<userID>
When your app makes an HTTP request to the Licensing API, the app needs to be authenticated. The app is authenticated by matching your Google Account that uploaded the app to the Google Account used to call the API.
There are
a few ways
the app can indicate the Google Account used to make the API call. For the Chrome Web Store Licensing API, we highly recommend the use of
OAuth for Web Applications
. In this approach, OAuth access tokens are used to identify the Google Account calling the API.
You can obtain the necessary token via the
Chrome Developer Dashboard
by clicking the “AuthToken” link for your app. (This link appears only if your app uses Chrome Web Store Payments.) You’ll need this OAuth token
to sign
the HTTP requests to call the Licensing API. The best way to sign your requests is with a
standard OAuth library
.
The OAuth tokens that the Chrome Developer Dashboard provides are limited in scope, which means that they can only be used to make Licensing API calls. They can’t be used to make calls to other authenticated Google APIs or for anything else.
Once you’re ready to make authenticated calls, give the API a try by making your first request. For more information read the
Licensing API docs
, try out the
Getting Started tutorial
, check out the
samples
, and watch the video below:
Note that current version of the Licensing API is a stub, which means that it doesn’t return live data that’s based on purchases just yet. Instead, it returns dummy responses that you can use to verify the various scenarios of your implementation. However the protocol, response format, and URL endpoints of the API are all final, so your implementation shouldn’t need to change before the final launch of the store.
We look forward to receiving your feedback on the current Licensing API implementation at our
developer discussion group
.
Posted by Munjal Doshi, Software Engineer
Chromium Graphics Overhaul
Friday, August 27, 2010
For some time now, there’s been a lot of work going on to overhaul Chromium’s graphics system. New APIs and markup like WebGL and 3D CSS transforms are a major motivation for this work, but it also lets Chromium begin to take advantage of the GPU to speed up its entire drawing model, including many common 2D operations such as compositing and image scaling. As a lot of that work has been landing in tip-of-tree Chromium lately, we figured it was time for a primer.
At its core, this graphics work relies on a new process (yes, another one) called the GPU process. The GPU process accepts graphics commands from the renderer process and pushes them to OpenGL or Direct3D (via
ANGLE
). Normally, renderer processes wouldn’t be able to access these APIs, so the GPU process runs in a modified sandbox. Creating a specialized process like this allows Chromium’s sandbox to continue to contain as much as possbile: the renderer process is still unable to access the system’s graphics APIs, and the GPU process contains less logic.
With this basic piece of infrastructure, we’ve started accelerating some content in Chromium. A web page can naturally be divided into a number of more or less independent layers. Layers can contain text styled with CSS, images, videos, and WebGL or 2D canvases. Currently, most of the common layer contents, including text and images, are still rendered on the CPU and are simply handed off to the compositor for the final display. Other layers use the GPU to accelerate needed operations that touch a lot of pixels. Video layers, for example, can now do color conversion and scaling in a shader on the GPU. Finally, there are some layers that can be fully rendered on the GPU, such as those containing WebGL elements.
After these layers are rendered, there’s still a crucial last step to blend them all onto a single page as quickly as possible. Performing this last step on the CPU would have erased most of the performance gains achieved by accelerating individual layers, so Chromium now composites layers on the GPU when run with the --enable-accelerated-compositing flag.
If you’d like to read more about this work, take a look at this
design doc
which outlines Chromium’s accelerated compositing system. Over time, we’re looking into moving even more of the rendering from the CPU to the GPU to achieve impressive speedups.
Posted by Vangelis Kokkevis, Software Engineer
New Flock Browser Based On Chromium
Tuesday, August 24, 2010
Foreword: When we released Google Chrome almost two years ago, we also released the source code under an open-source license. Just as Firefox, WebKit, and other open source projects helped to drive the web forward, we wanted to follow suit and ensure that others could use the code we developed to make their products better. The Chromium codebase provides a complete browser to build on, so that if you want to focus on one particular piece, such as drastically changing the user interface, you can do that without having to worry about how to get amazing performance in the rest of the browser.
Recently, Flock released a new beta version of their browser built on top of the Chromium codebase. For those of us in the Chromium project, this is extremely exciting and encouraging. We believe that users having a choice between multiple browsers is a great thing, as it spurs innovation and competition, and lets users choose a browser that provides the best experience for them. Flock brings an innovative approach to their "social web browser," and we are glad to welcome them into the Chromium community. As part of that, we wanted to offer the team behind Flock an opportunity to talk about the ideas behind Flock, how Chromium helped them in achieving their goals, and their vision for the future. What follows is a perspective from Clayton Stark, VP Engineering at Flock.
When Flock began developing its first web browser five years ago, "the social web" was a small, niche market. Today social
is
the mainstream web, and this evolution in the market drove our development roadmap. With the new Flock browser, our engineering team focused on designing a straightforward and integrated social dashboard that delivers an experience simple enough for a mass audience. This is where the technology behind Chromium came into the picture for Flock. As Chromium emerged, we saw that not only was there significant improvements to performance, but also apparent was a simple and elegant user interface and architecture across all the various systems.
A core goal of new Flock is to keep our users in touch with all of their friends and feeds with a minimum of configuration, and at the same time, make it fun and simple. With all of the users’ feeds and social activity streams flowing into the scrolling sidebar, we knew the performance had to be first-rate, and that techniques we used for earlier versions of Flock were unlikely to perform at scale. With Chromium under the hood, we were able to leverage web workers, and that, combined with the raw horsepower of V8, allowed us to scale the use of the sidebar to manage very large data sets (in the first few weeks after the beta launched we saw a few hundred million activities flowing into Flock’s sidebar). Most importantly, benchmark testing shows us that New Flock with Chromium performs in the top-tier of all browsers available in the market.
Clearly the web is evolving very quickly, and we are seeing more and more people discovering content through their friends. The Flock team is energized by the big developments coming fast in this emerging, interest-graph-enabled web, and we have a roadmap in front of us that we are really excited about. The browsing platform needs to continue to mature at a rapid pace to support the dramatic changes in online user behavior. And, as it does, we already see the performance and power in Chromium that we need to allow us to focus on the innovations we want to bring forward, on top of the platform.
So, I’d like to send out a huge thanks on behalf of the Flock team to all those who have contributed to the Chromium project. Your work has made our project possible, and made new Flock our best release ever.
Clayton Stark, VP Engineering
Flock, Inc.
Posted by Ian Fette, Product Manager
New in Google Chrome Beta: More Extension APIs, Free Hoodies
Monday, August 23, 2010
Since we launched the Google Chrome extension system, one of the most frequent
requests
we’ve gotten is to add the ability to integrate with the context menu (the menu that pops up when you right-click on a link, image, or web page).
Now in Google Chrome Beta, developers can do just that. The new
context menu API
allows extension developers to register menu items for all pages or for a subset of pages. Developers can also register menu items for specific operations, like right-clicking on an image or movie. For example, you could create an extension that makes it easy for users to share interesting images from images.google.com with their friends on Google Buzz.
Some users have lots of extensions installed. To help these users avoid ending up with gigantic unwieldy context menus, Google Chrome automatically groups multiple menu items from the same extension into a sub-menu.
We’d also like to announce two new experimental APIs. These APIs aren’t quite ready for prime-time yet, but we’re really excited about them and couldn’t wait to get your feedback.
The
omnibox API
allows extension developers to integrate with the browser’s omnibox. With this API, you can build custom search support for your favorite website, keyboard macros to automate tasks, or even a chat client right into the omnibox.
The
infobars API
allows extension developers to display infobars across the top of a tab. These infobars are built using normal HTML, so they can be heavily customized and interactive.
For the complete list of new extension APIs in Google Chrome beta,
see the docs
. And
let us know
if you make something cool. If we like it, we’ll send you a free extensions hoodie and may even feature you in the gallery.
We look forward to seeing what you come up with!
Posted by Aaron Boodman, Software Engineer
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
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
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
.