Note: this article is a very early draft and limited to a conceptual level. There are no implementations around so far, although a reference implementation might be implemented in a near future. Suggestions are welcome!
Background
The World Wide Web (retroactively called web 1.0) was originally conceived as a convenient way to read documents by the use of a combination of HTTP over TCP for data transmission and the HTML language for content, using specialized software called “web browsers”. Soon after, a scripting language called JavaScript was designed to allow dynamic behaviour on such documents.
Fast-forward a couple of decades later, and today a web browser handles a never-ending list of responsibilities over your computer, including:
- GPS location;
- Bluetooth;
- Accelerated graphics;
- Virtual reality;
- A rendering engine (CSS);
- Audio and video rendering;
- Microphone and camera access;
- A WebAssembly runtime;
- A JavaScript runtime that ties all together.
In few words, a web browser strives to become a operating system, running on top of another operating system. Writing a modern web browser nowadays from scratch is such an incredibly complex task that only three major implementations are catching up with current standards:
- Firefox (which unfortunately loses market share everyday) and its derivatives;
- Webkit;
- Chrome and its derivatives.
Not to mention the staggering amount of resources usually required by them, modern web browsers are driven by corporate interests rather than efficiency, safety or maintainability. For example, web browsers automatically download and run unverified JavaScript. Even if the source code for a website can be downloaded, it is often obfuscated and “minified” and hence unreadable for humans.
This means proprietary, obfuscated code that harms users is able to run on their computers without possible prior user verification. This situation leads privacy and safety-concious users to disable JavaScript on their web browsers in order to reduce attack surface. Unfortunately though, disabling JavaScript breaks most websites.
While the World Wide Web arguably has had a great effect on human society and deserves recognition for this, its scope has went way too far for mere mortals to catch up, even without mentioning whatever this new Web3 fuzz might suppose.
So, instead of writing a document viewer that pretends to be an operating system, why not use the operating system?
Overview
The Native Web aims to achieve the same level of convenience the World Wide Web currently offers, with the following substantial differences:
- Make TLS-encrypted connections by default;
- Run code the CPU on the target computer understands natively, rather than using an interpreter;
- Encapsulate such code into portable applications that do not depend on the host environment;
- Isolate such portable applications into sandboxes with well-defined, restricted capabilities, using publicly audited existing solutions.
Native Web belongs to the application layer according to the OSI model, on top of a reliable transport layer such as TCP.
Advantages over the World Wide Web
- A Native Web browser has a very small scope compared to a web browser, thus making multiple client implementations possible;
- Functionality is limited by the application itself, not the browser;
- No browser APIs required to access hardware resources;
- Source code can be always audited before execution. More on this later.
Disavantages over the World Wide Web
Possibly no protocol can ever be a perfect replacement for the modern web. The Native Web is no exception, and the following disavantages have to be considered:
- Limited portability: some platforms might not be able to provide the level of sandboxing required by the Native Web;
- Servers must provide portable applications for all platforms supported by the Native Web;
- Portable applications might include external libraries of varying size. Therefore, download sizes are expected much larger (at least tens of MiB) compared to the typical size of a website (tens or hundreds of KiB).
Allowed software licenses
In order to avoid unverified, and therefore potentially malicious, software from running in users’ computers, users must have the right to inspect the source code of the application before executing it. Therefore, the Native Web only allows software licensed by the AGPL license.
Native Web browser tasks
When connecting to a Native Web site, conceptually speaking, a Native Web browser:
- Connects to a Native Web server using the nweb:// URI scheme. For example:
nweb://xavi92.privatedns.org
- Establishes a TLS handshake with the server;
- Prompt the user about the right to download the source code before downloading the application;
- If requested by the user, retrieves the hash of the tarball containing the source code;
- If requested by the user, retrieves the tarball containing the source code and checks its hash. Caching is allowed if a file with the same hash already exists;
- Tells the server the target architecture, as described by
uname -moe.g.: x86_64 GNU/Linux; - Retrieves the hash of the portable application matching the target architecture described above;
- The portable application is retrieved from the server matching the target architecture above. Caching is allowed if a file with the same hash already exists;
- Runs the portable application in a sandbox.
Sandboxing requirements
In order to mitigate potential vulnerabilities, Native Web browsers:
- MUST NOT allow access to the host filesystem;
- MUST NOT allow access to any hardware peripherals, unless explicitly allowed by the user;
- MUST allocate a directory, only accessible by the sandboxed application, to store application data.
Portability
As stated above, since the Native Web executes natively compiled applications in a sandbox, some platforms might not be supported. So far, Linux is the only platform considered. Realistically, this document expects no mass adoption in a near future from non-tech-savvy users anyway. Should the Native Web become unexpectedly popular, this document assumes corporations will find a solution to its limitations (think of how Docker is actually implemented on non-Linux platforms).
Linux implementation
The following pieces of software are suggested: