Keep an app unblocked in the firewall?

GlassWire Help
21

Is this app still maintained? Should we be worried? Why isn’t this fixed? And it’s now 4 clicks to unblock?

Edit : Just to be clear, since this is obviously a very opinionated decision from you guys : I decide what my threat model is, not you. I should be able to decide that some binaries don’t need GW protection. Rogue known signed binaries is already game over. Not being able to join a Teams on time because of Glasswire is a much more common and important threat to me than supply chain attacks or my box being popped.

Let us whitelist executables, please.

1 Like
22

Hi everyone, checking in to make sure I understand the scope of this issue as I see it is long-standing. So if I understand correctly, when you upgrade an app that has a firewall rule already applied to it, GlassWire is detecting this as a new app in the firewall list and NOT applying the previous rules already set. Is this accurate?

Would a solution where we somehow detect that this is indeed still the same app, just a new version, and keep the same rules applied to it be the correct resolution? Or are there other scenarios where this wouldn’t work?

1 Like
23

This is a big problem.

I have learned that, when I try to use Microsoft Quick Assist and it doesn’t work, go to GlassWire and unblock “Microsoft Edge Webview2” (again and again and again - webview2 is updated so frequently)

Honestly - how do you expect your customers to understand that Webview2 is used by a lot of other applications and GlassWire is blocking it every time it gets updated and they have to manually go and unblock it?

1 Like
24

Correct. The issue happens because the the new version of the app has a slightly different path. Typically because the the version number is included within the folder name. It is particularly bad for things like EdgeWebView which is updated during boot, before GlassWire has started, and so the new version is silently blocked without notification. As EdgeWebView is used by other apps these then begin fail.

The solution has been discussed, and promised, for many years. All we need is a basic rule which uses wildcards and (for extra security) checks the digital signature of the executable.

So for the EdgeWebView example the executable path in the rule 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

Ideally, GlassWire would also check that the code cert of the new version matched that of the old.

1 Like