WebShell is a free, open-source, private and secure alternative to commercial cloud storage and web-based software. It's a web desktop which can be self-hosted on your server to provide access to your files and apps from the web.

To the user, it provides a remote desktop right in the browser, with a familiar UI - a file manager and apps that can open and edit different file types. Files can be created, edited, shared and published in a single trusted and private space, without using corporate cloud services.

To the app developer, it provides a minimal and easy-to-implement API for opening and saving file content, without giving the app any access to, or reasons to worry about, the file system.

The project will deliver:

• API documentation for the file system, web app and low-level message channel APIs
• a virtual file system with plugins for server FS, FTP and SFTP
• a file manager app for browsing and operations on files
• a window manager for apps, with each app running in a sandboxed iframe
• a file menu with all file operations for app windows
• an app dock and launcher
• a JS library for web apps
• a simple IDE for web apps
• starter web apps to seed the ecosystem

Show me something, now

We have prototyped most of the technologies needed in the project before:

• An (ancient) proof-of-concept. It demonstrated that a full-featured desktop can work in the browser. See http://desktop.ljudmila.net
• A newer demo (a tab-based desktop, no window resizing). It implements the concept of separation of files and apps. Its file system can only save to the browser's local storage, but it has all the essential file menu functionality and dialogs. The included apps are therefore trivial (see their source). See https://south-tooth.glitch.me
• A preliminary attempt to define the required APIs. See various files at https://github.com/zocky/web-shell-api

About the project

The corporate cloud is gradually replacing the personal computer as the place to store and edit files. While this provides many conveniences to users, it also removes their control over their data.

Our aim is to return user files and applications to the user's computer and under the user's control, while allowing all conveniences of cloud-based file storage and web apps.

In the long term, we share the common dream: a mini computer that simply plugs into your home network and automagically configures NAT, DNS, SSL so it is immediately accessible from the web. It should know how to federate with other servers (i.e. your own, or those of friends, family, colleagues) to provide secure peer-to-peer services like mutual backup, file sharing and syncing, social network functionality, etc.

In the short term, we will concentrate on producing a solid first version of the core software needed for self-hosting files and apps, immediately installable on any computer, and working independently.

This will include:

• a virtual file system with plugins for server FS, FTP and SFTP
• a file manager app for browsing and operations on files
• a window manager for apps, with each app running in a sandboxed iframe
• a file menu with all file operations for app windows, including dialogs
• an app dock and start menu
• a JS library for apps, which connects to the desktop, and provides hooks for handling file opening/saving

In addition, we will:

• provide a set of basic apps (text editor, image viewer, simple IDE for apps, etc)
• integrate a selection of existing high-quality web apps
• allow publication of individual files and folders (i.e. rudimentary web hosting)
• allow passwordless sharing of individual files and folders with single-use login links sent through email

Note: In this project, we're focusing on single-document applications and file menu operations. There are other types of applications (e.g. project editors, which need access to a whole directory) and services that an app can provide to WebShell (e.g. navigation, clipboard operations, etc). All APIs and components will be designed so that they can be expanded with these features in the future. Any of these additional features that prove easy to define and implement may be included in the project.

Key Insight - Apps Don't Need Permissions

In the classical model, the OS (or its equivalent) provides a file operations API to the apps. The apps are granted permission to access particular or all files, and the developer implements file operations for his app.

In our model, there are no permissions. Apps have no access to the file system. Instead, WebShell provides the complete file menu and file dialogs to the application and performs the actual reading and writing of files. The app simply responds to the resulting open and save actions by deserializing the provided data (which WebShell has read from a file) or serializing and returning its current state (which WebShell will save in a file).

This provides the following benefits:

• Increased security - the apps get access to content on the need-to-know basis
• Decreased burden on the user - the user doesn't need to decide and track which file permissions they gave to which app
• Much simplified development - the developer gets the solution to one of the hardest problems completely for free and can concentrate on the actual functionality of their app

Background

Files

For many users, the web has replaced their hard disks or removable media as the place to store and access their files. The convenience this offers is offset by the fact that your data is stored on a corporate server, beyond your control and with questionable privacy protections.

The existing alternatives, e.g. SFTP to your own or your organization's server(s), are relatively convenient for Linux users when they are on Linux devices, but are severely impractical even in Windows, let alone on various touch devices, where they are not provided as a built-in option, and require installation of software which provides only limited functionality.

The first goal of the project is therefore to provide convenient access to your files on the web, i.e.a fully functional file manager for the browser, based on a virtual file system in which folders from your server or other sources (FTP, SFTP, cloud services) can be mounted.

Apps

