Safe General-Purpose Local Storage Mechanism for RIAs
The problem I have with “cloud” computing is that I’m too possessive. When I purchase software, I pay the extra money to have the physical DVD shipped to me. The reason I do it is because I have a sense of ownership in the applications I buy (Yeah, I know, “license”, not “buy”). That sense of ownership is even stronger when it comes to my data. I don’t want my data off in internet-land, where if the company hosting it goes out of business or gets acquired, I find myself paying $49.99 per month for access to it, or worse, lose it. I also have a fear that my data could be mined or exploited. I can’t possibly be the only one that feels this way.
So how do we create a safe general-purpose mechanism for accessing persistent local storage from web applications?
The Google Gears approach is to create a server to be run on the client’s machine. Then, the user is running a web application from a server hosted locally. I’m by no means a Gears expert, but I feel it becomes a slippery slope to ask end-users to run servers on their desktops. Savy end-users will no-doubt understand the risk of opening up a port to the public, but many will not? I think the Gears server blocks direct public access, but couldn’t any arbitrary web page embed a reference to the local Gears server, and use client-side scripting to expose the file system? The only way to safely protect it would be to limit the capabilities of the Gears server. This is a less-than-ideal solution because it imposes a limit to the capabilities of all RIAs. At the very least, this approach will be incompatible with many corporate infrastructures.
Even if Gears manages to get all of the kinks worked out of their security mechanism, there is still one enormous problem with their approach; it’s not a general-purpose solution. Gears appears to provide it’s functionality via a fairly extensive JavaScript API. Don’t get me wrong, there’s absolutely nothing wrong with JavaScript. But I don’t want to be writing some of my business logic in JavaScript, and some of it in another language.
I’ve considered writing an application that ran in the browser and provided programmatic access to the file-system, either through a plug-in or via a Java applet. The Applet would be cool because the user wouldn’t have to install anything, but just grant authority to the Applet when the page loaded. On the other hand, many users would be confused by this request each and every time it loaded. Not only that, you don’t necessarily know what applet is requesting permission, so it wouldn’t be good to train users to grant full permission to any old arbitrary public web page.. Plus, an Applet would need to be downloaded to the client machine every time it was utilized (cached for each web page utilizing it?).
A plug-in would be a better solution. Once its installed, it doesn’t need to beg for permissions. As long as its provides safety from being hacked, life will be good. But now, the question becomes, “how do we make it hacker-proof”?
If you think about it, we already have a fairly safe File-Upload component. So why couldn’t we employ the same strategies to create a Data-Save component? What makes the file-upload component safe is that the user is provided a familiar component that is (1) easily recognizable, (2) can only be manipulated by the user and not by code.
Today I had an idea. Every browser-based technology I can think of provides intercommunication with JavaScript variables. This means that we could use JavaScript variables as the mechanism for storing and recalling data. It would work like this; A plug-in could be created that is able to load and save the state of a particular JavaScript object, lets say for purposes of discussion, an object named “StateSpace”. For instance, if we had an application that wanted to save off the coordinates of a 2D point, it might set StateSpace.X and StateSpace.Y.
The plug-in would then provide a user interface that appears on the user’s browser as shown in Figure 1.
Figure 1: The proposed StateSpace interface.
To prevent a web application from directly accessing the local file system, there would be no programmatic access to the functions that save and retrieve data. All file interaction would be controlled exclusively by the user via the StateSpace UI. This prevents the plug-in from being used to bamboozle users into exposing their file system. Not only that, but only ASCII files in JSON notation could be loaded. An attempt to load any other type of file would simply fail.
The RIA developer embeds the Flash, Silverlight, JavaScript (,etc) application into the HTML of the web page, along with the StateSpace object. The embedded object would provide the UI (Figure 1) in a window in much the same way that an embedded Flash object does. The beauty of this arrangement is that the StateSpace plug-in would be instantly recognizable to the end user since (1) it has its own unique interface, and (2) it would appear on the page of all StateSpace-enabled web applications. Users would immediately recognize when an RIA is able to save and load data via StateSpace, and trust that it will be safe.
To help visualize this better, imagine a spreadsheet RIA written in flash (A possible RIA replacement for Microsoft Excel). The flash application would save off the data within each of the cells to the StateSpace JavaScript object using its own strategy. For instance using two-dimensional arrays to hold the state of each of the cells. The user could save off the state of these JavaScript variables using the StateSpace plug-in by clicking on the [Save] or [Save As] buttons on the StateSpace interface within the browser window. Later, the session could be recalled upon returning to the web page by clicking on the [Open] Button withing the StateSpace interface.
To make this work, three additional issues must be addressed;
(1) The user should be able to identify whether or not there is unsaved data simply by glancing at the StateSpace UI. There must also be a JavaScript function, for instance isSaved(), that returns a boolean value. RIA Developers could then check the value when the page is being unloaded, and warn the user that unsaved data will be lost if they navigate away.
(2) The StateSpace UI would have an INFO button that would provide access to various metrics about the JavaScript object available to be saved, most importantly the amount/size of the data-set being saved. It could have an options panel where the user could set a maximum size-limit so that a warning message would pop-up if the object exceeded a certain size (for instance 1 megabyte).
(3) The StateSpace UI would automatically associate data-sets with the URL from which they were saved, so that the user knows which data-sets go with which URLS, and can easily retrieve their data from a prior session. Obviously, it would also need to allow users to open data-sets created from different URLs too, if they desired to do so.
The StateSpace strategy would allow quite a bit of flexibility. A StateSpace enabled application could organize the JavaScript variables however it see’s fit. For instance the application could have its own internal mechanism for subdividing data into “projects”, etc. I would imagine there would ultimately be JavaScript libraries that simplified this task.
Please help me to identify any possible weaknesses or exploits. Will it work? Am I missing anything? Please comment (either publically or via email).