Skip to main content

 

Fefe fasst die aktuellen Ereignisse bei Mozilla zusammen:

https://blog.fefe.de/?ts=a1cd1f2c

Auf kurz oder lang wird Firefox wohl wie die SPD Geschichte sein. Damit bleibt Chromium (Chrome) als Schwergewicht und FDP unter den Webbrowsern (nur im Hinblick auf die Ideologie) übrig, zusammen mit einigen Abkömmlingen wie Microsoft Edge und Apple Safari. Wer denkt da noch an die Interessen der Nutzer, für die Privatshäre und der Schutz vor Werbung wichtig ist?

Jetzt erscheint es umso wichtiger, die Forks von Firefox und Chromium (z.B. Palemoon, Iridium Browser) zu stärken oder an anderen freien Browsern zu entwickeln, damit auch in Zukunft mindestens ein Browser da draußen ist, der aus freier Software besteht und das Augenmerk auf (technikaffine) Nutzer und deren Anforderungen legt statt Profitinteressen und den Anforderungen der Werbewirtschaft Vorrang einzuräumen.

# # # # # # # #

Lotte Mondblum reshared this.

 
Meinste nicht, dass Mozilla nur durch ein Tal der Tränen gehen muss, bis die aufwachen? Fefe schreibt ja auch, dass es erst wehtun muss.
 
Das Tal ist anscheinend noch nicht tief genug, denn einen Richtungswechsel kann ich bei Mozilla nicht feststellen. Die Kündingungen, die jetzt in manchen Abteilungen durchgeführt wurden, deuten eher auf ein „weiter so“ bei Mozilla hin, was im Endeffekt zu noch weniger Nutzern und im Endeffekt zum Ende von Firefox führen wird. Firefox war mal gut, aber fing dann an, Chromium/Chrome hinterherzulaufen. Anscheinend ruht man sich bei Mozilla darauf aus, dass Firefox nicht so schlecht wie Chrome im Hinblick auf die Privatsphäre ist.

Ich benutze Firefox auch nur noch deswegen, weil er in der Paketverwaltung standardmäßig dabei ist, alle Webseiten damit gehen und es genügend Erweiterungen gegen Werbung und anderen Mist gibt. Sollte sich der Zustand von Firefox verschlechtern (mehr Telemetrie, mehr fest eingebaute Dienste wie z.B. Pocket, weniger Schutz vor Werbung), werde ich wohl auf einen anderen Browser wie z.B. Konqueror wechseln.

 

The wiki for MoeNavigatorEngine now contains documentation on how to contribute to the project. It also gives you a basic explaination of how the network stack works and how parsers work in MoeNavigatorEngine so that you don't have to look into the code anymore to figure that out:

https://codeberg.org/moenavigator/moenavigatorengine/wiki/index

If you have cloned the source code repository, you can download the whole content of the wiki by invoking "git pull" followed by "git submodule init" and "git submodule update". The wiki content is in the "doc" folder.


More documentation on the different parts of MoeNavigatorEngine will follow. Any specific component you are curious about?


# # # # # #

 

MoeNavigator update: The engine got a new network stack


In short: The network stack in MoeNavigatorEngine has been cleaned up and has become more flexible. The tools for the engine have been updated, MoeNavigator got a bit of maintenance.


The refactorisation of the network stack in MoeNavigatorEngine (MNE) has progressed far enough so that the new code has been merged back into the master branch.

The new stack relies on a network handler that interfaces with the network functionality of the operating system and request objects that pass themselves to the network handler when the request starts. The difference to the old stack is that there is no network protocol handler anymore that passes data. Instead, the network handler sends data to the request object's buffer which is then passed to the "other side" of the web browser engine that processes the data in one of its parsers. To avoid polling, mutexes are used as semaphores which get locked when data have been read and unlocked when data is available. The new network stack should also be able to handle asynchronous requests, but that isn't implemented yet.

