HTML5 in the browser: Local data storage

HTML5 Web Storage, Web Database, FileReader, FileWriter, and AppCaching APIs will transform Web pages into local applications, but not yet

Page 3 of 5

The indexed storage also includes the ability to execute the changes as transactions, eliminating the questions about race conditions that may bedevil the localStorage object. This may warm the hearts of database programmers, but it may be too early to know exactly what to expect. The version of the draft I read while writing this includes the line, "TODO: decide what happens when dynamic transactions need to lock a database object that is already exclusively locked by another transaction." There are many details to work out.

HTML5 File API: FileReader
The final apostasies in HTML5 are the FileReader and FileWriter objects, two devices that reach outside of the browser's sandbox and actually touch the file system. It's one thing to offer the JavaScript programmer the ability to store objects from trip to trip, and it's another to let them have access to functions like readAsBinaryString.

The File API is not widely implemented yet, but it promises to dissolve the wall separating the "personal" part of the PC with the "inter" part of the Internet. There's even an updated scheme to make all of the file://C: URIs behave more like distant websites. JavaScript will see fewer differences between loading a local file and downloading data from a distant website with an XMLHttpRequest call.

The details of this API are still missing. The spec is filled with useful suggestions like, "System-sensitive files (e.g. files in /usr/bin, password files, other native operating system executables) typically should not be exposed." Well, duh -- but notice the use of the word "should." The spec suggests that the browser "may" raise a SECURITY_ERR. The details are still in flux, and I don't think anyone knows what may come of opening up this Pandora's box. Perhaps the Web applications will routinely need access to the /usr/bin directory and all of the SECURITY_ERR events will drive the user mad. We can't be certain.

HTML5 File API: FileWriter
If the FileReader API sounds like a recipe for massive privacy invasions, imagine what potential evil lurks in an API with the name FileWriter. Presumably there will be much good as well, including the ability to simplify the installation of new software. We can only hope.

The design of the FileWriter API is similar to all the other File APIs. You create a block of bytes called a Blob, pass it to a FileWriter object, and invoke the append or write methods. The next thing you know, your disk is filled with viruses. There are also mechanisms so that the viruses can choose between installing themselves synchronously or asynchronously. The data can be found inside the file with offset methods like seek.

The jokes about the viruses should remain jokes if the security model works as planned. Although the draft spec doesn't say much about the security model, it looks as if the goal is to give the average user all the rope they need to tie themselves up and hang themselves inadvertently. The browser will pop up a search box and ask where the data should be stored. Sensitive areas of the OS will probably be off limits, but I still wonder about the damage that could be done with supposedly safe sections. Imagine, for instance, an application that can write a block of bits to the Desktop directory and give it the name "Click Me." What percentage of the world can resist a message like that?

We can hope that the browser builders will move slowly with this tool. Perhaps they'll leave it disabled until a user decides to opt in through the preferences interface. Ideally, they'll bury the access even deeper as Mozilla does with the preferences hidden beneath Firefox's about:config menu.

| 1 2 3 4 5 Page 3