The Small Web Browser, an inclusive proposal

Background

Almost a year ago, I had some ideas floating around about an alternative to the world wide web, where native executables were downloaded from servers, rather than a mix of HTML, CSS and JS. However, such alternative did not put any care to one of the (IMHO) most serious concerns with the current world wide web: user privacy.

Gemini, on the other hand, preferred to design everything from scratch, effectively excluding web content from Gemini, and vice versa. This was in fact one of the main concerns behind this well-known article.

This had me thinking for a few weeks. While I do think HTTP/1.1 is good enough for most tasks, so that a completely new-from-scratch application layer such as Gemini might feel redundant, there are several aspects from HTTP that I do not particularly like:

• Cookies
• User agent
• Referer
• Etag
• Cross-origin requests

There are other aspects from the modern web that I strongly dislike, too:

• Search engines
• JavaScript
• Unencrypted connections

Of course, it is not that websites are forced to use any of the points above. However, any user would have a hard time filtering websites out following this criteria. Even if browser extensions could be used, these are not standardised and thus might lead to widely different results.

Then, I felt somehow inspired by the Small Tech Foundation, and their intention to provide a truly decentralised web. Unfortunately, even if the Small Web, as defined by the foundation themselves, were successful, it would still be cumbersome for users to figure out which sites do comply with their requirements - more so, considering they mostly define ethical requirements, not technological ones.

Proposal

Therefore, in an attempt to make an inclusive solution (rather than exclusive, as Marius thought of Gemini), I suggest a new browser, namely the Small Web Browser, with the following design requirements:

• Support a small subset of HTTP/1.1, supporting GET/POST, while effectively removing support for most HTTP headers.
• Support a subset of HTML5, so that embedded images, audio and video are possible.
• Support modern CSS, possibly leaving deprecated or complex features out.
• Support NO JavaScript at all, as JavaScript is one of the main sources of complexity behind a modern web browser, and is typically abused for user fingerprinting.
• Mandate the use of TLS-encrypted connections.
• Allow integration with SOCKS5 proxies e.g.: Tor.
• Provide passwordless authentication via client certificates, and always ask for user authorization beforehand.

And, as key features over existing web browsers:

• Provide a local index of sites complying with the requirements above, so that sites can be found without the use of an external search engine.
  • On the modern web, search engines are considered the gate-keeper between users and results, and often abuse their position for corporate interests.
• Such index can be updated from third-parties, similarly to package managers like APT.
• Custom providers can be easily added by users, so the network remains decentralised.

Advantages

The Small Web Browser is inclusive, because:

• Sites accessible from it can still be accessed from traditional web browsers. * It provides guarantees on a subset of features from the modern web that do not harm users.
• Users do no longer have to worry on inspecting which websites can be trusted, as such guarantees would be provided by the browser.
• It allows reusing existing tools, both web browsers and servers.
• Because of the smaller set of features, it also leads to simpler code, allowing more implementations to flourish over time.

Design goals

• Simplicity: by stripping off a large amount of non-essential features, implementing “Small Web” browsers becomes straightforward, allowing multiple implementations to flourish and co-exist.
  • This is not the case for modern web browsers, where only a handful of implementations (namely, Gecko, WebKit and Blink) are able to catch up with all required features, at a huge cost.
• Stability: as opposed to the modern web, “Small Web” browsers do not have an ever-increasing scope, but instead focus on a reduced and stable set of features by design. Implementations are then ensured to be compatible between them.
• Security: because of the limited scope, implementors can focus on making their browsers more robust and, therefore, more secure.
• Forward compatibility: since “Small Web” browsers implement a subset of standard HTTP/HTML/CSS features, websites accessible from “Small Web” browsers are also accessible from modern web browsers without modifications.

Next steps

Because of modern browsers being feature-compatible with a Small Web browser, it should be possible to reuse a more feature-limited yet simpler web browser, in order to create a modified fork that provides a reference implementation for a Small Web browser.

The following points must be considered before taking on the implementation:

• Which features from HTTP/1.1, HTML5 and CSS should be included.
• How the local index is retrieved from third parties.
• How offline searches can be integrated into the browser.

Candidate web browsers

• litehtml (preferred)
  • HTML5/CSS library.
  • Browsers must then implement a bunch of functions, mainly related to rendering.
  • A PoC web browser is also provided.
  • Does not render some websites (such as this) correctly.
    • Some quick experimentation showed @media CSS rules are not being applied, but should not be too hard to fix.
• Dillo
  • SSL (!) support still experimental.
• netsurf
  • Portable software written in ANSI C.
  • Only HTML 4.01 and CSS 2.1 supported officialy.
    • However, the Hubbub sub-project implements HTML5 parsing.
• KHtml
  • Can be easily embedded into Qt applications.
  • However, according to Wikipedia, KHtml will be discontinued from KDE Frameworks 6.