Chromium Blog
News and developments from the open source browser project
Chrome@IO
2012年6月26日火曜日
Google I/O is just around the corner and all of us in the Chrome team are looking forward to sharing with you what’s new with the open web.
Starting from June 27, we’ve planned more than 20
sessions
and
code labs
. If you are not joining us in San Francisco, you can still watch some of these sessions by attending one of the 350+ I/O
extended events
or by simply tuning in to the
livestream
from anywhere in the world. You can also watch these sessions when you are on the move by downloading the
Google I/O mobile app
.
All other sessions are going to be recorded. Videos from these sessions will be available after the conference on
Google Developers Live
and the
I/O website
.
Finally, you can follow our
Google+ page
and
Twitter account
for more behind the scenes coverage.
Let the fun begin!
Posted by Brian Rakowski, (Miami) Vice President Product Management
Put your extensions on a diet with event pages
2012年6月21日木曜日
If you’re a Chrome extensions power user, you may be familiar with a task manager that looks like this:
That’s a lot of extensions running! Most of the time, they’re probably just sitting idle, waiting for the user to interact with them. Do they really need to be running and using your memory all the time?
Over the last several months, we've been working on a new feature for the extension system called
Event Pages
that we think will help reduce the memory used by these idle extensions.
How They Work
Event pages are an evolution of
background pages
, with one major improvement: rather than running in the background all the time, an event page only runs when it is handling events. Once an event page becomes idle, it is unloaded, freeing memory until the next time it’s needed. Learn more from the
event page documentation
.
To help event pages support some important use cases, we’re also developing a few new APIs.
The
alarms API
allows an extension to wake itself up at set times, to support features like periodically syncing data to the cloud.
Some
new events
let extensions know when they have been installed, or when their event page is being unloaded.
A
declarative version
of the webRequest API lets extensions do network interception without the need for a background page at all.
Try it Out
We plan to release event pages to Chrome’s beta and stable channels late this summer, but you can start experimenting with them on the
developer channel
today. Try converting your overweight extension to event pages, and
let us know
how it works.
Posted by Matt Perry, Software Engineer
Customer Feedback Improvements in the Chrome Web Store
2012年6月20日水曜日
As Chrome Web Store apps and extensions have become more popular, users have been generating a large amount of reviews and feedback for developers. Until now, there was no way to separate a user’s review of an app’s features and quality from developer-focused feedback, such as the reporting of bugs, feature requests, and general questions.
To improve the feedback loop between developers and users, we’ve added a new way to get feedback directly from your users:
This feature provides a clean separation between reporting bugs and compatibility issues to developers and the rating / comments users can leave in the store relating to the functionality and usefulness of a given app. The contents of the feedback forum are publicly visible to everyone, which helps to cut down on duplicate issue reporting.
Turning the Feedback Feature On
In order to enable this feature for your store items, go to your developer dashboard and click on the “Edit your User Feedback preferences” option (highlighted below):
Engaging With Your Users
You should encourage your app’s users to engage with you via the new feedback feature by placing links to your app’s feedback page directly on your site after you’ve activated it. To do so, use the url format “https://chrome.google.com/webstore/support/yourappid
”.
Doing so will increase the likelihood that users will discover the feature and reinforce the idea that you actively support it.
We hope that this new feature will give users a better experience in reporting issues, requesting new features, and asking questions. Similarly, developers will now have a much easier forum to use to have an ongoing social conversation about their products.
If you have any questions about this new feature, you can reach us on our
developer forum
.
Posted by Siddhartha Saha, Software Engineer
Develop for Good and have a chance to win tickets to I/O 2013!
2012年6月14日木曜日
Cross-posted from the
Google Developers Blog
Would you like to use your coding skills to significantly improve the world, and have the chance to win tickets to Google I/O 2013 for your efforts?
Google.org
has joined forces with the
I/O Extended
team to bring you the
"Develop for Good" Hackathon
. We’re looking for hackers to tackle issues around repressive regimes, engaging citizens in politics and enabling us all to be greener!
Almost anyone can participate in the hackathon from just about anywhere in the world. Many of the Extended events are
already hosting hackathons
, so we encourage you to find an event near you or start your own. If you’re in the San Francisco Bay Area, Google.org will be hosting a ‘Develop for Good’ hackathon at the
San Francisco I/O Extended event
.
Here are the three challenges developed by the Google teams:
Google Ideas
: Conflict reporting for blackout situations in repressive regimes.
Google Politics & Elections
: Citizen Engagement for Politics & Elections.
Google Green
: Help us all be a little bit greener!
Developers can start preparing, and even coding, right away and then bring their ideas to the Extended event Hackathons during I/O (though we welcome you to participate even if you’re unable to attend an event). Pencils down on Friday night—hacks must be submitted by 11:59 p.m. (PDT) on June 29, 2012 via
this form
.
After June 29th a team of Googlers will judge the submissions for each challenge. We will announce the winning hacks for each challenge by about August 1st, 2012. There will be one winning hack selected from each challenge area, and each will receive up to 5 tickets to I/O 2013, along with the honorary title of "Google Developer for Good, 2012". In addition, we’ll award one of the
latest Chromebooks
to each member of the team producing the best web app across all three challenges.
If you are interested in getting involved, we recommend signing up for an
I/O Extended event
near you and then checking with the organizer to see whether a hackathon is part of the agenda -- or hosting your own Extended event and hackathon!
Find further details of the challenges, prizes, submission guidelines and
hackathon rules
on the
I/O Extended organizers' website
.
Posted by Anna de Paula Hanika, Product Marketing Manager
Make your website faster with PageSpeed Insights
2012年6月12日火曜日
Cross-posted from the
Google Developers Blog
.
A year ago, we released a preview of the PageSpeed Insights Chrome Developer Tools extension, which analyzes the performance of web pages and provides suggestions to make them faster. Today, we’re releasing version 2.0 of the
PageSpeed Insights
extension, available in the
Chrome Web Store
.
PageSpeed Insights analyzes all aspects of a web page load and points out the specific things you can do to make your page faster. For instance, PageSpeed Insights can inform you about an expensive JavaScript call that blocks the renderer for too long, remind you about that new photo on the front page of your web site that you might have forgotten to resize or optimize, or recommend changing the way you load third-party content so it no longer blocks the page load.
PageSpeed Insights for Chrome is a Chrome Developer Tools extension that analyzes all aspects of the page load, including resources, network, DOM, and the timeline. If you're already familiar with Chrome Developer Tools, you'll find that PageSpeed Insights integrates with a toolset you're already using.
Using technologies like
Native Client
, PageSpeed Insights is able to run the open-source
PageSpeed Insights SDK
securely and with the performance of native code. Leveraging the Insights SDK enables the Chrome extension to automatically optimize the images, CSS, JavaScript and HTML resources on your web page and provide versions of those resources that you can easily deploy on your website.
We hope you’ll give
PageSpeed Insights for Chrome
a try and start optimizing your web pages today. We’d love to hear from you, as always. Please try PageSpeed Insights for Chrome, and give us feedback on our
mailing list
with questions, comments, and new features you’d like to see.
Posted by Libo Song and Bryan McQuade, Software Engineers
New Developer Features in the Chrome Web Store
2012年6月12日火曜日
During these last few weeks, the
Chrome Web Store
team has been focused on launching the store in more countries and building some new features for developers that can help them reach and engage with more users.
New Countries
We recently launched the Chrome Web Store in six additional countries: Turkey, Ukraine, Egypt, Saudi Arabia, Morocco and the United Arab Emirates. This means that developers can now distribute and sell their apps to millions of additional potential users.
To be successful in these new markets, we highly recommend
localizing your apps
in as many languages as possible. This will make them more accessible to users around the world, and more likely to be promoted in the 42 countries the store is available in.
New Offline Apps Collection
To recognize developers who have made their apps work offline - and help users find them - we created a
special collection
just to highlight them in the store.
If you are a developer, getting your app listed in this collection is as simple as adding the
offline_enabled
flag to your app’s
manifest file
(note: to avoid negative user feedback, please ensure that your app does indeed work well offline before you do this).
Better Information in the Developer Dashboard
One of the common requests we’ve received from developers, is that they’d like better insight into how well their apps are doing in the store. Many of you would especially like to know how many times your apps and extensions are being viewed vs. how many installations are occurring.
To help you with your data needs, we’ve created a new graph view to help you understand the performance of your apps. To make this data more accessible, you can easily download it as a CSV file. Currently, we provide 90 days of history information.
In the near future, we plan to further refine this feature - for example, we may increase the historical period for which data is available and add other features to help you understand how your apps are being adopted.
If you have any questions about these new features, you can reach us on our
developer forum
.
Posted by Joe Marini, Developer Advocate
A Tale Of Two Pwnies (Part 2)
2012年6月11日月曜日
When we
wrapped up
our recent Pwnium event, we praised the creativity of the submissions and resolved to provide write-ups on how the two exploits worked. We already covered
Pinkie Pie’s submission
in a recent post, and this post will summarize the other winning Pwnium submission: an amazing multi-step exploit from frequent Chromium Security Reward winner Sergey Glazunov.
From the start, one thing that impressed us about this exploit was that it involved no memory corruption at all. It was based on a so-called “Universal Cross-Site Scripting” (or UXSS) bug. The UXSS bug in question (
117226
) was complicated and actually involved two distinct bugs: a state corruption and an inappropriate firing of events. Individually there was a possible use-after-free condition, but the exploit -- perhaps because of various memory corruption mitigations present in Chromium -- took the route of combining the two bugs to form a “High” severity UXSS bug. However, a
Pwnium
prize requires demonstrating something “Critical”: a persistent attack against the local user’s account. A UXSS bug alone cannot achieve that.
So how was this UXSS bug abused more creatively? To understand Sergey’s exploit, it’s important to know that Chromium implements some of its built-in functions using special HTML pages (called WebUI), hosted at origins such as
chrome://about
. These pages have access to privileged JavaScript APIs. Of course, a normal web page or web renderer process cannot just iframe or open a
chrome:// URL
due to strict separation between
http[s]://
and
chrome://
URLs. However, Sergey discovered that iframing an invalid
chrome-extension:// resource
would internally host an error page in the
chrome://chromewebdata
origin (
117230
). Furthermore, this error page was one of the few internal pages that did not have a
Content Security Policy
(CSP) applied. A CSP would have blocked the UXSS bug in this context.
At this point, multiple distinct issues had been abused, to gain JavaScript execution in the
chrome://chromewebdata
origin.
The exploit still had a long way to go, though, as there are plenty of additional barriers:
chrome://chromewebdata
does not have any sensitive APIs associated with it.
chrome://a
is not same-origin with
chrome://b
.
chrome://*
origins only have privileges when the backing process is tagged as privileged by the browser process, and this tagging only happens as a result of a top-level navigation to a
chrome://
URL.
The sensitive
chrome://*
pages generally have CSPs applied that prevent the UXSS bug in question.
The exploit became extremely creative at this point. To get around the defenses, the compromised
chrome://chromewebdata
origin opened a window to
chrome://net-internals
, which had an iframe in its structure. Another WebKit bug -- the ability to replace a cross-origin iframe (
117583
) -- was used to run script that navigated the popped-up window, simply “back” to
chrome://net-internals
(
117417
). This caused the browser to reassess the
chrome://net-internals
URL as a top-level navigation -- granting limited WebUI permissions to the backing process as a side-effect (
117418
).
The exploit was still far from done. It was now running JavaScript inside an iframe inside a process with limited WebUI permissions. It then popped up an about:blank window and abused another bug (
118467
) -- this time in the JavaScript bindings -- to confuse the top-level
chrome://net-internals
page into believing that the new blank window was a direct child. The blank window could then navigate its new “parent” without losing privileges (
113496
). The first navigation was to
chrome://downloads
, which gained access to additional privileged APIs. You probably get a sense of where the exploit was headed now. It finished off by abusing privileged JavaScript APIs to download an attack DLL. The same APIs were used to cleverly “download” and run
wordpad.exe
from the local disk (thus avoiding the system-level prompt for executing downloads from the internet zone). A design quirk of the Windows operating system caused the attack DLL to be loaded into the trusted executable.
As you can imagine, it took us some time to dissect all of this. Distilling the details into a blog post was a further challenge; we’ve glossed over the use of the UXSS bug to bypass pop-up window restrictions. The UXSS bug was actually used three separate times in the exploit. We also omitted details of various other lockdowns we applied in response to the exploit chain.
What’s clear is that Sergey certainly earned his $60k Pwnium reward. He chained together a whopping 14[*] bugs, quirks and missed hardening opportunities. Looking beyond the monetary prize, Sergey has helped make Chromium significantly safer. Besides fixing the array of bugs, we’ve landed hardening measures that will make it much tougher to abuse
chrome://
WebUI pages in the future.
Posted by Ken Buchanan, Chris Evans, Charlie Reis and Tom Sepez, Software Engineers
[*]14, or thereabouts. It’s easy to lose count.
Try Chrome in Metro mode
2012年6月7日木曜日
Back in March, we
began work
on a
Metro-style enabled desktop browser
, a version of Chrome that will run in both the Metro and desktop environments of Windows 8 on x86. (Chrome won’t run in WinRT, i.e. Windows 8 on ARM processors, as Microsoft is
not allowing browsers
other than Internet Explorer on the platform.) If you’re running the
Release Preview of Windows 8
, you’ll be able to try Chrome in Metro mode in the next
Chrome Dev channel
release by setting it as your default browser.
The initial releases of Chrome in Metro mode will include integration with the basic Windows 8 system functionality, such as
charms
and
snap view
. Over the next few months, we’ll be smoothing out the UI on Metro and improving touch support, so please feel free to
file bugs
. We’re committed to bringing the speed, simplicity, and security of Chrome into Windows 8, and we look forward to working with you on it.
Carlos Pizano, Software Engineer and Metro Gnome
Accelerated CSS Filters Landed in Chromium
2012年6月4日月曜日
CSS filters are a powerful, easy-to-use visual effects tool for web developers. Filters can manipulate the appearance of any HTML element and can be stacked together to create unique effects -- all with a single line of CSS. Chromium GPU accelerates these filters to make them super fast. CSS filters are new in Chromium 19.
The current set of supported filters in Chromium include many that are familiar to web developers with image processing experience, such as sepia, saturation, opacity, and blurs. If you’re a web designer looking to add dynamic visuals to your next page layout, a developer building a photo editing app, or a game developer looking for an easy way to add effects to your next title, CSS filters can help you get there easily.
img { -webkit-filter: sepia(100%) contrast(200%) blur(5px) }
GPU acceleration of these filters brings their performance to the point where they can be used for animating elements in conjunction with CSS animations powered by
-webkit-transition
or even HTML5 video tags.
To get a sense of how much you can do with CSS filters, check out this interactive abstract
painting app
.
For more info on CSS filters, including a full list of those available in Chromium and how to use them, check out the new
CSS Filter tutorial
on HTML5Rocks.
Posted by Stephen “Rose-Colored Glasses” White, Software Engineer
ラベル
$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
12月
8月
6月
5月
4月
3月
2月
2023
11月
10月
9月
8月
6月
5月
4月
2月
2022
12月
9月
8月
6月
5月
4月
3月
2月
1月
2021
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2020
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2019
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2018
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2017
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2016
12月
11月
10月
9月
8月
6月
5月
4月
3月
2月
1月
2015
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2014
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2013
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2012
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2011
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2010
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2009
12月
11月
9月
8月
7月
6月
5月
4月
3月
2月
1月
2008
12月
11月
10月
9月
Feed
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
