Extending Chrome and Firefox privileges with message passing.

I'm going off on a technical tangent for this post because I'd like to take the time to write a little about the design of our application platform, Kixx. Specifically, I'm going to outline how I think we can build privileged applications using the web browser as a platform. By privileged, I mean applications that can make cross domain network calls and have access to a local storage system among many other things that normal web pages cannot do.

The Firefox and Chrome web browsers both have some notion of a background page running with extended local privileges available to extension developers. For Firefox, this takes the form of an undocumented and hidden window running within the the core of the browser referred to as the "chrome" by Mozilla developers. In the Chrome browser, extension authors can explicitly load an HTML document (with JavaScript) into a background page using the manifest configuration of an installed extension.

We can build an extension for both the Chrome and Firefox browsers that takes advantage of these features to give extended privileges to pages running in the normal browser window tabs. This way, we can build locally installed applications which run in the browser and can do things like make cross domain XMLHttpRequest Ajax calls, open new browser tabs, and do other stuff that web pages should not normally be allowed to do.

Firefox extension developers are able to make actual JavaScript objects available to content pages from the internal JavaScript of the browser. On the other hand, Chrome extension developers must create a message passing API between the privileged extension scripts and the DOM of the content page.

For security reasons, and because of the Chrome browser design for page interaction, our design will be using a message passing API. There are also some other side benefits of the message passing design that I'll mention later.

In the Firefox extension, we will dynamically place an iframe element into the hidden window from the JavaScript in our extension. We'll then load our own page, which implements the privileged half of our message passing API, within our iframe element as the browser loads.

In the Chrome extension our message passing API will be implemented in a simple background page. We'll be able to use a content script explicitly declared in the extension manifest to facilitate communication with normal content pages.

In both browsers, this scheme will look something like fig 1.

The "privileged execution frame" in fig 1 is the background page we loaded from our browser extension. The "bridge API script" is the script running in that page which implements the privileged side of our message passing system.

The "content execution frame" contains the normal tabbed browsing pages.

However, for good reason, we do not want to give any web page that the user loads into the browser these extended privileges. We only want certain pages that we designate to be able to have access to our message passing API.

To accomplish this, we'll set up a folder somewhere on the local file system to contain our privileged applications. We'll call these mini applications toolpacks. Only pages loaded using the file:// URL scheme from our toolpacks will have access to our message passing API.

The design for our toolpacks will look something like fig 2.

Each toolpack exists in its own folder on the local file system. A toolpack may consist of HTML pages, JavaScript files, CSS, and images. One toolpack will contain the JavaScript file for the non-privileged side of our message passing bridge API (shown in the red in fig 2). As shown in fig 3, toolpacks can access the message passing API by importing it using a script tag in an HTML file. When a toolpack is loaded from a file:// URL that contains a reference to the messaging passing bridge script via a script src="..." tag, the toolpack can use only the privileges given to it by the message passing API. Further, no pages loaded from any other URL scheme (ie. from the Web) will be given the message passing API, even if it tries to load it. There are some additional benefits of the message passing design besides just security (that I promised to talk about earlier). First, we can poach the basic API design from the web worker scheme being specified by the WHATWG clan. Second, the message passing design allows for better concurrent processes within complex applications, sort of like Erlang. As far as I know, this scheme will only work for the Chrome and Firefox web browsers because of their capability to run background pages. To support other browsers we'll probably have to learn some different tricks. So, anyway, that is the basic idea of the design. I'll talk about API design and implementation ideas in later posts.

Setting a Goal. The flag in the distance.

I just thought I would throw my 2 cents into the popular theme of setting goals in the new year.

I think we are wrong to think of goals as an end game. I don't think that achieving a goal has much value. It is the process of getting it that arms you to handle larger challenges in the future.

Don't get me wrong, I'm not against the idea of setting goals for the new year. In fact, I'm all for setting goals any time of year. I just think that we need to focus on why we are trying to achieve our goals, and how we plan to get there. And then, we should reserve the right to change our minds about how we plan to get there, while the goal itself remains a flagpole stuck in the sand way off in the distance, reminding us of which direction we need to ultimately go in.

Some of the tactics we use to get to that flag may not work, and we'll need to revise them. Sometimes we may need to cross a river to get there, and our plans will need to be revised again. This is an important and valuable process.

The flag in the sand keeps us going, but it is the problems we encounter along the way to reach that flag that really make us who we are.

John F. Kennedy understood this when he decided that the nation needed a rally in the middle of the cold war. He made the point well during his "Moon" speech at Rice University. If you have not listened to the speech, you should Google it and listen to the whole thing.

"We choose to go to the moon. We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win."

Your specification documents need to be driven deep into the woods and "eliminated."

Spec docs are just an excuse to pretend that you are doing something important. Nobody really needs them, because all that really matters is that the code ships and people like it enough to use it. Developers who get stuff done don't write spec docs. Sure, they take part in the flame wars on the open standards mailing lists, and they might even write a spec after implementing it, but while all this is going on, the developers that really matter are shipping code at the same time.

The worst offenders are the committees of so called "open standards" people posturing in their academic micro environment. And who is impressed? The users? I don't think so. Doug Crockford came up with the JSON standard all by himself. He even joked in a presentation, calling himself "the one man standards body". I think that's the best standards body I've ever heard of.

Go to this link and read it. Its a walking tour of a mailing list where the early web browser developers are kicking around some ideas for what HTML would become. Go there and read it now, and then come back. You'll notice some ideas on there, some good, and some really bad. But you know what else? Marc Andreesen shipped the code for his browser without waiting for everyone else, and it changed the world forever.

You might complain that HTML doesn't really work very well and needs to be thrown away. But, is the big fat pile of steaming poop called HTML5 any better? HTML5 is the camel created by a committee that set out to create a horse.

Dave Winer recently had this to say in a blog post about the OAuth spec:

If you want to get smart about open standards, you have to watch how these things play out in another open thing -- the market. Because it's the market that just as often shapes a standard as it is a standard that shapes the market.

My sentiments exactly Dave.

I think the best strategy is to take the only the good stuff from open specs and then use whatever you can lay your hands on that will create a minimum viable product the fastest. Don't bother with writing a spec, the code is the best spec you could write. So, let's ship some code this year!