As a data protection project, we always stick to these three principles when developing our technologies and running our services:
- Data minimization: we only process and store the data that we really need to process the respective transaction.
- Privacy by Design: Data processing always follows the “Privacy by Design” principle, whereby we always ensure a high level of data protection as early as the development of a function.
- Privacy by Default: All configurable functions are preset to generate, store or transmit as little data as possible.
Data processing when using the eBlocker
A basic design principle of the eBlocker that no usage data is recorded during the operation of the eBlocker. In particular, no usage data will be sent to us (eBlocker Open Source) or any third party beyond the unavoidable data that is generated during normal internet communication. Even for the unavoidable data, eBlocker provides the user with options, if necessary, to control the extent, recipient or time of transmission. The development of the eBlocker was guided by the following principles:
- Prevent data storage on the device.
- Any eBlocker specific services of the device work autonomously without additional cloud servers. I.e. neither directly nor indirectly there is a data outflow from the device to us (eBlocker Open Source) or other third parties.
- For unavoidable internet connection data (DNS queries, routing), eBlocker offers additional options to the user to be able to control which servers get this data.
The following sections explain some important aspects more in detail.
eBlocker filters always work autonomously
The pattern recognition and filtering functions of eBlocker work completely autonomously and do not use any cloud services. This includes tracker and ad blocking filters, malware filters and parental control filters. Therefore, no information about the accessed websites is sent to us (eBlocker Open Source) or any third party.
The eBlocker does not store any traffic data
The eBlocker also does not store any connectivity data on the device itself. There are the following exceptions:
- The device’s own DNS server has – like every corresponding server – a cache (intermediate storage) to optimize the response times, in which the last queried domains are stored. The retention time corresponds to the TTL time of the DNS responses, typically a few minutes. There is no interface to specifically read this cache. The DNS cache can be cleared manually at any time via the administration interface. The user can disable the eBlocker DNS server at any time.
- To optimize the filter functions, filter results for called domains can be stored locally in eBlocker. This data is stored encrypted by eBlocker. There is no interface to read them out specifically.
- To analyze and fix SSL connection problems, the user can activate the recording of SSL connection problems. Here, the recording can be activated individually for each device in the home network. In case of an SSL connection problem, the affected device, the time as well as the addressed domain is saved and displayed by eBlocker in the administration interface. These recordings can be deleted manually at any time and will be deleted automatically after seven days.
- A similar function allows the recording of all SSL connection data of a device for a maximum of 15 minutes, also to analyze and fix SSL connection problems. This recording function terminates itself after 15 minutes at the latest and only ever records the SSL connection data of a single device in the home network.
Distribution of DNS queries
Among the unavoidable connection data that is generated when establishing internet connections are the DNS queries for resolving internet domains. Here the eBlocker offers the user the possibility to specify several external DNS servers and to select them accordingly, so that the queries are distributed evenly to all DNS servers, in order that none of these servers can create a complete profile of the queries. The user is free to choose the DNS servers, the number is not limited. Additionally, DNS queries can optionally be sent over the Tor network (even if the rest of the traffic is not routed over Tor at all).
Routing data obfuscation
To prevent the user’s internet provider from getting detailed traffic data about the routing of internet requests, the eBlocker offers the user the possibility to route all internet communication of single devices or the whole home network via Tor or an OpenVPN capable VPN provider in an encrypted way. We (the eBlocker Open Source Project) are not involved in the communication at any time. The user has the free choice of any VPN provider. When routing via Tor, the countries of the exit nodes can be freely defined by the user.
Analysis of SSL traffic
At its core, eBlocker works with a technology that analyzes data packets for patterns of data collector services. This pattern analysis can only be done if the data traffic is decrypted in the eBlocker. If the user also wants the eBlocker protection for SSL connections (via https), the SSL function needs to be activated explicitly on the eBlocker. With activation, a unique root CA certificate is generated for each eBlocker in the respective eBlocker. To decrypt encrypted connections, the eBlocker then forms the end of the end-to-end encryption of an SSL connection. It takes over the validation of the website certificate and the revocation lists instead of the browser. To re-encrypt the connection to the end device of the user, the eBlocker Root-CA certificate needs to be added to the browser or the operating system of the end device once. The eBlocker then uses its Root-CA certificate to sign the website certificate to ensure the encryption to the end device. The Root-CA certificate has a validity period of three years by default. The user can generate a new Root-CA certificate at any time, for which the validity period (12/24/36 months) can be determined freely.
Data storage during activation of eBlocker
The email address provided during activation will only be used to notify the user in case of a very serious eBlocker security vulnerability. In particular, the email address provided during activation will not be shared with third parties and will not be used for other purposes such as sending advertisements.
Data storage during update
In order to act autonomously (see above), the eBlocker must be regularly supplied with updated patterns, filter lists and further data. For this purpose the eBlocker has a function for automatic or manual update. The user can decide if the eBlocker automatically checks for updates once a day at freely selectable times by polling an eBlocker cloud server or if he wants to do this manually.
To receive updates, the eBlocker must have a valid license and a linked X.509 certificate with associated private key. This certificate is uniquely assigned to the activated eBlocker, but does not contain any user data itself. Especially neither the e-mail address, nor an IP or MAC address of the user.
During the check for update, only this certificate is transmitted to validate the update authorization. The update server stores a reference to this certificate and the associated activated license, as well as the time of the request.
These update requests are the only data that are centrally collected and stored by us during the operation of an eBlocker.
The IP address used during the update request is written into the log files of the server for technical reasons. However, it is not analyzed systematically and especially not stored in a database or otherwise linked to the above mentioned update data or other data of the user.
eBlocker Diagnostic Report
To support the analysis of technical problems, we may ask the user to create an eBlocker diagnostic report and send it via email. It is explicitly not recommended to share diagnostic reports in the community forum.
This diagnostic report contains a specially created diagnostic file with information about the user’s local network: number and type of network devices, their local IP address and MAC address, the user’s external IP address and further data about the current configuration of the eBlocker. Furthermore, the diagnostic report contains some more log files that can give information about the usage of the eBlocker.
All files are simple text files that are packed into a compressed tar archive. The user can view these files at any time before sending them.
Source code inspection by everyone
The whole eBlocker source code is available as open source under the EUPL license (GPL compatible). Thus, everyone interested can take a look at the quality of the programming code and convince himself that the utmost care was taken during the development and that the implementation of data protection described here was done accordingly.