Problem
When monitoring a GW remote server it is too easy to select Block All for the GW remote server instead of the Local computer.
At present, I can turn on blocking for a GW remote server. The problem is that this action is not reversible from the monitoring computer because GW communication is now prevented. To resolve a mistake, I have to turn blocking off at the GW remote server. This becomes a bigger problem if physical access is difficult or prevented for that computer.
I can give you an example which is similar to problems I’ve seen in the past. A critical process is left running overnight on a computer in a locked room or secure area. A computer administrator who works at night is asked to monitor the process to check that it hasn’t crashed. That administrator decides to monitor that process using GlassWire because that is already setup. That night the administrator suspects a malware problem on his computer and selects Block All without realizing that the GlassWire view is for the remote computer. The block causes the critical process to fail because it needs continuous network access. The administrator can’t remove the block in a timely manner before the process fails. Nobody would have thought that GlassWire could stop the process completing.
Solutions
I’d suggest having a warning message before allowing Block All for any GW remote server, i.e. for any computer that is not Local.
Another option would be to allow Block All to be turned off remotely but I’m not sure that allowing any communication is worthwhile when users want to Block All.