The protocol support is the same as with the old network stack: HTTP only. But in the new stack, the Request class provides an abstraction layer where protocols are just specialisations of the base Request class. Adding support for other protocols (like gopher) should have become easier with the new network stack.

The HTTP support has improved in the new stack since the header fields are not limited to a certain set of fields. All header fields are treated equal in request and response headers as long as they are valid. The HTTPRequest class doesn't care what's inside the fields, its only repsonsability is to put together the request header, parse the response header and read the response data. I have verified that reading big binary files works using the mneget tool (from the moenavigatorengine-tools repository). To send data via HTTP POST or PUT, the HTTPRequest class needs some more code to send big chunks of request data.

To add TLS support, a layer between the network handler and the request is necessary. How it shall be named is not yet decided, but it will probably implement the NetworkHandler interface so that all methods for unencrypted network access can be available for encrypted network access as well. This would enable support for HTTPS and could add TLS support for all other protocols the engine supports so that theoretically there could be something like "gophers" (gopher secure), once gopher is implemented.

Besides the work on the engine, I updated the tools for it and got mneget, a wget-like program, into a working state. MoeNavigator itself got a little bit of maintenance and an updated about dialog. With the big progress in MoeNavigatorEngine this week, the days of WebKit as default engine in MoeNavigator are numbered.


About

MoeNavigator is a web browser written from scratch in C++. It uses its own engine called MoeNavigatorEngine (MNE). There is also a collection of tools for the engine. The source code is licensed under the terms of the GNU General Public License v3. The repositories are on @Codeberg.org:

- https://codeberg.org/moenavigator/moenavigator
- https://codeberg.org/moenavigator/moenavigatorengine
- https://codeberg.org/moenavigator/moenavigatorengine-tools


# # # # # # # #

 

Which application layer protocols besides HTTP(S) would you like to see in a web browser?


Since the refactorisation of the network stack of MoeNavigaterEngine is coming to an end, it is more easy now to add other protocols. The question is: Which protocols besides HTTP(S) can be useful in a web browser? Which would you suggest?


# # # # #

 

MoeNavigator progress


After months, I have continued to work on the refactorisation of the network stack of MoeNavigatorEngine, the web browser engine of MoeNavigator.

In the new network stack, the Request class (and especially the derived HTTPRequest class) get a central role in handling request and response data. They interact directly with the network handler on the one side and the engine core on the other side. The architecture should be able to allow synchronous and asynchronous network requests in the future. At the moment, the code to read data from an URL in MoeNavigatorEngine reads response data in chunks using a synchronous approach.

During implementation of the new network stack, I thought about including libcurl, but it couldn't be integrated into the new network architecture, since it doesn't allow separating transfer protocols like HTTP from the underlying network functionality. For a web browser engine, I think it is necessary to have the full control over each bit of HTTP data that is sent or received. So the network stack of MoeNavigatorEngine continues to use POSIX sockets directly without a library in between and protocols are implemented in classes derived from the Request class.

There are still some tasks to be done before the network refactorisation is finished. The progress can be seen here: https://codeberg.org/moenavigator/moenavigatorengine/issues/9

The "network-refactorisation1" branch in the git repository contains the current state of the refactorised network code. It is still unstable, method signatures and interface definitions may still change.


Info
MoeNavigatorEngine is my attempt to write a web browser engine.

Project page at codeberg: https://codeberg.org/moenavigator/moenavigatorengine

# # # # #
 
Thinking about the new network architecture, it seems that middleware modules between a request and the network handler can easily be added, especially if the middleware implements the NetworkHandler interface. Support for TLS could be added by telling Request objects to interact with a TLS-NetworkHandler which in turn interacts with the "real" network handler. Of course, malicious plugins could hook themselves between the TLS-NetworkHandler and the Request object and read all data, but then again, you should know what you are doing when installing plugins.
 
Built-In TOR support would be possible by adding a middleware module between the TLS middleware and the "real" network handler.