Chromium Blog: extensions

New experimental APIs for Chrome extensions

Monday, April 4, 2011

experimental extension APIsa series of low-level APIs

The Web Navigation Extension API allows extension developers to observe browser navigation events. These events fire both for top-level navigation and in-page navigation. The API therefore allows an extension to keep track of exactly what page (or section thereof) the tab is showing, and how the user got there. We foresee a number of use cases for this API, including extensions that gather and present statistical or benchmarking data, safe-browsing extensions, and developer tools.

The Proxy Extension API closes one of our most popular feature requests, allowing users to configure Chrome’s proxy settings via extensions. Proxies can be configured for the entire browser or independently for regular and incognito windows. Configuration options range from setting a single proxy server to installing remote or even local PAC scripts. A sample extension demonstrates these capabilities.

Sample extension showcasing individual proxy settings for normal and incognito windows.Let us knowPosted by Dominic Battré, Software Engineer and Jochen Eisinger, Software Engineer

Extending the Omnibox

Tuesday, February 22, 2011

omnibox APIthis extension

Posted by Matt Perry, Software Engineer

A Year of Extensions

Thursday, December 9, 2010

The gallery has grown to over 8,500 extensions and 1,500 themes.

A third of Chrome users have at least one extension installed.

Over 70 million extensions and themes have been installed.

New APIs for things like context menus, history, and cookies.

Integration between extensions and HTML5 features like notifications and geolocation.

Extension sync, so your favorite extensions are always with you.

Native support for Greasemonkey user scripts.

Chrome Web Storeomniboxpinned tabsnetwork interceptionsidebarsPosted by Aaron Boodman, Software Engineer

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

Making Chrome more accessible with extensions

Wednesday, June 30, 2010

work hardsome extensionsgalleryAccessibility implementation guideDeveloper's Guideopen sourcedChromeVis

extensionSummer of Code projectGoogle Moderator topicPosted by Rachel Shearer, Software Engineer

Extensions in Incognito

Thursday, June 24, 2010

Mouse StrokePasswordMaker

Note to extension developers: incognitochrome.extension.inIncognitoTabSaving data and incognito modePosted by Matt Perry, 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:

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:

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

Google Chrome Developer Update - Geolocation and Incognito Extensions

Friday, March 26, 2010

What's New in Google Chrome?
The Google Chrome Dev channel has been updated to 5.0.356.2 for all platforms since our last developer post. It includes a few new goodies for developers:

Please keep in mind that these features are still under development and are not 100% stable yet. In addition to the above, there are a few new experimental features baking in /trunk. You can try them out with the --enable-experimental-extension-apis flag:

chrome.experimental.infobars
chrome.experimental.contextMenu

Samples and Tutorials
We’ve added a few new sample extensions tutorials to get you started:

Sample and tutorial to demonstrate using Google Analytics in your extensions
Extension to display, create, and update your Google Documents
Tutorial to demonstrate using OAuth in your extensions

Remember to follow us on Twitter: @ChromiumDev!
Posted by Eric Bidelman, Developer Advocate

Experimental Extension APIs

Monday, March 1, 2010

You might have already noticed this, but we now have some APIs that we’re referring to as experimental. The idea is that we can add new APIs to the platform that may not be ready for prime time. This allows you to play with these APIs and give us feedback before they’re final, which in turn helps us get them out to everybody more quickly.
Our first two experimental APIs — chrome.experimental.history and chrome.experimental.processes — are available on the dev channel. The history API lets you query and modify the user’s browsing history. When it’s finalized, we’ll also allow you to replace the history page with your own, just like you can replace the new tab page today. The processes API allows access to information about Google Chrome’s process model, including process IDs and the CPU usage of individual tabs. The processes API is incomplete, but you can see upcoming features in its design doc.
These APIs have a few major limitations. First, to use an experimental API you must add a command-line flag when you start Google Chrome (--enable-experimental-extension-apis). Second, you can’t upload extensions that use experimental APIs to the Google Chrome Extensions Gallery. Finally, these APIs will change in incompatible ways, so the code that you write today isn’t guaranteed to work tomorrow.
What this really means is that these APIs are only useful for you to play with. You won’t be able to share extensions that use these APIs with a lot of people. However, we’d really like you to try them out and give us feedback. Doing so will help us release the APIs more quickly and make sure they do everything you need. Playing with the experimental APIs is also a way for you to get experience with them before most other developers.
We expect to add more experimental APIs over time, so keep an eye out for future announcements.
Posted by Erik Kay, Software Engineer

Extending Google Chrome 25,621 Miles

Thursday, February 4, 2010

At the end of 2009, we traveled around the world — to the Czech Republic, Russia, and Argentina — meeting with developers and talking to them about Google Chrome Extensions and HTML5.
In the first leg of our trip, we headed to Europe for Google Developer Day Prague and Google Developer Day Moscow on November 6th and 10th. Google Developer Days are one-day events featuring seminars and office hours about Google developer products like Android, Google App Engine, and of course Google Chrome! More than 800 developers were on hand in Prague and more than 1,500 in Moscow to learn, among lots of other things, how to develop extensions for Google Chrome. Below is video of the talk Brian gave about extensions in Moscow. You can also watch video of this talk translated into Russian or video of a similar talk from Prague and view slides from Prague or slides from Moscow.

