I’ve built a handful of Chrome extensions this year, and I wrote up some of what I learned in a post back in March. Since then, I’ve found two more tricks that have proved useful.
First, the Chrome Canary channel includes a handy extension error console to quickly expose extension errors. Update: This feature is now available in all channels, including Chrome Stable.
Simply open the chrome://extensions page and an Errors link will appear available for extensions after you tick its Collect errors checkbox:
This error console can be enabled in other channels (dev/beta/stable) by launching with the --error-console command line argument.
Next, you’ll often end up with both a public version of your extension and a side-loaded developer build installed at the same time. If their Action icons are the same, it’s easy to get confused about which version is which.
To help clarify which is the development version, you can easily add a Dev badge to the icon of the developer build:
The code to add to your background.js file is straightforward and works even if the background page is not persistent:
// Our background page isn't persistent, so subscribe to events. chrome.runtime.onStartup.addListener(()=> { init(); }); // onInstalled fires when user uses chrome://extensions page to reload chrome.runtime.onInstalled.addListener(() => { init(); }); function init() { // Add Badge notification if this is a dev-install chrome.management.getSelf( (o)=>{ if (o.installType === "development") { chrome.browserAction.setBadgeText( {text: "dev"} ); } }); }
As mentioned in my last post, the Chrome Extension Source Viewer remains invaluable for quickly peeking at the code of existing extensions in the store.
Finally, some day I’ll need to spend more time looking through the many Extension Samples published by Google.
I’ve had more fun writing Chrome extensions than anything else I’ve built this year. If you haven’t tried building an extension yet, I encourage you to try it out. Best of all, your new Chrome extension development skills will readily transfer to building extensions to Opera, Firefox, and Microsoft Edge.
-Eric
text/plain 
Eric, I’m alarmed by this passage in the Chrome Extensions docs:
“Incognito mode promises that the window will leave no tracks. When dealing with data from incognito windows, do your best to honor this promise. For example, if your extension normally saves browsing history to the cloud, don’t save history from incognito windows.”
(https://developer.chrome.com/extensions/overview)
Do your best?? Is this really left to the discretion of extension developers? What good is incognito mode if it’s not enforced? Is there some kind of architectural challenge here that I’m missing?
How do you imagine if the browser could prevent that?
I’m not sure. Your comment tells me I’m missing something obvious. Is it not possible for incognito mode to wall off the data that is normally available to extensions in standard mode?
For one thing, I imagine that it would be easy for Chrome to simply disable extensions in incognito mode by default. After all, it’s a fairly explicit API. In fact, didn’t Chrome do this already? I think I have to explicitly choose to enable individual extensions in incognito mode. So the docs are even more confusing in light of that fact – extensions are disabled by default.
Yes, Chrome extensions are disabled by default in Incognito mode, but the user may approve them. Any extension that permits itself to run in Incognito mode should be aware of the mode and behave accordingly.
The point of most browser extensions is to interact with the web pages the user visits. If the browser were to “wall off” that access, the extensions could not do anything useful.
I think there are a few things extensions can do without interacting with the currently open (or any) page. All kinds of little tools, Wunderlist, calculators, games, and the even an ad blocker doesn’t need to phone home to do its job. I think controlling outgoing traffic is a straightforward task that we might reasonably expect a browser to do. It’s amazing what some of these extensions do behind the scenes, and what they send out – I think it’s almost assured that some innocuous extensions are going to be co-opted by APTs or even created by them.
Long-term, it would be great to have a browser extension API that was not based on JavaScript and didn’t expose the extension to attacker-controlled pages. I’m think of what Ormandy discovered about LastPass. That needs to be taken completely out of the DOM, completely away from whatever arbitrary website the user is on. It would be neat if we had a C#, golang, Python, Ruby, or Lua API that could do things like autofill a password without exposing itself to the site via JS. I dream a smart, well-architected language-agnostic extension API that funneled the aforementioned languages into a specially designed IR or bytecode (WebAssembly? Maybe too LISPy.) JavaScript is really not something we should accept long-term, and we need a boxed back-end API.