The notion of converting conceivably every computer on the planet into a server is certainly not new. But almost everywhere the notion has been attempted, it's been exploited. Microsoft's ActiveX experiment in the mid-1990s was a notorious example of collective inattention to the entire topic of exploitability, though it's not the only one. Since then, millions have willingly made their Web clients into P2P servers in the interest of file-sharing -- authorized or not -- while some of them unknowingly exposed their file systems to the whole planet, exposing sensitive government documents in the process.

History tells us to be skeptical when any software purports to enable ordinary computers, especially Web browsers, to act as servers. This morning, Opera Software unveiled its Unite server networking protocols, which consist of extensions to the existing widget system for its Opera Web browser. The objective there is to enable any Opera user to be a server in her own right, potentially serving up blogs, tweets, and files. Opera's own bank of servers -- which are already put to use providing pre-rendered pages for its "Turbo" feature -- serves as an intermediate proxy for all communications between Unite-enabled browsers.

Within minutes of our posting the news, Betanews readers expressed their time-tempered skepticism. As user zealus.com put it, "A united botnet owners community has released their statement where they thank Opera developers for making their lives extremely easy."

As an organization that professes strict adherence to international standards, Opera should be mindful of standards supporters' desire for strict security. But an initial read of the company's extended APIs has left us with a number of questions -- which we put to Opera Software directly this morning. The biggest question we have is whether the Unite APIs expose users' file systems...a question that still merits asking even after having read the documentation. As the security model indicates, no Unite user has access to any other user's file system directly. Instead, each user acting as a server builds a virtual picture of its file system on Opera's proxy servers, generating so-called mount points to which clients are given access.

"The FileSystem class...is a virtual file system," reads Opera's documentation for the Unite File I/O API. "In order to actually use it, you'll need to add directories from your actual file system as mount points to the virtual file system."

For now, all Unite-capable programs are Opera widgets. So whether a widget exposes mount points depends on whether its config.xml file includes a reference to the File I/O API. That reference includes a parameter that points, by default, to a designated shared folder. This may be some folder that the Unite server widget designates as being safe to share with others. However, certain shortcuts have been provided for this parameter -- shortcuts which lead directly to system folders in Windows, Mac, and Linux, according to Opera's documentation. These folder hints are home, pictures, music, video, documents, downloads, and desktop. According to Opera, home may point to a Windows user's "My Documents" or "Documents" directory; and documents may point to an Ubuntu Linux user's "Documents" directory. The File I/O parameter may include any or all of these folder hints.

Now, the Unite widget only exposes what this parameter permits the Opera proxy to expose through the virtual file system. However, according to the documentation, the level of access the end user has to that file system is determined by the corresponding level of access in the Unite server's physical file system. And according to a warning in the documentation, the job of securing that system is effectively left up to the developer.

"WARNING: Once mounted, the mount point will be read-write unless the underlying file system defines it to be read-only," the documentation reads. "Be careful to protect your data by controlling how data gets written to them. You should supply some sort of authentication of users who access these directories and be careful to not leave code open to exploitation."

As a spokesperson for Opera told Betanews this afternoon, "Opera Unite conforms to a secure sandbox security model. The services do have read-write privileges to any folders (and sub folders) the user grants access to. This access is restricted only to that folder, and nothing outside the specified folder. Moreover any and all services you download from http://unite.opera.com go through a quality check, done by the [quality assurance team] at Opera."

Whether changes to the virtual file system are always translated by the proxy back to the Unite server wasn't specified in the documentation, though it is clear that deletion is an option, for mount points whose access allows this. Again, the parameter for setting mount points to specific directories, or to shared or system directories, is specified in the Unite widget's config.xml file -- a file typically distributed with Opera widgets, and which may be guessable. Access to the file system by a widget is a major deviation from the existing Opera widget security model, as updated in May 2008.

But the file itself will be shielded from access by the Unite widget or any other widget, as Opera's spokesperson told Betanews. "The config.xml...is hidden away from the Unite protocol and other Web protocols that the browser responds to. It cannot be altered by any unsolicited requests."

Next: Could an Opera user become an unwilling file sharer?