Hello, would it be possible to add broader blocking options for files and folders that are created only temporarily? For example, items in the Temporary folder tend to disappear and reappear. When I block them in the firewall, they show up again and have to be blocked repeatedly. It would be very useful to allow blocking by path—such as an entire folder, a subfolder, or by name as a custom rule.
Thank you very much.
There is longstanding feature request for the capability to create path (wildcard), publisher (certificate), and destination (IP) based firewall rules. It keeps being promised…
In the meantime, for your scenario, you might be better to flip into Click-to-Allow mode rather than Click-to-Block. That way these temp locations would be blocked by default.
Hello,
I could be wrong but being GlassWire a enhanced GUI for Windows Firewall, I think it can’t do things that Windows Firewall can’t do. When you create a new rule in Windows Firewall you can only, eventually, allow or block a specific IP address or a list of IP addresses, not domains though. You can’t use wildcards patterns, neither allow or block specific publishers (i.e. digitally signed executables).
I’m only aware of one 3rd party firewall that supports wildcards patterns in applications’ paths, moreover it is freeware.
From Windows Firewall article about rules Windows Firewall Rules | Microsoft Learn
True. But GlassWire keeps it’s own database of apps and access rules. So when it detects an app it can use it’s own logic to determine if it should be allowed or blocked and then make an appropriate rule in Windows Firewall.
Thank you, I didn’t know that. In this case I wonder why the features that you listed hasn’t been implemented yet as they would be very useful and maybe they could entice me in future to subscribe to GlassWire Premium, perhaps with the addition of the feature to Allow / Block domains per-app/executable.
Moreover you also listed “destination (IP) based firewall rules” in missing GlassWire features but Windows Firewall already supports allow / block specific remote IP address/es so it’s even wierd that GlassWire doesn’t support it. From what I can understand GlassWire, currently, is a Allow / Block app without the ability to customize its rules.
It is a feature set that has been requested before and throughout the time I have been a user (7+ years).
I can’t answer why it hasn’t been done, other than guess the developers have different priorities. I can appreciate that it could be tricky to make a user friendly interface for these advanced rules. Perhaps they don’t want to scare off more casual users? But then as you said, it could be a feature that is restricted to the top edition.
I think this could be the main reason, keep GlassWire easy to use. On the other hand this approach can discourage potential users that want to customize the firewall rules to have a greater control over them, rather than just having a simple Allow / Block behavior.
Indeed I just discovered a free software which acts as a GUI / front-end for Windows Firewall and it supports wildcards, even if Windows Firewall doesn’t support them. I didn’t think it was possible.
Moreover it can automatically allow applications signed with a trusted digital certificate. You can also manage your own list of trusted publishers to automatically allow any software they create.
So, also considering what you wrote above, I guess that GlassWire too should be able to support wildcards patterns, same for allowing digitally signed executables related to trusted publishers.
Great to hear that the theory is proved. Now we just need GlassWire to get on with doing the same!
Judging by the lack of feedback from the developers it seems that they are not interested in implementing any of the feature mentioned in this thread. I prefer a more flexible firewall that allows to customize its rules so, personally, I don’t see the point to pay a recurring subscription for a firewall that only offers Allowing / Blocking a app.
I’ll stick to the Windows Firewall GUI and the 3rd party firewall I’m currently using as they offer some rules’ customization, especially the 3rd party firewall. They don’t have all the other features included in GlassWire Premium and described here GlassWire Pricing but for me the most important thing is the firewall. Moreover they are both free of charge and 64-bit.
Thanks for the discussion here, and sorry for the silence on our end. It definitely wasn’t disinterest.
Here’s where we’re heading. Rather than building full path or wildcard rules, we’re exploring whether we can solve the temp-folder problem by allowing blocking at the package level. That way blocking once would actually stick, instead of you having to chase the same thing as it keeps reappearing.
It won’t cover every case raised in this thread, but it should fix the main issue. It does require some real rework under the hood, which is the honest reason it hasn’t shipped yet. It’s on our roadmap for this year, and we’ll come back here with a concrete update as soon as we have one.
I’m intrigued how packages will be identified without using paths. These temp setup files tend to use randomised filenames and have variable checksums. Just using the application name would be very dangerous. I don’t see a solution other than “fingerprinting” using multiple identifiers which would include publisher certificate and wildcard rules.
