Right now we’re seeing stuff happening in the webbrowser that starts to go beyond the traditional web application. I’m talking about things that make either the browser itself or the interaction between different web applications a richer experience.

On the browser side, the basket of technology commonly referred to as HTML 5 falls into this category. It makes the browser a much more powerful client, thus rebalancing a lot of weight between web server and client to an IMHO much more natural equilibrium.

On the web application side we are seeing are starting to see lots of interesting application mashups, thanks to technology like OAuth and cross-origin AJAX hacks. Facebook’s recent innovation, the social graph and the ability to embed it into other applications, is a powerful example.

As many have noted, there are huge problems with this and they all have to do with security and privacy. Virtually none of the technologies coming forward under the HTML 5 umbrella help with security. Yes there are some attempts to fix one of the most backwards security policies in the browser. But these are mere sticking plasters over oozing flesh wounds.

Weaving a richer web

As I’ve written here before, I think we need a browser designed for the cloud. Back then I was mostly speaking in terms of usability and explicitly ignored the privacy issue. It think it’s time to come back to that now. With HTML 5, we’re giving the browser many ways to be a richer client. But in terms of user data, we’re still treating it as a dumb terminal.

Weave, a Mozilla Labs project, has a different vision. Its broad idea is to create a richer web experience while still having users control their data. Concretely, the Weave Sync service allows you to synchronize your tabs, history, bookmarks, settings and passwords between different browsers. And here’s the thing: the data is all encrypted, on the client. All that Mozilla is storing on their storage nodes (which you don’t have to use, by the way) is a bunch of encrypted JSON.

Sure, you may be saying, that’s great for making Firefox a richer browser, but how does that help the general web?

Well, it turns out that doing RSA and AES cryptography in JavaScript isn’t such a far fetched idea at all. With some inspiration from an abandoned project, I was able to hack together a (very rough) version of Weave Sync for Google Chrome. Since it’s entirely written in JavaScript, it actually works in any browser.

See for yourself. (To try it out, you need to create a Weave account with some tab data in it, e.g. by installing the Weave Sync add-on in your Firefox and syncing your tabs).

Sure, you may be thinking, encryption is great for dealing with personal data, but it would be impossible in a social web. What if you wanted to share your bookmarks with other people?

Well, is it really that impossible? Let’s look at what Weave does. In a nutshell, it encrypts your private data with a symmetric “bulk key.” This bulk key is stored along with data on the server, but in encrypted form: encrypted with your public key. That means to get to your data you’ll need your private key to decrypt the bulk key which in turn can then decrypt your private data.

If I now wanted to share my bookmarks with you, I could simply give you my bulk key by encrypting it with your public key. Job done. You can see my data (and only the data I’ve encrypted with the particular bulk key that I’m sharing with you), but nobody else can. Not even Mozilla.

I know, sharing bookmarks is so 1998. But it’s essentially the same thing as the Like button (or the LUUV button). Or your address book. Or your whole social graph. Point is, we no longer need the server to do the heavy lifting for us because the browser environment is getting richer — be it the HTML templating, session storage or even cryptography. The server can become a dull data storage that we can scale the heck out of and, more crucially, potentially ditch for different one if you like. While all the data is in the client’s hands and leaves it only in encrypted form.

This is the kind of cloud I can definitely get on board with.

Today I had one of those it-came-to-me-as-I-was-under-the-shower moments. For some reason, a conversation from a couple of months ago popped back into my mind. Somebody had asked me about associative arrays in JavaScript. To which I simply replied something like, well, they’re just there, built into the language. Just use an object! You could technically even use an array (since JS arrays aren’t really arrays but hash tables with string keys whose strings happen to convert to integers), but that’s not a good idea for various reasons.

This morning I realized that my answer wasn’t entirely complete. Objects work fine as associative arrays a.k.a. hash tables a.k.a. dictionaries if your keys are strings or can be uniquely converted to strings (in which case you could write toString() methods for all your objects you want to use as keys.) Python is a bit less restrictive with its dictionaries and requires that your object be hashable. Immutable built-in types like strings and tuples are hashable, so as long as you can find a one-to-one unique mapping to those (and implement that in __hash__()), you’re good. The advantage of this system is that string representation and hashing aren’t mixed into one interface.

The good news is that thanks to the concept of object identity (present in both JavaScript and Python), you can actually write an associative array that accepts arbitrary keys:

function dict () {
    var keys = [];
    var values = [];

    return {
        get: function (key) {
            return values[keys.indexOf(key)]
        },

        set: function (key, value) {
            var i = keys.indexOf(key);
            if (i === -1) {
                i = keys.length;
            }
            keys[i] = key;
            values[i] = value;
        },

        del: function (key) {
            var i = keys.indexOf(key);
            keys.splice(i, 1);
            values.splice(i, 1);
        },

        keys: function () {
            return keys.slice();
        },

        values: function () {
            return values.slice();
        },
    };
}

I’m not going to bother with a Python implementation because it would look almost identical (modulo syntax). Also, if you find yourself wanting to use something like this in Python, you’re probably doing something wrong. Python’s dictionary implementation is insanely fast and the range of immutable types (strings, tuples, frozensets, etc.) should be sufficient.

And come to think of it, so far I haven’t felt the need for something like this in JavaScript either. But it came to me under the shower, so I had to write it down.

A few months ago I wrote a post about JavaScript titled Curly braces are not the problem wherein I pointed out one of JavaScript’s biggest weakness, the new operator and how to spell an object constructor as well as methods on the corresponding prototype. Some commentators mistook that post for critique of the prototype model itself. It was far from it, I think the prototype model is great, just the spelling was awful. Consider this:

function MyObject() {
    /* constructor here */
}
MyObject.prototype = {
    aMethod: function () {
        /* method here */
    }
};

which is alright until you now want to inherit from this and add methods:

function YourObject() {
    /* constructor here */
}
YourObject.prototype = new MyObject();
YourObject.prototype.anotherMethod = function () {
    /* another method here */
};

There are several problems with this. First of all because YourObject inherits from MyObject, it has to be spelled differently. Secondly, we can’t reuse the constructor, at least not without resorting to func.apply() tricks. Thirdly, we have to know what to pass to the constructor of MyObject at definition time.

It turns out, Doug Crockford not only agrees with me on this but also has come up with a better way. Back in January I thought that we needed more syntax to fix this, but it turns out we need less (by which I mean ditching the new statement). In Vol. III of his excellent Crockford on JavaScript lectures, he defines a constructor maker:

function new_constructor (extend, initializer, methods) {
    var prototype = Object.create(extend && extend.prototype);

    if (methods) {
        methods.keys().forEach(function (key) {
            prototype[key] = methods[key];
        });
    }

    var func = function () {
        var that = Object.create(prototype);
        if (typeof initializer === 'function') {
            initializer.apply(that, arguments);
        }
        return that;
    };

    func.prototype = prototype;
    prototype.constructor = func;
    return func;
}

I’ll let you work out the details of this yourself and instead just show you how you would define the equivalent of the two cases above:

var new_my_object = new_constructor(Object, function () {
    /* constructor here */
}, {
    aMethod: function () {
        /* method here */
    }
});

var new_your_object = new_constructor(my_object, function () {
    /* constructor here */
}, {
    anotherMethod: function () {
        /* method here */
    }
})

See how symmetrical both forms are now? And if both object constructors really were were to share the same initializer, I could easily define that as a separate function and reuse it.

Btw, if you do any sort of web development, I highly recommend you watch the Crockford on JavaScript talks. They’re not only entertaining but are an excellent lesson in history of all the technology that makes up the web.

Follow

Get every new post delivered to your Inbox.