The filters must sit in the data stream between the network access library and the presentation layer of the browser to be able to transform it.

In netlib, there's a concept called "stream converters" implemeted, which is responsible for charset conversion, mime-type conversion etc.

The first aim is to specialize converters to filters to follow the specifications of the user.

The list of activated filters and these specifications are generated by the filters part of the preferences dialog box of Mozilla, where the user can choose from the installed filters.

Until this point, all code must fully comply with the Mozilla-project, because the most parts are even inherited from Mozilla-classes.

The second aim is to get away from this to make programming of filters much easier and, above all, browser-indepented. The hope is, that the interface(s) are standardized by w3.org and so make its way into MSIE and other competitors, too.

Those standard-interfaces can be supplied by the Mozilla-compilant filters. Mozilla-compilant filters get just interfaces to other filters. This way, more than one interface is accessible. But this technique should be completely transparent to the user. Mozilla-filters should know, which filters belonging to them are installed on the system and report them to Mozilla, so that the user can choose directly the independent filters (not the interfaces and then the filters). If the user clicks on the "Setup..."-Button after selecting an already activated filter, a setup-window of the independent filter should show up.

The kind of interface between the browser-indepented, third-party filter and the mozilla-filter, the installation procedure and the setup dialog are completely free. The only main restriction is that the mozilla-filter knows the installed filters, which belong to it, to make it possible for the filters-preferences dialog box to provide an up-to-date list of available filters.