Our next and last stop was Buenos Aires for Google DevFest Argentina. Google DevFests are more focused versions of Google Developer Days. On November 17th, another 800 or so developers attended this event. There, we covered the Google Chrome platform in a couple sessions — on HTML5 and extensions. Below are slides from the talk Mihai gave on HTML5. You can also view slides from the extension talk.

HTML5 and Google Chrome - DevFest09

View more documents from mihaiionescu.

For us, the best part of being at these events was seeing and hearing about all the interest in Google Chrome from developers everywhere and all the cool things those developers are building with the browser. If you'd like to get involved too, there are a bunch of community-organized Google Chrome events going on now. Check out the Google Technology User Group site to find a group or Meetup to find an event near you. And if there isn't a nearby group or event already, why not create your own! We have a collection of hackathon-in-a-box resources to help you do so.

Posted by Brian Kennish and Mihai Ionescu, Developer Advocates

40,000 More Extensions!

Monday, February 1, 2010

One thing that got lost in the commotion of the extensions launch is a feature that is near and dear to my heart: Google Chrome 4 now natively supports Greasemonkey user scripts. Greasemonkey is a Firefox extension I wrote in 2004 that allows developers to customize web pages using simple JavaScript and it was the inspiration for some important parts of our extension system.
Ever since the beginning of the Chromium project, friends and coworkers have been asking me to add support for user scripts in Google Chrome. I'm happy to report that as of the last Google Chrome release, you can install any user script with a single click. So, now you can use emoticons on blogger. Or, you can browse Google Image Search with a fancy lightbox. In fact, there's over 40,000 scripts on userscripts.org alone.
Installation is quick and easy, just like installing an extension. That's because under the covers, the user script is actually converted into an extension. This means that management tasks like disabling and uninstalling work just like they do with extensions.
Note that user scripts are powerful software and have full access to your private data on any web site. So, for example, they could read all your web mail or access your online bank. Be sure to read the comments on any user scripts in order to decide whether you trust the author with this power.
Also keep in mind that some user scripts won't work in Google Chrome yet, because of differences between it and Firefox. Based on some analysis that the current maintainers of Greasemonkey did, I expect between 15%-25% of scripts to not work in Google Chrome. If you find such a script, you should consider letting the author know. There may be something he or she can do to easily fix the problem. In the meantime, we'll keep working on bugs on our side to bring our implementation closer to Greasemonkey.
Have fun trying out the thousands of available scripts. And don't worry - If you get bored, there's lots more extensions at Google Chrome's extension gallery.
Posted by Aaron Boodman, Software Engineer

Security in Depth: The Extension System

Tuesday, December 15, 2009

In our earliest discussions about the extension system, we knew we wanted to raise the bar for security, but how can we secure the platform while still letting developers create awesome extensions that have rich interactions with web pages? During our threat analysis, we realized there were two main security concerns: malicious extensions and "benign-but-buggy" extensions.
A malicious extension is an extension written by an ill-intentioned developer. For example, a malicious extension might record your passwords and send them to back to a central server. The tricky part about defending against malicious extensions is that there are well-intentioned extensions that do exactly the same thing. Our defenses against malicious extensions focus on helping the user avoid installing malicious extensions in the first place:

We expect most users to install extensions from the gallery, where each extension has a reputation. We expect malicious extensions will have a low reputation and will have difficulty attracting many users. If a malicious extension is discovered in the gallery, we will remove it from the gallery.
When installing extensions outside the gallery, the user experience for installing an extension is very similar to the experience for running a native executable. If an attacker can trick the user into installing a malicious extension, the attacker might as well trick the user into running a malicious executable. In this way, the extension system avoids increasing the attack surface.

To help protect against vulnerabilities in benign-but-buggy extensions, we employ the time-tested principles of least privilege and privilege separation. Each extension declares the privileges it needs in its manifest. If the extension is later compromised, the attacker will be limited to those privileges. For example, the Gmail Checker extension declares that it wishes to interact with Gmail. If the extension is somehow compromised, the attacker will not be granted the privilege to access your bank.
To achieve privilege separation, each extension is divided into two pieces, a background page and content scripts. The background page has the lion's share of the extensions privileges but is isolated from direct contact with web pages. Content scripts can interact directly with web pages but are granted few additional privileges. Of course, the two can communicate, but dividing extensions into these components means a vulnerability in a content script does not necessarily leak all the extension's privileges to the attacker.
Finally, we utilize our multi-process architecture and sandboxing technology to provide strong isolation between web content, extensions, and the browser. Extensions run in a separate operating system process from the browser kernel and from web content, helping prevent malicious web sites from compromising extensions and malicious extensions from compromising the browser kernel. To facilitate rich interaction, content scripts run in-process with web content, but we run content scripts in an "isolated world" where they are protected from the page's JavaScript.
Of course, attackers will write malicious extensions and well-intentioned developers will write buggy extensions. The extension system improves security by making it easier for developers to write secure extensions. If you would like to learn more about the security of the extension system, you can watch our video or read our academic paper describing all the details.
Posted by Adam Barth, Software Engineer

Extensions beta launched, with over 300 extensions!

Tuesday, December 8, 2009

Most recentdesign docmailing listlimited restrictions

bugslet us knowAdd-on ConformPosted by Erik Kay and Aaron Boodman, Software Engineers

Chromium Blog