💾 Archived View for xavi.privatedns.org › small-web-browser.gmi captured on 2024-08-25 at 00:05:31. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

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:

2022-02-04 Native Web: an alternative to the World Wide Web (draft, updated 2022-02-05)

However, such alternative did not put any care to one of the (IMHO) most worrying issues with the current world wide web, which is 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:

"Gemini is solutionism at its worst", an article by Marius.

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 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 its intention to provide a truly decentralised web:

"What is the Small Web?", an article by Aral Balkan

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, should be created, with the following 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.

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, such as Dillo, to create a modified fork that provides a reference implementation for a Small Web browser.

Dillo, a 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.

Would you like to share your thoughts? Contact me!

Back to main page

Article created on December 27th 2022.