With setting “ask to connect” in the firewall, is it possible to keep an app unblocked after its updated?
Google drive keeps getting blocked, and have to remember to unblock it to keep files synced.
I don’t use Google Drive, but have noticed that some installers trigger the “ask” prompt every time they update. In my case, every time a new version of Dropbox is pushed, I get prompted again, even though I have allowed the previous one.
I assume maybe that it’s a new version number or something that triggers this? Not certain…
1 Like
What zzz00m is saying and also every time there is an update of any app you will be prompted. I don’t think there is any way to avoid it. I use click to block myself. Just easier for me. 
1 Like
ok, maybe start to use click to block then. Keep forgetting to check gw when something is not synced
1 Like
I have found that it is sometimes necessary to use “click to block” to get some installers past a “no network available” error.
So if you are careful about what you have installed and run a “clean” computer, there is little likelihood of anything malicious suddenly attempting an outbound network connection. And anything making a new network connection will be logged regardless.
1 Like
Hi, this problem has not been fixed since 2 years ?
It’s quite annoying to repeat the same action many times, and then having a blocked app list polluted by many occurrences of the same app (but different versions).
There should be an option to block/allow an app with some specific conditions, for example :
- Block/allow an app (same filename AND same signature) until… [specific date] or [specific amount of time]
- Ask again if a previously allowed app get significant changes (example : some virus detections by VirusTotal)
- Block/allow all apps from a specific editor (same signature)
1 Like
A fix for this has been promised repeatedly for a long time. Six years ago there was talk of a certificate (code signing) rule, but it never materialised.
Better management of duplicate firewall entries has also been promised. The fact that they build up is bad enough, but then deleting them is also a painful process. This is meant to be an enterprise security product.
It would also be great to have an option to allow an app only for a period of time (after witch Glasswire will ask again). It would prevent all those installation .exe file to pollute the list (they are only used once).
Still fighting this poor implementation on a weekly basis. I have found that once you reach a large number of these duplicate entries, GlassWire seems to stop prompting to Allow/Block the app. So the app is just silently blocked. Microsoft Edge WebView is practically a core part of the O/S now for all users. Why is this not fixed yet?
The latest release of GlassWire now has an easy way to delete the build up of redundant firewall entries, which is great. However, the longstanding issue of apps which update to a different path remains. A fix for this was promised 8 years ago!
But it gets worse. Some apps with their own auto update mechanism don’t seem to trigger the Ask To Connect prompt and remain blocked by default. Opera is one of these, but MS Team is another more problematic one. After an update Teams will fail to sign in. There is no prompt and no entry for a new version being detected in the Log tab.
It is necessary to go to the Protect tab and allow both Microsoft Teams and Microsoft Edge WebView2 to restore operation. Both of these apps install their updates to a new folder which GlassWire cannot cope with; e.g.
c:\program files\windowsapps\msteams_24295.612.3262.1872_x64__8wekyb3d8bbwe\ms-teams.exe
c:\program files (x86)\microsoft\edgewebview\application\131.0.2903.86\msedgewebview2.exe
1 Like
Here is WebView, a core Windows component being blocked following a version update. No Ask To Conect prompt appeared and the new version has not been detected or listed in the Log.
The user must work out that the reason certain apps have stopped working is because this core component, which was previously allowed, is now being silently blocked.
Hi @ittroll
The WebView was blocked because updated and installed to a new location, so it’s considered as a “new” application.
Ask To Connect mode blocks all new apps by default.
The ask to connect popup was missing because GW UI was not running at the moment, when WebView initiated it’s first network activity.
Thanks for the reply @Andrea_GlassWire
I understand why it is happening, but why isn’t there a solution after all these years? This component will be present on most Windows computers and so GlassWire should be able to operate with better intelligence in this standard configuration.
8 years ago there was talk of a certificate checks and/or wildcard patterns which would seem to be the obvious solution for frequently updated apps.
It is also slightly alarming that the new version is not logged, presumably because the GlassWire UI is not running. So does this mean potentially malicious changes can go undetected if they happen early enough in the boot sequence?
Today it was Teams’ turn.
No prompt and nothing in the log. So I guess we can’t rely on GlassWire’s security checks to reliably detect system file changes.
Disappointing that there was no attempt to address this in the latest version. For some reason, tweaks to the UI have a higher priority than the core operation of the security features.
@Huda_GlassWire Please can you check if this longstanding issue is being worked on. The problem is with apps and Windows components which install updates to a new folder name and so require re-approval, or simply fail to trigger a prompt and so are silently blocked. This has been a known issue for years and previous reps have claimed it was being worked on. Suggested solutions include rules which incorporate publisher certificates and/or wildcards paths. Here are a couple more old threads on the issue:
Microsoft Edge WebView2 is a prime example of the long standing problem, this Windows component is used by many other applications. Following an update it installs into a new folder and GlassWire silently blocks it. Now other unrelated apps will suddenly stop working and the user has to divine why.
All we need is a basic rule which uses wildcards and (for extra security) checks the digital signature.
So the executable path is:
C:\Program Files (x86)\Microsoft\EdgeWebView\Application\*\msedgewebview2.exe
Instead of:
C:\Program Files (x86)\Microsoft\EdgeWebView\Application\139.0.3405.125\msedgewebview2.exe
What I don’t like about “Click to block” is that, if you run something that is malicious, it can do bad things before you have a chance to stop it. I run GlassWire to improve my security. By running it in “Click to allow” mode with the VirusTotal option, my security is greatly enhanced.
3 Likes
Agreed. Ask To Connect is the more secure stance. GlassWire just needs more intelligent rules to handle updates with path changes.
I don’t know why the GlassWire devs haven’t fixed this by now. This is just dumb.
1 Like
Why the hell is this not fixed yet
1 Like
It’s crazy that there’s still no fix for this. I have to review the Active Apps list multiple times every day to unblock updates of various standard and well-known apps, including built-in Windows components. There needs to be some sort of auto-allow rule for these updates. It doesn’t even need to be perfect or match every possible scenario - just something to handle the majority of cases.
1 Like