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 yetFollow @peterwayner
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
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
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
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
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
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.