techno.blog("Dion")

As soon as you build richer and heavier applications that have any data or logic on the client, you get into the world of security. Ajax security is a hot topic. On the one hand, the game hasn’t changed at all:

Don’t trust the client!

But we see XSS, CSRF, and other tactics being used to do bad things. With the Gears Database component, we have to think about how safe that data is. Although data on a local machine is a bad thing, we have seen people using encrypted partitions to give some level of security. What if we could have a layer of Crypto in Gears itself? This would mean that a Web developer could use Crypto anywhere in their Web application.

Dojo Offline put encryption on top of Gears. In Dojo SQL you can use a magic ENCRYPT() function in your SQL string and it will be grabbed out and encrypted for you.

“Under the covers Dojo SQL’s cryptography is powered by 256-bit AES,
using the passphrase you provide to derive the key. Specifically, we use
the JavaScript AES implementation given here if you would like to study
how it works; special thanks to Chris Veness for contributing the AES
encryption code to Dojo.”

There are some JavaScript based AES libraries such as ecmaScrypt but the performance tends to be a touch slow. This problem is going away in the future as we see ActionMonkey come alive, as well as other trace based JIT compilers for JavaScript. This is still in future land though, so what about now.

There are some big questions when you really think about what a Gears Crypto API should be:

• How low level should it be? Just a wrapper on something like openssl?
• Should we just put encryption into the existing APIs?
• What are we truly trying to solve here?

In general, when you aren’t sure, you end up getting low level APIs and you sit and wait for developers to built on top of it. This is one area where I would like to see a higher level API. In my experience, Crypto APIs are always too complex and in your face. Often you don’t want to choose a million options. You want to say “Erm, can you just encrypt this really well?”.

Would you like to see a crypto API that you could just use? If so, what would you actually like to see!

Other Future APIs

• Developer Tools
• Factory API updates
• Blob API
• Logging API
• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.

I have talked before about the interesting view that you get from working at a company that has many people focused on its every move.

One of the interesting types of posts are the Bob left Google! ones.

Some people assume that if Bob left, that all hell is breaking loose over in the ‘plex. Of course, if you do the maths and use common sense you see that:

• Google is a large company now. Lots of people are going to be moving on to other things. Shift happens
• Google is a large company now. Many great people are joining
• Google is a large company now. Some people may not want to work for a large company, but prefer the startup thing, or something else.
• Google is a successful company. Let’s face it, some people made insane amounts of money and can afford to do nothing, become angels, or anything else.

In some ways it is great to see a bit of a revolving door. It allows some of the new folks to come in and shake things up in different ways. This will result in great new products, and amazing updates. 2008 will be a great one for Google.

Regarding people that leave, this also doesn’t have to be a bad thing for Google. Hopefully it sends them out into the wild to start other Googley companies with connections back to us.

Nathan Stoll puts it well:

I’ve been comforted by the realization that Google benefits by my departure to tackle new endeavors. Great companies like Goldman Sachs, McKinsey & Company, Procter & Gamble, and GE all consistently turn out leaders in their fields; their employee departures complement the mother ship by spreading the culture and working ethos. Google has many more fine minds joining than it has leaving, and is training them to be technology-focused leaders with a passion for building great consumer focused services.

We realize that to build great applications that use Gears, we need to provide the right tools. From building applications, I have seen how the development cycle is affected by implementing offline support for example. If you are debugging your application you need to create helper methods that can clean up your local database and resource store for example.

There are various tools that have come along to help work with the database, most of them being web based, and some being local tools (e.g. SQLite Manager).

The team wants to offer more development tools for components such as:

• Database
• List databases per origin
• Create new
• Delete
• Interactive DB command line (can just use existing /sdk/tools/dbquery.html)
• LocalServer
• List ResourceStores (and ManagedResourceStores) per origin
• ResourceStore and ManagedResourceStore status (last error, update history, etc)
• command line (like db command line, but pointed at localserver DBs)
• WorkerPool
• Show running workers
• Interactive JS prompt to run JS inside a worker
• Interactive prompt to send messages to a worker
• Logging (requires LoggingModule)
• Show logging in real time as it happens
• Show historical logging
• Sort/filter by origin/page of source page

We also want it to be done via dogfood:

We can implement Gears tools as HTML/JavaScript applications that use the Gears APIs themselves. In order to make the tools available to every application, we should package them with Gears and serve them automatically from a special set of URLs of the form: <origin>/__gears__/<tool_name>. For example:

