Thanks all for your great feedback and questions! Please ping me if I missed to cover a technical question below that you wanted an answer to.
The update check happens once an hour OR when you get online.
With the fix mentioned below, we fixed an issue with the Portmaster not correctly detecting connectivity. It may have detected connectivity too early in the past, meaning it would attempt to update when there is not connection yet. So, this _might_ work a lot better now.
Yes, as @CyberDevil assumed the blocking triggers a loop. I also went over this with Daniel and referenced these two code parts triggering this.
[1],
[2]
We use one.one.one.one -> 1.1.1.1 as a check if DNS resolved correctly during connectivity testing. What we like about using one.one.one.one is that (1) it is not suspicious - we don't like to broadcast to the network that the Portmaster is running on a device - and (2) the returned IP address will (very likely) never change.
We did not think about other systems blocking that domain though, which caused the Portmaster to retry it.
This problem reached us in a fortunate time window and we have already implemented and released a fix for that: If resolving one.one.one.one is not successful, we now use dns-check.safing.io as a fallback, which makes it obvious the Portmaster is at work, but we need a guarantee on the returned IP address for the check to reliably work.
Does this blocking somehow affect the work of the Portmaster?
No, there was no impact, just that the Portmaster would think it is only "semi online". But, as laid out above, this should now be resolved anyway.
Remember when I wrote about zombie processes in the Linux system monitor? Apparently, they were related to the enabled blocking option in the Next DNS. As soon as I turned off this option, the zombie processes no longer appear in the system monitor.
Interesting. From what I saw when I looked into this, this should not be related.
The program icon from the system tray began to disappear from time to time. After reboot, it reappears, but after 2-3 system boots, it may disappear again.
Until now we've only had problems with the Tray Notifier appearing multiple times. We use a PID-lock for the notifier - what could have happened is that the notifier failed to clean up after itself (hard shutdown?) and then PID of the old PID-lock of the notifier was taken by another process, letting the notifier think that there is already an active instance running.
I hope that in the future the program will show the amount of incoming / outgoing traffic for each program and the speed of the Internet connection.
We definitely want to do this, but this isn't easy to do while keeping things fast as they are. On Linux, we'd have to find a whole new way to interact with the network stack, on Windows we'd need to add support for counting data in the kernel extension. So, it'll come, but it'll take some time.
And if I understood correctly, at the moment Portmaster does not protect (and does not even notify the user) ports from being scanned by special programs (for example, Nmap)?
What do you mean exactly by "protect"? We cannot stop packets from arriving at your device.
Currently, the Portmaster drops incoming packets it does not allow, meaning that a scan will be not be able to see open ports that are not allow to accept connections by the Portmaster. In my opinion, that ticks the "protect" box.
In addition, we have a portscan detection system in progress (no ETA! [Estimated Time of Arrival]), which will outright block all communication with an IP that is scanning your device, even when scanning allowed ports. This will also have notifications.