Update December 20, 2023: We have released eBlockerOS 3 with IPv6 support today. The following article is therefore no longer up to date.
For the next big development stage of eBlockerOS we have analyzed and prioritized the wishes of our community and summarized all in a roadmap.
Roadmap for eBlockerOS 3
Originally we had planned to accelerate the development of eBlockerOS 3 with freelance developers that we pay for their full-time implementation services. We wanted to raise the funding for this via a new crowdfunding campaign. Unfortunately, however, there will be no crowdfunding campaign in the short term, so feature development is likely to be slower with the commitment of volunteer supporters alone. More on this below in the “Subject to change” section.
Advanced Ad-Blocker & Cookie-Banner Blocker
Today, eBlocker blocks all requests to data-collectors. Thereby, most advertising banners and other elements of third party providers are also blocked, so that websites are almost free of advertising. However, it may happen that adverts are delivered by the visited website itself – i.e. not by a third party such as Google or other Ad Servers.
The same applies to so-called Consent or Cookie Banners, which today also disappear almost completely, if the Cookie Banner Filter in eBlocker is enabled. However, banners which are directly integrated into the website cannot be blocked technically.
To ensure that both advertising and cookie banners disappear completely, they can be suppressed in the browser by so-called “element hiding” – even if they were loaded directly from the visited website. The elements are not displayed then, although they got loaded. For eBlockerOS 3 we plan to implement exactly this element hiding and thus provide an even more undisturbed surfing experience.
Update: The feature has already been implemented in a first version in eBlockerOS 2.8 – including the highly requested YouTube ad-blocker.
Obstruct fingerprinting, further improve anonymity
Today, the eBlocker can already cloak the end device and simulate another device to the visited website by so-called “cloaking”. Technically, the user agent is replaced in the http request. This replacement is static today, i.e. the user agent is fixed for the selected device type, even if it is updated quarterly by us. For example, a device cloaked as a Linux computer appears to be the very same device for all eBlocker users who have chosen a cloak as a Linux computer.
This type of cloaking can be further improved by not using a static, fixed user agent, but a user agent that differs and varies from request to request. This makes it even more difficult to recognize and fingerprint the user when device cloaking is enabled.
Intelligent handling of new network devices
eBlocker today offers extensive protection settings for devices already known in the network. However, for example the parental controls or other filters could be “accidentally” bypassed if friends of a child connect their own devices to the network. These devices would not be filtered per se in case the eBlocker was not configured optimally. Parents might not even recognize these new devices later, when they have been removed from the network already.
To prevent this, an intelligent, automated handling of new devices is planned. With this feature, the eBlocker administrator will be informed automatically if a new device is connected and it is possible to set filter defaults for new devices. For instance, it can be prevented that a new device can connect to the internet at all or it can be enforced that always certain parental control, malware or other filters are applied. It also makes it easier for the administrator to keep track of which devices have been newly connected to the network and thus also detect “unwanted intruders” in the network.
Improved Domain Name Service for DNS firewall
Today’s DNS firewall is already very flexible and masters the standard DNS protocol for resolving domain names to IP addresses. In addition, a “round-robin” distribution of DNS queries via different DNS providers as well as a routing of DNS queries via the Tor network is easily possible.
In addition to these features, eBlockerOS 3 will also implement new DNS protocols that are currently gradually establishing their position in the market:
- DoH (DNS over HTTPS), which encrypts DNS requests using the HTTPS standard.
- DNSSEC (Domain Name System Security Extensions), which can be used to prevent DNS response forgery.
Both protocols have very similar benefits in the end and during detailed planning we will decide which of the protocols we prioritize to implement.
Advanced Personal Device Firewall
With eBlockerOS 2.7 a first version of the Personal Device Firewall will be released, which allows to individually detect and block the domains contacted by the particular device.
After this first version, we are already planning some improvements for eBlockerOS 3, such as a visualization of the requested domains over time, a geographical analysis of the requested domains as well as extended blocking options like blocking of certain countries. Furthermore, a more detailed illustration is planned, which eBlocker filter rules have blocked certain URLs and domains, so that especially “power users” get more transparency and flexibility.
Update: We have fully implemented this feature in eBlockerOS 2.7 already.
IPv6 support
The current Internet standard is based on the IPv4 protocol, which is also implemented in eBlocker today. The next generation of the Internet protocol IPv6 slowly reaches private home networks. Even if IPv6 has only disadvantages for privacy protection and rather should not be activated, the new protocol can not be deactivated at some home network devices or only with some technical efforts.
Therefore we plan to implement IPv6 support for eBlocker to offer users who cannot deactivate IPv6 the same comprehensive protection as with IPv4.
Update: Please check out the current progress of the IPv6 implementation here.
“Subject to change”
The roadmap outlined above is a summary which we have set in the team. At the end of the day, the concrete implementation is done by developers who implement the features either on a volunteer or fee basis. The volunteer developers decide themselves if and which items they want to develop and at what speed. We can only achieve a precise prioritization and time estimation of development efforts with freelancers, we are paying for their services. So the exact time when a feature will be released also depends on whether we can find additional feature sponsors like the German DEVK insurances. Of course, this also means that there can always be changes and new ideas that a developer implements or a sponsor wishes for.
Developers, sponsors and supporters wanted
Are you a developer, do you know potential feature sponsors or supporters, or can you otherwise contribute to faster feature development?
Then we are looking forward to hearing from you: partner@eBlocker.org