http://www.rememberthemilk.com/__gears__/databases.htmlhttp://www.rememberthemilk.com/__gears__/show_database.html?mydb... etc ...

Serving the Gears tools from within the origin they are manipulating means that we don’t have to add any special debug override to the Gears security model. The tools can manipulate Gears resources because they are being run inside that origin.

There is a minor chance of the __gears__ keyword conflicting with an existing application. We can make this configurable if people think this is a big deal.

We should reuse the existing Gears APIs to implement these tools. In the cases where there is no Gears API to provide a feature, it would be preferable to add the API. For example, there is currently no API to list the databases for a given origin. But there is an outstanding feature request for such an API. We should implement that API it instead of adding something special just for these tools.

Other Future APIs

• Factory API updates
• Blob API
• Logging API
• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

If you have any other tools that you would like to see, I am all ears.

Disclaimer: This is early days, and who knows what the final API will look like, or if it will even make it. Do you have ideas for cool Gears that make the Web better? Let us know!.

The simple Gears Factory is the front door to all Gears modules. It is about to get a small update that gives you a touch more configurability.

If you have wanted to customize the popup that your users get when first giving permissions to use the application, you can use the new APIs:

• boolean getPermission(siteName, imageUrl, extraMessage): Lets a site manually trigger the Gears security dialog, optionally with UI customizations.
  • siteName: Friendly name of the site requesting permission.
  • imageUrl: URL of a .png file to display in the dialog.
  • extraMessage: Site-specific text to display to users in the security dialog.
• hasPermission: Returns true if the site already has permission to use Gears.

So, nothing fancy here, but if you want to customize your Gears messages, you will be given control to do so.

Other Future APIs

• Blob API
• Logging API
• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is early days, and who knows what the final API will look like, or if it will even make it. Do you have ideas for cool Gears that make the Web better? Let us know!.

Now, the Blob API isn’t going to be something that you will use often, if ever. It is an internal-ish API that other APIs such as the Image Manipulation API will use.

A blob is an object representing file data. It is retrievable, for example, from a resource store or from a HttpRequest or some other source of file data. It can be saved back to a resource store or to a POST request via HttpRequest.

Blob data cannot be accessed from Javascript. Only metadata can be read. Blobs can only be created and modified by other modules.

The external view is simply:

interface Blob {
  readonly attribute int size;
  readonly attribute string contentType;
}

Whereas any Gears module can blob.SetData(otherdata);.

Other Future APIs

• Logging API
• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is early days, and who knows what the final API will look like, or if it will even make it. Do you have ideas for cool Gears that make the Web better? Let us know!.

Steve Souders is known for:

• Chief Performance Yahoo!
• Creator of YSlow
• Some book on Web Performance
• Blood nice guy

The last point is the most important of course. Although it must be fun to say that you are Chief Performance Yahoo! to non-geeks at parties, he has left Sunnyvale, and has head a touch North to Mountain View.

I am very excited indeed to say that he is going to be starting at Google on January 7th, as you can see from the top of his site:

I’m at Google as of January 7, 2008.

I am glad he put a link to Google in there, so we can get the Guice.

It will be great to start working with Steve, even if we differ on some points. For example, he prefers the non-Ajax versions of maps as he thinks they are too slow. Are you kidding me? Do you never move around in the map then?

Lunch is on me on the 7th, Steve :)

I was a touch surprised to read that Gears came in as #1 in the 25 most innovative products of the year.

On the other hand, maybe they saw the potential for upgrading the Web. The potential is really what I see when I look at Gears. The hope for a better Web. We need help from the entire Web developer community, and beyond.

It turns out they really just saw “offline” == Gears, but that will change in 2008. Here is to the future.

Congrats to Aaron, Chris, Scott, Mike, Othman, and the entire Gears team.

Logging is famously over engineered in Java, with huge abstractions. In JavaScript, the majority of folk still use alert() or write out to the Error Console. Of course, those that know, use Firebug and such.

It would be nice to be able to debug throughout the browsers, and inside of WorkerPools in the Gears world. Rather than reinvent the wheel, our Logging module should be as close to the Firebug API as possible:

class GearsLogger {
  // All these methods interpolate _args_ into _message_, replacing occurrences of _%s_.
  debug(String message, Object[] args);
  info(String message, Object[] args);
  warn(String message, Object[] args);
  error(String message, Object[] args);
}

