For the past month, I've been writing about the similarity between the iOS document model, and that of most modern web applications. After acknowledging the strengths of the iOS document model, last week I addressed the danger that such a similarity poses for the future of web applications.
Although we don't want to go wholeheartedly down the iOS route of walled garden filesystems, we can still learn from their efforts and successes.
So... what is there to learn?
Security
Security is perhaps the most difficult to address, so let's start with it. The strength of the iOS document model lies in getting users to actively indicate that they want to transfer control of a specific document between applications, rather than passively accepting that an application wants to access/change a document. This is a critical distinction, because it forces the user to make a conscious decision to grant permissions instead of just rubber-stamping a request that pops up.
Can we do something similar for web applications? Part of the answer to this question depends on how we address the challenge of a web-application filesystem. There's a huge space of possibilities here, so I'm going to adopt the most general form possible: There are three entities/trust in the system: your browser, one or more sites that hold your data, and one or more sites hosting the web applications you use. They don't have to be separate, but I'll think about them as being so to keep things simple.
Practically speaking, there are two separate levels of authorization to grant: access to read the data, and access to modify the data. Let's break things down and address each in turn.
Read access is easily the harder of the two to pin down, mostly due to limiting the scope of access. Let's say I have a web application for email/messaging and a second application with my address book. Clearly, the email client could make use of the address book data. The absolute wrong way to do this is for the email/messaging application to put up a dialog box saying "Can I have access to your address book data?" I'm not just talking about authorization issues here; Even gimmicks like Facebook/Twitter's application authorization tokens essentially boil down to the same thing: "Click button in order to use software".
We need to get users to consciously decide that they want to transfer data between applications. In its simplest form, this means, from within the address book application (or the filesystem storing the data) clicking on a standardized widget to "Open this data with email client".
Even this though, is somewhat awkward. You don't want to have to do this every time your address book data changes, and you might not want to grant access to your entire address book.
A second option would be to use the drag/drop metaphor. Dragging contact information from one web application to another is a clear indication that a user wants to transfer access to the contact to the email application. Still, this is somewhat awkward. It would be nice to have address book support within the application itself.
HTML/Javascript provide us with a third option. Javascript provides us with a (securable) framework for importing widgets from one codebase into another. I'm not sure how a secure implementation of this could be properly developed, but you could use javascript to modify the email application's text input field to pop up an autocomplete panel. Selecting an autocompletion would be an explicit choice on the user's part to pass the contact information over to the email client. Of course, now we've just reversed the problem -- This approach means that you need to find a way to get the user to agree to the address book modifying their email client. Furthermore, browser security being what it is, you want some way to guarantee that the address book javascript code doesn't have access to the application state.
Ok, that was a bunch of blathering about read security. In most cases, an approach analogous to the traditional filesystem approach suffices: double click a document to open it, or bring up a widget that's part of the filesystem, which grants access to the selected data. Any application-specific state can be kept separate, and inaccessible to other applications.
So what about writes?
I don't have a particularly good answer here. The problem is that you don't want one application to do something to your data that breaks another application's functionality. In part, this can be solved by keeping application-specific metadata separate from common state. Most likely, the best approach here is to keep state in versioned form, like a distributed revision control system (e.g., GIT). If an application breaks something or deletes something, you provide the user with going back and undoing some or all changes performed by the offending application. This approach works reasonably well for Wikipedia, which is subject to a similar attacker model.
And, as expected, I've gone pretty crazy with this discussion of security. I'll wrap up for real next week with a discussion of the remaining three (smaller) points: Interface Formats, Presentation, and Non-Document Data