Latest update: 2022-02-05
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!
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:
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 two major implementations are catching up with current standards:
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*?
The Native Web aims to achieve the same level of convenience the World Wide Web currently offers, with the following substantial differences:
Native Web belongs to the application layer according to the OSI model, on top of a reliable transport layer such as TCP.
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:
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 AGPLv3 license or later:
When connecting to a Native Web site, conceptually speaking, a Native Web browser:
nweb://xavi92.privatedns.org
In order to mitigate potential vulnerabilities, Native Web browsers:
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).
The following pieces of software are suggested:
Article created on February 4th 2022.
Last updated on February 5th 2022.