As we see more of these get out there, I hope that we come together and define some simple logging that developers can be assured of. Having to always use Firebug Lite, or define window.console if the object isn’t there, is a pain.

Other Future APIs

• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is early days, and who knows what the final API will look like, or if it will even make it. Do you have ideas for cool Gears that make the Web better? Let us know!.

Once you start delving into the WorkerPool API, you quickly see how a common pattern would be using it as a messaging system. As it stands, it looks like an Open Web version of Erlang processes.

Scott Hess wrote up his thoughts on a more formal Messaging API based on WorkerPool:

Gears WorkerPool has two pieces, the part about running a bit of JS asynchronously, and the part about trading messages with that JS. This API may be composable from more basic bits. The messaging bit could be used in other contexts, such as implementing something like WhatWG’s postMessage().

Aside: What is WhatWG’s postMessage?

postMessage is “a messaging system that allows documents to communicate with each other regardless of their source domain, in a way designed to not enable cross-site scripting attacks.”

Here is an example:

For example, if document A contains an object element that contains document B, and
script in document A calls postMessage() on document B, then a
message event will be fired on that element, marked as originating from
document A. The script in document A might look like:

var o = document.getElementsByTagName('object')[0];
o.contentWindow.postMessage('Hello world');

To register an event handler for incoming events, the script would use
addEventListener() (or similar mechanisms). For
example, the script in document B might look like:

document.addEventListener('message', receiver, false);
function receiver(e) {
  if (e.domain == 'example.com') {
    if (e.data == 'Hello world') {
      e.source.postMessage('Hello');
    } else {
      alert(e.data);
    }
  }
}

This script first checks the domain is the expected domain, and then
looks at the message, which it either displays to the user, or responds
to by sending a message back to the document which sent the message in
the first place.

Back to the Gears Messaging API

Scott gives an example of the messaging API, starting with an end point:

var port = google.gears.factory.create('beta.messageport', '1.0');
port.onmessage = function(port, msg, sender) {
  alert("message: " + msg);
};
port.listen("name");   // Omit for anonymous listener.

and having a way to send it a message:

var port = google.gears.factory.create('beta.messageport', '1.0');
port.open("name");
port.sendMessage("hello there");

To enable cross domain, you can post.open(name, domain), and on the other side, you have to allow it via something like port.allowCrossOrigin(["www.good.com", "www.angelic.com"]);.

I am excited about a messaging API, as I think that it fits into the way in which we are developing new Web applications. Having an asynchronous queue that allows me to replay work (e.g. offline), and work nicely with Comet based interactions, would be great. We can reuse all that we have learned from other event based systems, and Gregor can rename his book and be happy!

Other Future APIs

• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is early days, and who knows what the final API will look like, or if it will even make it. Do you have ideas for cool Gears that make the Web better? Let us know!.

Gregor Hohpe gave a nice report on Google Gears Live From Japan, at a “Google Developer Roundtable” event. Gregor was at the event focusing on Gears and gave a presentation on the topic:

When giving a presentation about Google Gears, what would be better than actually making a Gears application that renders the presentation? That’s what the sample application, that comes with Google Gears, does. It reads a text file into the local SQLite database and renders the presentation from the database records. On slide 10 of my updated presentation you can cache all application resources (e.g., images, JavaScript files, CSS files, etc) in the resource manager and run the presentation offline (naturally, following this link requires Gears). I demonstrated that feature during the talk by pulling the network cable right after synchronizing. Thank god it worked. I hope it shows on the video! I uploaded the presentation application with all supporting files to the code.google.com subversion repository.

He also had some pointers for the future, with a good link to an architecture doc:

Developers also pointed out that the Gears API’s are relatively low level building blocks, making more guidance and advice from Google essential. A recent article on the Gears Architecture clearly points this direction. This is a topic close to my heart. I want to make sure that developing rich and responsive browser apps is not reserved for hard core hackers and JavaScript junkies. While the “competition” (a good friend of mine, actually) has been getting a lot of air time regarding Democratizing the Cloud, it’s equally important for Google to bring Web development to the masses. A little voice in my head tells me that there may be some interesting design patterns for these types of applications waiting to be documented. AJAX Design Patterns is a good step into that direction, but Gears has fundamentally changed the landscape for AJAX development.