Browsers are rapidly becoming the tool of choice for all sorts of desktop activity. And "Web 2.0" technology is making browsers even more important than they already are. As you know, browsers typically rely on Uniform Resource Identifiers (URIs) to locate various types of resources. The first part of a URI is called the scheme. The most commonly used schemes are http and https, which are used to locate content that can be accessed via the Hypertext Transfer Protocol (HTTP).
At this time there are over 50 schemes (see the URL below for details) that a given browser might know how to handle. In addition to http and https, some of the more popular schemes also include ftp, file, mailto, and news. Then there are several other schemes that you've probably seen in use at some point or other, including javascript, ldap, nntp, and chrome (the latter is common for Mozilla-based browsers).
esw.w3.org/topic/UriSchemes
Recently Opera Software submitted a draft proposal to the World Wide Web Consortium (W3C) that may or may not become accepted as an official W3C Web API working group draft. The proposal calls for the creation of a new Web application programming interface (API) in Web browsers, called File I/O, which in turn will use a new URI scheme called mountpoint. The purpose of the API is to create an abstract method for Web applications to interact with a computer's local file system in a sandbox environment. The API would be compatible with various file systems without the need for any knowledge of which file system type is actually in use (e.g., FAT, FAT32, NTFS, EXT3, ReiserFS).
As it stands now (and this could change, assuming the draft is accepted by W3C), the API would let a Web application and its user browse, create, read, write, copy, and move directories and files. The API would allow the creation of mount points and those mount points could be made persistent across restarts of an application.
Based on what I've read in the draft, there would be some amount of protection in place to prevent possible mischief. For example, the API would need to ensure that a user actually took physical action via the keyboard or mouse before allowing various types of file I/O activity to take place. That level of protection would help defend against automated file access, typically perpetrated via URLs, scripting, and other technologies. While there is no detail about how the API's sandbox would be maintained and controlled, we can assume that considerable efforts will be made to ensure overall system security.
But, we've seen sandbox-related file access problems in the past in various browsers. Since people have discovered ways to escape sandbox environments we've had to endure all sorts of related exploits. That's exactly why I bring this API draft to your attention.
If the draft is accepted and development begins on a formal specification, then without a doubt we'll see this new URI scheme and its underlying functionality rolled out into popular browsers. And thus, we'll also see the URI scheme become commonplace in Web 2.0 applications. And you know what that means: We'll inevitably see bad guys find chinks in the API's armor, which nearly always leads to malicious exploits.
So, if and when the API goes into formal development you'll have a whole new level of security concerns to add to your heap, and while that heap is probably big enough already we'll all still have to address these new concerns in one way or another.
If you're interested in reading about the proposed File I/O API you can do so at the first URL below. And while you're there, have a look at some of the other proposals at the second URL below, especially the FileUpload, Clipboard Operations, and Network Communications API proposals--each of which poses other potential browser-related security considerations.
dev.w3.org/2006/webapi/fileio/fileIO.htm
dev.w3.org/2006/webapi/
Register