Files are useless without applications that can open them for viewing and/or editing. Remote files can be downloaded to the local disk, opened in a locally installed application, and uploaded back.

But web-based applications are more convenient both for the user and the developer, because they work on any computer with any operating system, and don't need to be installed in a way that could harm your computer. Many commercial applications are moving to the web, and very many users already use "free" corporate web-based applications for editing their files.

In addition to commercial/corporate web applications, there are numerous high-quality open-source web-based viewers and editors for various documents, but few are widely deployed. The main obstacle to their routine deployment is implementation of data storage and sharing between apps.

Many projects have stalled at this point, because further development requires either:

• complex coding of backend storage and authentication, which is outside the comfort zone of many web app developers, and prevents sharing of data with apps from other developers, or
• a commitment to working with a particular set of commercial cloud services (which still requires acquiring and deployment of API keys, so the app cannot simply be installed and used).

So in practice, most advanced open-source web apps are only accessible at a small number of websites, which either sell storage space or force the user to store their files on one of many cloud services and give the website permanent access, often to all of the user's files. The result for the user is account/password hell and loss of control over their data and who has access to it.

The second goal of the project is therefore to provide an easy-to-implement API that will allow web apps to open and edit user files, without giving the app permanent access to the particular file or any other user files.

Core concepts

WebFS

At the core of WebShell lies WebFS, the virtual file system. It defines the WebFS API which provides for file and directory operations.

WebFS doesn't store any files itself. It allows connection and mounting of local (i.e. in-browser) and remote (your server, SFTP/FTP connections, cloud services) file systems through File System Adapters, to which it delegates all file operations.

FS Adapters are loaded in sandboxed iframes (separate iframe for each connection) and are isolated from the rest of the system. They provide for authentication with remote servers and implement WebFS file operations on them.

What's In An App

An App is a webpage which is loaded in a sandboxed iframe and knows how to communicate with WebShell. When it is loaded, it establishes a secure connection to WebShell through a browser window message channel. It describes its capabilities (i.e. which file types it can open/save/create), and WebShell provides the appropriate file menu functionality to the user.

For the developer, integrating an app with WebShell consists of:

• including the WebShell app JS library
• registering a hook for deserializing (i.e. opening) a file for each supported file type
• registering a hook for serializing (i.e. saving) its current state for each supported file type
• nothing more

Isolation of apps and files

Apps are not aware of WebFS. They are provided with file contents only on a need-to-know basis, i.e. when the user chooses to open a particular file in the particular app. When the user chooses to save the file, the app returns the content that will be saved, again without direct access to the file system.

Isolation of components

All shell components are encapsulated and self-contained and can only communicate with other components through defined messaging APIs. This prevents any unplanned or undocumented dependencies between components.

Non-core components (i.e. FS adapters and application windows) live in separate sandboxed iframes and and communicate with parent components through window message channels. This prevents cross-process data access and data leakage.

The relationship between components is hierarchical. Parent components load, unload and control child components. Child components can only send events to parent components, which parent components may choose to react to or ignore. This enforces consistent data flow and permission checking.

WebFS is fully virtual

In addition to regular file stats and operations, FS adapters can provide additional information about files (e.g. image dimensions) and custom file operations (e.g. flip image) that are implemented on the remote server.

FS Adapters can provide access to actual file systems or to virtual file systems that represent other system resources, e.g. tables in your database, or service daemons running on your computer. In the future, this can be used to provide the user with advanced remote control over their computer's system resources within the familiar UI of the file manager.

What makes us different

Unlike most other web desktop projects, we're concentrating on fundamentals and security. Our aim is to provide a solid and secure, but minimalistic, set of APIs that are essential for a web desktop to work. All components live in sandboxed iframes, and all communication between the desktop, the file system and the apps is conducted through window message channels. This prevents any cross-window JS access or data leaking.

Unlike other web app ecologies, our security model isn't based on giving permissions to apps to access various areas of your system and data. Apps cannot operate on your files directly. Instead, they are opened and saved by the desktop itself at user's explicit request, and apps simply deserialize the file content or serialize their current state when requested. This both completely prevents unauthorized access to user data from apps, and frees the app developers from a large amount of complex, repetitive and bug-prone work.

Unlike projects like Firefox OS, we're relying exclusively on existing and widely used web technologies. We're also not aiming for a complete replacement for your OS, which reduces our workload to a manageable size.

Unlike OwnCloud and similar projects, we're not imposing a complex development environment on app developers. WebShell apps don't need any access to the backend, don't need to understand how storage works, and don't need to be programmed in PHP. Integrating an existing web app in our model can be accomplished in two lines of code in client JS.