You just proved my point…
You gave 3 (three) examples of apps that change location when a NEW version gets installed. They don’t change location out of their own volition… they only change path when the old version is uninstalled and a new one is installed. A file or app that changes path on its own has a very particular name: virus (or the new term: malware).
This means that at one time, the “yourphone.exe” was installed at one particular path (call it a folder, etc, you get the idea). Then, Windows (oh Windows) issued a new version of that same app. Therefore, Windows “UNINSTALLED” the original app (it was therefore remove from that installed folder, path). Then Windows (Windows “Update”, by the way) installed the new version of the app into a new folder (a new path).
Why can’t Glasswire simply “round up” all apps that no longer exist in the hard drive at the “logged path” and group them into a category for quick clean up/removal from the firewall list/log? This has nothing to do with leakage at all, or any other issues… it’s a simple cleanup of firewall list/history of apps that are not found at the logged path… it’s a matter of a simple FIREWALL LOG/RULES CLEANUP… so what if the user has to interact with the firewall to assign a new rule? That’s precisely the purpose of the firewall.
Now, I see your point… about not wanting to keep telling GlassWire that the new app (which has a new path, thanks to the new versions that was installed by Windows Update) was in fact either denied/allowed before and that Glasswire should remember the rule and apply it to this “new” app (regardless of the new path/folder location). BUT that is not what I am talking about, AND is not good for a TRUE firewall to think that way for obvious hacking reasons.
Just to be super clear here, at the moment, GlassWire only allows/denies network access based on the app path (the rules/log attest to this - you showed a picture that states this). GlassWire is not automatically granting access because of the app name… it does not disregards the app location/path. Everytime that there is a new “yourphone” version, GlassWire keeps asking me if I want to allow/deny access (because it has detected a new path, therefore, it needs a new rule - this is how firewalls must work)… so… you make no sense.
Furthermore, hackers masquerade their files with similar and well known file names so that “stupid” firewalls can let them through… this is one of the first tricks they ever devised. Therefore, IT IS NOT to the advantage of any firewall to “remember” a rule by an app’s name in order to grant or deny connection and disregard the path. If it is not in the logged path, then it should require user input for the new rule (it could be a virus pretending to be a legit app). This is firewall common sense 101.
Some of the firewall software that always failed independent test reviews failed because they also had an option to remember the name of the file requesting access and ignored the logged path… they were instead looking for the app name (the .exe, .com, .dll etc) regardless of where it was found. Users saw this as a more convenient option (less user interaction with the firewall) and selected that option for the firewall to filter traffic. That was the downfall of the firewall companies, and users kept getting hacked.
Can you name one genuine firewall company which makes their software firewall to allow/deny an app network access just based on the app’s name regardless of where the path is? Even the firewalls that comes with some antivirus don’t behave that way, and they are not firewall experts. Even Windows does not do that. When a new version of yourphone.exe is installed, window updates also makes the path changes into it’s built-in firewall, that’s why those using only the Windows firewall will never see a message about that.
Well… thank you for corroborating/proving all my points.