pylorak
Tinywall blocks service despite being whitelisted
Despite being whitelisted
I did autolearn and it worked. I noticed there's 2 entries now in settings.
I deleted both entries, and unblocked, it appears to add it as a service by default
I have to Select a Process, select EABackgroundService and add it as an Executable instead.
The same thing occurs with the Xbox gamingservices.exe I have to add it as an executable and not service.
its not an issue or bug. this is how it works. i'm a very old user of TinyWall. you have to whitelist list that .exe normally, not as service. VOILA.
its not an issue or bug. this is how it works
Sounds like a Logic or Association Handling bug to me. If it's going to automatically set the type it shouldn't require manual intervention.
Sounds like a Logic or Association Handling bug to me. If it's going to automatically set the type it shouldn't require manual intervention.
You are not completely wrong and I understand how this might look buggy for a user. But please be aware that sometimes multiple processes share a single executable and they could be executing as different services. Or one process is a service and the other isn't. This is not just theoretical, there are known apps that do this. So if TinyWall chooses to unblock the executable instead of a service when it thinks the process might actually be running as a service, it could result in unblocking apps and processes that the user didn't intend to whitelist. Basically, TinyWall has two options. Either err on the side of easier usability, or err on the side of better safety/privacy. Which path would you take? Currently it does the latter.
When users right-click to select the Unblock option in the Show connections window, the appropriate connection type (i.e. Executable or Service) should be automatically pre-selected, which is not the case (at least for this specific EABackgroundService file). And this is why it took me two minutes to understand why it was still blocked, even if already in the whitelist.
Even when trying to unblock the Executable, TinyWall was pre-selecting the Service option.
This improvement would reduce user confusion.
please be aware that sometimes multiple processes share a single executable and they could be executing as different services. Or one process is a service and the other isn't. This is not just theoretical, there are known apps that do this. So if TinyWall chooses to unblock the executable instead of a service when it thinks the process might actually be running as a service, it could result in unblocking apps and processes that the user didn't intend to whitelist. Basically, TinyWall has two options. Either err on the side of easier usability, or err on the side of better safety/privacy. Which path would you take? Currently it does the latter.
Always better safety. Sacrifice useability rather than compromise security.
I'm saying I can find it in services.msc, tinywall detects at a service, tinywall does not unblock it as a service. Why? In my view unblocking a service is broken?? or is it a service running as a process? :) If this is indeed intended, maybe a FAQ?
GamingServices is weirder being both active and blocked