Windows 10 Blocking Ineffective, Tedious

GlassWire Elite 2.1.167 - Windows 10 Pro 1909

Well, I finally decided to retire my eight year old i7-3770K/Z77 Win7 Home desktop with an i9-9900K/Z390 Win10 Pro.

I found GlassWire eminently practical in managing applications’ access to the internet for programs where I deemed calling home was unnecessary and blocking outbounds for a slew of Microsoft services. The Ask To Connect feature was gold.

But now I’m recalling what I ran into with Win10 waaaay back when as a Windows Insider I was running pre and post releases. And I think I posted up something about it here.

For example, I opened Windows Camera after I installed my WebCam and the first thing that happened was two outbounds, one HTTP.
c:\program files\windowsapps\microsoft.windowscamera_2018.826.78.0_x64__8wekyb3d8bbwe\windowscamera.exe
I blocked it.

A couple of weeks later and here we go:
c:\program files\windowsapps\microsoft.windowscamera_2019.926.20.0_x64__8wekyb3d8bbwe\windowscamera.exe

Same program, new path. Note - the second event occurred even though I had since changed all Camera security settings to off and with the USB WebCam unplugged. There is no better reason for a program like windowscamera.exe to be blocked always by a one-time setting without further user intervention. That way I can use my WebCam locally,as I did in Win7.

Ditto for programs that just go ahead an connect out in the background.

Like Microsoft Outlook Communications:
c:\program files\windowsapps\microsoft.windowscommunicationsapps_16005.11029.20108.0_x64__8wekyb3d8bbwe\hxtsr.exe
Blocked.
c:\program files\windowsapps\microsoft.windowscommunicationsapps_16005.12430.20136.0_x64__8wekyb3d8bbwe\hxtsr.exe
Blocked.
c:\program files\windowsapps\microsoft.windowscommunicationsapps_16005.12430.20280.0_x64__8wekyb3d8bbwe\hxtsr.exe
Blocked. Well, until the next time.

So for all intents and purposes, GlassWire’s blocking is largely ineffective.

Which brings me to an annoyance I’ve always wondered about: Why is it when Deny is selected on First Network Access, there is no entry in Alerts?? The process of an un-Deny or further research requires strict attention to the ONE alert (as in, write it down) and then find the program in Firewall.

As well, unless one has “that don’t look right” expertise, just whacking Deny might break something Win10 is trying to do.

In Win7, after the initial Allow, blocking a program or service, at worst, evoked an in-app “can’t connect” OK or an Information entry in Event Viewer. Since there’s a First Network Activity in Alerts, it is easy to find and block it needed. An updated program or service evoked only an Application Info Changed; firewall state untouched.

But now in Win10, I’ll need to find out exactly how to disable Microsoft Outlook Communications (hxtsr.exe) and then hope there are no ramifications. And do that for a boatload of Windows programs/services that in just over two weeks have two to four paths. winstore.app.exe is relentless.

I understand GW is undergoing a complete rebuild, soon to be released.

I’m hoping it will be able to enable blocks based on process and not path. (Just like Malwarebytes Anti-Eploit; it doesn’t care where Libre Office, for example, is installed or is portable, when opened, Libre Office is announced as protected.)

In other words, GlassWire needs to catch up.

And record Deny in Alerts.

If not, I’ll have to find something else for an application firewall and keep GW for its superb monitoring.

Thank you. Looking forward to the rebuild…

Thanks for your detailed feedback. Our team will review it.

What about blocking by certificate, do you think that would help? For example allow all apps signed by Microsoft, but block unsigned apps, or apps by X company.

I understand how you’d like alerts/logs for blocking behavior. That’s a great idea.

The update has a rewritten backend but no new functionality. The backend improvements will allow us to move faster in adding new features/settings in the future.