182 captures
29 Apr 2017 - 10 Apr 2026
Jun
JUL
Aug
23
2017
2018
2019
success
fail
About this capture
COLLECTED BY
Collection:
Twitter Outlinks
This is a Collection of URLs (and Outlinked URLs) extracted from a random feed of 1% of all Tweets.
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20180723170957/https://blog.chromium.org/2010/06/
Chromium Blog
News and developments from the open source browser project
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
Bringing improved PDF support to Google Chrome
Thursday, June 17, 2010
Millions of web users rely on PDF files every day to consume a wide variety of text and media content. To enable this, a number of plug-ins exist today which allow users to open PDF files inside their browsers.
As we’ve previously mentioned
, the traditional browser plug-in model, though powerful, presents challenges in compatibility, performance, and security. To overcome this, we’ve been working with the web community to help define a
next generation browser plug-in API
.
We have begun using this API to improve the experience of viewing and interacting with PDF files in Google Chrome. This mirrors
our efforts
to optimize the Adobe Flash Player experience in Chrome.
Today, we are
making available
an integrated PDF viewing experience in the Chrome developer channel for Windows and Mac, which can be enabled by visiting chrome://plugins. Linux support is on the way, and we will be enabling the integration by default in the developer channel in the coming weeks.
With this effort, we will accomplish the following:
PDF files will render as seamlessly as HTML web pages, and basic interactions will be no different than the same interactions with web pages (for example, zooming and searching will work as users expect). PDF rendering quality is still a work in progress, and we will improve it substantially before releasing it to the beta and stable channels.
To further protect users, PDF functionality will be contained within the security “
sandbox
” Chrome uses for web page rendering.
Users will automatically receive the latest version of Chrome’s PDF support; they won’t have to worry about manually updating any plug-ins or programs.
Currently, we do not support 100% of the advanced PDF features found in Adobe Reader, such as certain types of embedded media. However, for those users who rely on advanced features, we plan to give them the ability to launch Adobe Reader separately.
We would also like to work with the Adobe Reader team to bring the full PDF feature set to Chrome using the same
next generation browser plug-in API
.
We’re excited about the usability and security improvements this will bring to Chrome users, and we’ll continue to keep everyone updated on our efforts through this blog.
Posted by Marc Pawliger, Engineering Director
Google Chrome Frame - Now in Beta
Tuesday, June 8, 2010
Web developers have been itching to develop with HTML5 but have been held back by legacy browsers.
Google Chrome Frame
can help break this impasse by allowing applications to target HTML5 on versions of Internet Explorer. Today, we’re excited to announce that Google Chrome Frame has graduated from Developer Preview into Beta.
Since our
initial launch
, we've been listening to developers: Instead of adding new bells and whistles, we've fixed more than 200 bugs to make integration with Internet Explorer seamless while improving security, stability, and performance. For example, we’ve improved our handling of Internet Explorer’s InPrivate browsing, cache clearing, and cookie blocking. All of the enhancements and features of
Google Chrome 5.0
are available in Google Chrome Frame too, including HTML5 audio and video, canvas, geolocation, workers, and databases.
As we've worked on these improvements, we’ve been excited to see sites adopting Google Chrome Frame, including
Meebo
and all the blogs hosted by
WordPress
. In addition to our launch partner Google Wave, some other Google properties, including Orkut and YouTube are also relying on Google Chrome Frame to deliver HTML5 experiences to millions of users.
For those of you who want to develop HTML5 applications and deploy them broadly, we encourage you to
give Google Chrome Frame a try
. Existing users will be auto-updated to the beta, so if you downloaded Google Chrome Frame before, you’ll automatically get the new version. We’re also creating a new
dev channel
release, where you can try out the cutting-edge features we’re developing. For information on getting started with Google Chrome Frame, our project
documentation
is the place to start.
We’re always working hard to improve, so expect further enhancements and performance improvements in both the developer and beta versions in the coming weeks. You can help by giving us
feedback
and
filing bugs
, and we’ll have more to share in the days ahead.
Posted by Amit Joshi, Software Engineer, and Alex Russell, Software Engineer
Google Chrome Developer Update - Google I/O recap, new APIs
Monday, June 7, 2010
Google I/O recap
If you missed the
Day 1 keynote
this year, it was all about the open web. There were some amazing demos from Mugtug, TweetDeck, Adobe, and Sports Illustrated demonstrating the full potential of HTML5. There was a preview of
WebM/VP8
, a high-quality, open, and web-optimized video format. We saw the announcement of the
Chrome Web Store
, which later this year will provide a new and exciting channel for developers to distribute their web apps and reach new users. We also launched the
Google Font API
, which allows you to add high-quality web fonts to any web page. Lastly, there were all of the great
Chrome sessions
. Videos have been posted on the Google I/O website:
Developing with HTML5
Developing web apps for the Chrome Web Store
Beyond JavaScript: programming the web with native code
Chrome extensions - how-to
Google Chrome's Developer Tools
Using Google Chrome Frame
HTML5 status update
WebM Open Video Playback in HTML5
What's new for developers in Google Chrome?
The Google Chrome Dev channel is now up to
6.0.422.0
. It includes a bunch of new features to think about when developing your apps:
Desktop notifications
(new since our last developer update)
File API
and
FileReader API
: Drag and drop files from the desktop to the browser!
Native Client (NaCl) SDK
and
ports
: Run with
--enable-nacl
.
HTML5 sandbox attribute
Integrated Flash Player plugin: Run dev channel with
--enable-internal-flash
.
In addition to the above, there are new experimental extension APIs:
chrome.experimental.cookies
chrome.experimental.clipboard
chrome.experimental.omnibox
You can try out these features by launching a Dev-channel version of Google Chrome with the
--enable-experimental-extension-apis
flag and adding the ‘experimental’ permission in your
manifest.json
file. Please keep in mind that these features are still under development and are not 100% stable yet.
Upcoming developer events
For those of you based in New York, there’s an upcoming Chrome Extensions hackathon in our local office on June 10, 2010. We also have a five day DevFest starting June 28, 2010 in Sydney, Australia. Google Chrome will be featured on Wednesday, June 30. Stay tuned for more details!
For the latest news and upcoming developer events, subscribe to this blog and follow us on Twitter
@ChromiumDev
.
Posted by Eric Bidelman, Google Chrome Developer Relations
An update on Google Cloud Print
Monday, June 7, 2010
In April, we
announced
Google Cloud Print, a service that enables any app (web, mobile, desktop), on any device, OS, or browser, to print to any printer. Development is progressing quickly and we are now testing the service internally at Google. Those testing it are particularly excited about being able to print from their phones to any printer in the company. We hope to launch the service in the coming months.
Google Cloud Print will work with all printers, including those that are not themselves web-connected (we call these “legacy printers”). However, as we said in the April announcement, the best experience will be with a new generation of web-connected printers that are natively cloud aware. We are working with a number of printer manufacturers to bring cloud print capabilities to their printers. Today, HP
announced
a full suite of cloud-aware printers ranging from $99 consumer printers to business-oriented printers. This pioneering work is a big enabler for the cloud print vision and all these printers will work with Google Cloud Print out of the box.
Sundar Pichai, VP for Client Products at Google and I joined HP’s announcement today to demonstrate printing from Chrome OS and a mobile phone. We show that Google Cloud Print enables printing from any device, without drivers, and that the print job starts instantly. Check out the video below (I encourage you to watch the full video or if you want the Google segment it begins at 31:37).
Watch
live streaming video
from
hpkickoff
at livestream.com
If you are a developer interested in learning more about Google Cloud Print, first review our
documentation
then keep an eye on check-ins to the chromium.org project. Those who have been following know that we’ve already added preliminary printing support to Chromium OS via Google Cloud Print and our proxy (which enables legacy printers to work with the service) now runs on Windows, Mac, and Linux.
Posted by Mike Jazayeri, Group Product Manager
Google Chrome’s Developer Tools Improve Productivity
Friday, June 4, 2010
At Google I/O 2010 we
presented
on Google Chrome’s Developer Tools and enjoyed getting the in-person feedback from developers. We wanted to list some of the new and improved features we presented at I/O that set apart our tools in helping developers become more productive.
The Scripts panel now allows editing JavaScript without having to reload the page. Just double-click on the line in the function body while debugging and make your changes. We’ll patch the underlying optimized machine code at run-time and continue the execution. [
video
]
CPU profiler captures the state of your app at a rate of 1,000 samples per second without modifications to the running optimized machine code. The resulting tree view makes it easy to find out where to focus efforts on speeding up the web app. [
video
]
The new Timeline panel provides a simple view of the AJAX application execution. It records everything that happens in the browser from JavaScript execution to styles re-calculations and then visualizes it in a simple waterfall with timing information and traces to the source code. See the demo fragment at [
video
].
The improved Heap profiler can take snapshots of the JavaScript heap, visualize and compare them. This makes finding and fighting memory leaks a much easier task. See the demo fragment at [
video
].
We also
covered
a number of general Inspector improvements in the WebKit blog recently. Watch them live in the DevTools panel walk through from the I/O
video
.
We welcome feedback: to submit a bug or feature request please use the Chromium
issue tracker
and mention DevTools in the summary.
We hope you like the new improved Google Chrome Developer Tools. Note that some of the features above are only available on Google Chrome’s
Dev Channel
at this moment. For more info please check out the
DevTools
site.
Posted by Pavel Feldman, Software Engineer
WebSocket Protocol Updated
Wednesday, June 2, 2010
WebSocket is "TCP for the Web," a next-generation full-duplex communication technology for web applications being standardized as a part of
Web Applications 1.0
. The WebSocket protocol is more efficient than HTTP as used in Ajax, so it is more suitable for real time and dynamic web applications. WebSocket also provides a very simple API that can be used to communicate bidirectionally between the web browser and a server, so it makes it easy to develop such web apps.
We initially implemented WebSocket in WebKit, which has been available in WebKit nightly builds and in Google Chrome. The initial implementation was based on
draft-hixie-thewebsocketprotocol-75
. Early adopters were able to start developing web apps using WebSocket on real browsers, and provide feedback about the WebSocket specification.
Based on community feedback, the WebSocket specification has been updated to
draft-ietf-hybi-thewebsocketprotocol-00
(also known as draft-hixie-thewebsocketprotocol-76).
This version relaxes requirements on handshake messages to make it easier to implement with HTTP libraries, and introduces nonce-based challenge-response to protect from cross protocol attacks. These changes make it incompatible with draft-hixie-thewebsocketprotocol-75; a client implementation of -75 can’t talk with a server implementation of -76, and vice versa.
Developers should be aware that starting from WebKit nightly build r59903 and Chrome 6.0.414.0 (r47952), the client will talk to a server using -76 version of the protocol, so it will fail to open WebSocket connections with a WebSocket server based on draft-hixie-thewebsocketprotocol-75. Since -75 version of the protocol is obsoleted and no longer supported in future version of browsers, to support new clients you need to update the server implementation. (Note that Chrome 5 uses -75 version of protocol).
The WebSocket protocol is still actively being changed. Until there is more consensus, we will continue to update our implementation to follow the latest draft of specification, rather than worrying about breaking changes.
We’re more than happy to hear your feedback, and encourage you to file any bugs you find on our
issue tracker
.
Posted by Fumitoshi Ukai (鵜飼文敏), Software Engineer
In The Open, For RLZ
Wednesday, June 2, 2010
When we
released
a new stable version of Google Chrome last March, we tried to improve the transparency and
privacy
options of Google Chrome. One area where we’ve seen a lot of interest and questions is the
RLZ
library that is built into Google Chrome. RLZ gives us the ability to accurately measure the success of marketing promotions and distribution partnerships in order to meet our contractual and financial obligations. It assigns non-unique, non-personally identifiable promotion tracking labels to client products; these labels sometimes appear in Google search queries in Google Chrome.
Documenting Google Chrome’s use of promotional tags and tokens was a good start, but we wanted to take this transparency a step further. Our goal was to not only show you exactly how we were sending distribution information, but also what information was included and how it was generated.
Today, we’ve open-sourced the code that generates the RLZ parameter that sometimes appears in Google search queries. We’ve made the RLZ library its own
project
on the Google Code site, since this is the same library that is used in other Google products. This is analogous to how we opened
Omaha
, the Google Updater technology, as its own open-source project.
Chromium will also continue to exist as it always has, without any RLZ library included. And, you can still download a Google Chrome with no RLZ behavior at www.google.com/chrome. But now that RLZ is open, Google Chrome distributed through promotional means will include this open-source implementation of RLZ.
It is our hope that we are not only opening up a previously-closed part of Google Chrome and providing better transparency, but that we’re also offering up potentially useful code to others who may use it in their own projects.
We know this is just a small step, but we think that the RLZ project will provide better transparency and value to the community. We want to hear what you think, so please keep the feedback coming!
Posted by Roger Tawa, Software Engineer, and Glenn Wilson, Product Manager
Labels
accessibility
1
benchmarks
1
beta
8
blink
1
chrome apps
3
Chrome Frame
1
chrome web store
26
chromeframe
3
chromeos
3
chromium
3
cloud print
1
dart
8
devtools
11
extensions
23
gdd
1
googlechrome
12
html5
11
incognito
1
javascript
3
linux
2
mac
1
mobile
2
na
1
native client
8
New Features
5
octane
1
open web
2
releases
2
rlz
1
security
30
spdy
2
ssl
2
v8
5
web intents
1
webaudio
3
webgl
7
webkit
5
webp
5
webrtc
4
websockets
5
webtiming
1
Archive
2018
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
Google
on
Follow @ChromiumDev
Give us feedback in our
Product Forums
.
