Discussion in 'other firewalls' started by ultim, Oct 12, 2011.
Great. Awaiting for it.
Okay, finally, here’s the fruit of the past 3 weeks and some coding marathons: UWP support.
Let’s begin with the changelog for 2.99.14, and then I’ll add some additional notes:
- New: Support for UWP apps
- Fix tray notifications on Win10 sometimes not visible
- Make Services window remember size
The changelog seems short, but obviously the first point is quite complex. First of all, of course the user now has the possibility to select an app from a list of only UWP apps (from the Settings window). But things don’t stop here. In fact, UWP apps are now auto-detected whenever possible, for example when whitelisting by window, or from the Processes or Connections forms, and new exceptions will be created for the UWP app instead of the executable file if possible. Furthermore, on Windows 10 there is special support for detecting whether an UWP app has been tampered with or flagged as malware by a 3rd party antivirus, and TinyWall will accordingly give you the green/red/blue banners in the exception details dialog. Of course a UWP app will be properly shown as missing (if absent) in the Settings window too, just like other applications, even though they aren’t identified or detected by their files like traditional apps. In other words, I think support for UWP apps is quite extensive and should come natural to most users.
Window 8 is a PITA. Basically it supports UWP apps (though they were called differently in its time), but it seems you cannot access them from traditional desktop apps at all. As a result, I had to exclude Windows 8 from the UWP support, and TinyWall on Win8 will behave identical to as if run on Win7. Windows 8.1 is not a problem though, so there is UWP support starting with Win8.1.
There were some hurdles I needed to overcome. From a technical point of view, one was making sure that you can still run TinyWall on Win7 and .Net 3.5, which normally wouldn’t have been possible, as you cannot link to the necessary libraries on these platforms, not even if you don’t call them in code. I also had to make some conceptual changes to the UI. The previous UI was very file-centered, and basically assumed that every firewall exception pertains to a file, sometimes with an additional service name. The identity of UWP apps is independent from the location or naming of their files, and are identified by a special Windows SID (security identifier) which is hidden to normal users. Since I could not use files anymore to refer to apps for the user, I had to make some changes here and there in the UI. As a result, some translations will be missing the new strings, though I tried to fill them in where I could. The new fundaments in TinyWall 3 made adding such a new kind of rule much easier though than it would have been in TinyWall 2, the earlier long preparatory work has really payed off.
Before I finish up, it might be worth adressing at the end why UWP support is important at all, or why you’d want to have this feature. Well, here are the reasons why:
- Windows Store apps (which are also UWP apps) change their filesystem locations whenever they are updated. UWP support in TinyWall means they remain whitelisted even after they are updated, like traditional desktop apps.
- Windows Store apps are distributed as packages, and potentially contain multiple executable files. With UWP support in TinyWall, you are whitelisting a whole package as one, meaning the problem of traditional desktop apps where you do not know which and how many files you need to whitelist does not exist anymore.
- Windows Store apps sometimes have strange executable names that can seem unrelated to the application you are looking for. UWP support in TinyWall means TinyWall can show you a more user-friendly name of the app.
- Some Windows Store apps share the same executables, but run as different apps in different processses. UWP support in TinyWall means you can correctly whitelist them separately instead of all-or-nothing.
Wow, this was supposed to be a forum post, not a diary entry
Let's get v3.0 out as soon as possible, and for that I need feedback if everything's alright. Here’s the [download link], have fun, and let me know if you run into any problems. Thanks for the help everyone.
Hi Deathmaw! Latest beta should make things work smoothly with the PC Game Pass too, since everything is so Windows Store-y there. Please let me know how the latest 2.99.14 is working for you
(see my post above)
i haven't understood , for all the 64bit version w10/8/7 the new version is version3 ,isn't ?
but there is not a "paranoid" or "interactive" mode ?
for paranoid and interactive mode i mean a pop up everytime a program try to connect to internet (outgoing)
Thank you for the updated version.
I have been using V3 for a few weeks and it has been working well.
I have just upgraded the latest test version. Support for UWP apps appears to be working well. The "Show connections" dialog was very unresponsive at first but is is fine now.
If you could fix Windows Defender updating it would be brilliant.
I think you are in the wrong forums TinyWall has no paranoid mode, no interactive mode, and no popups, no matter which setting. I think you are using a different program.
EDIT: Forget what I said before the edit.
Do you mean the problem that Defender gets new directories with each minor version? If it does that despite not being a UWP app, there is no standard way to deal with it. In that case, all that can be done is to introduce special cases for Windows Defender alone, and handle it in code separately - I'm not saying it is out of question since Defender is quite a central component, but I'm definitely not fond of the idea.
But is that necessary at all? I mean, I get Defender updates over Windows Update, which works just fine. Why would you like to whitelist Defender too?
I believe Windows defender does much of its checking using on-line data so it needs an internet connection to work properly. It does instant look-ups. Windows defender updates to a new version in a different directory and then has no internet access. I check regularly for a new version in c:\programdata and change the firewall as soon as I notice a new one.
Currently I have:
I get this exception when I try to open Manage screen:
System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
at PKSoft.UwpPackage.NativeMethods.GetUwpPackageListing(Package& list, Int32& size)
at PKSoft.SettingsForm.SettingsForm_Load(Object sender, EventArgs e)
at System.Windows.Forms.Form.OnLoad(EventArgs e)
Operating system is Windows Server 2012. Pressing Continue will open the window.
I assume the same problem may occur also on Windows 7. I also tried to edit one rule that I have added and after I pressed the UWP list button, it crashed and the program closed.
No, it doesn't happen with Win7 / Win8 / Win8.1 / Win10. I tested those Windows versions personally. I didn't test any Windows Server versions though, and apparently the same UWP API that works on Win8.1 does not work on Server 2012. I'll check if I can find an alternate API for that case, otherwise I'll just blacklist Server 2012 and disable the UWP functions there. Thx for letting me know.
With both 2.99.13 and 2.99.14, I often lose some settings, and have to use auto-learn on apps that I already authorized, like Opera or Waterfox who lose randomly after a reboot Internet access.
Aside that, Kudos, I cannot imagine a better GUI.
Question, until these problems with the beta are solved, does the latest (2.1.13 I think) regular version supports W10?
It's a bit tiring to have to relearn constantly.
Reason found. I didn't see it because of low number of connections. Fixed in next build.
Hi, BobHD. 2.1.8 is not the latest, it is relatively old, and it has known problems with Win10 v1903 or later. Please download the latest version from the homepage (tinywall.pados.hu), which works with any version of Win10 (including v1903 and later).
That's strange. I haven't seen that happen and nobody else has reported a similar problem even though 2.99.13 has been in testing for many weeks, so for the moment I'm going to have to assume it is related to your PC/setup somehow. TinyWall basically only looses its firewall settings when the settings file gets corrupted or lost. Do you have crashes with your PC? Try running a filesystem scan for errors.
We might also find some pointers in the logs (look in C:\ProgramData\TinyWall if there are any), but in a case like this, I'm not being too hopeful about the usefulness of these logs. Do you notice any pattern about when the settings get lost? Is it only after reboots or does it happen without reboots too? Does it happen on every reboot?
Yes, just after posting, I verified and saw it's 2.1.13. I installed it (I remember having problems with my W10 tests on virtual machines), and so far so good... until now where the tray cannot communicate with the service.
I did not reboot after the downgrade, the setup did not ask for it. I'll do it now, it's probably needed.
I have a lot of apps installed, so many that it took me 2 weeks to re-install everything when migrating from W7 to a new PC with W10.
In particular, I use Window Blinds, and although it makes W10 look much better, it brings compatibility problems.
I don't see any log, maybe because I downgraded to 2.1.13.
I'll see if i have still problems after the reboot, and if I do, install the beta again and take notes about the patterns, I'm not sure for the moment. I don't have crashes. And the apps are blocked even though I can see then unblocked in the manage dialog, so the settings are not lost, they just don't work.
I swear, W10 is a nightmare.
I have still the communication error after the reboot, so I will upgrade again to the beta.
That too is abnormal. Your problems with both the stable and the beta releases might have the same root cause.
Just to make sure that folder permissions are alright, please 1) uninstall TinyWall, 2) delete the folder C:\ProgramData\TinyWall, 3) reinstall TinyWall.
I'm a bit tired of all the installs and reboots, so I propose to see if I still have problems before trying that.
I may have found out some of the reasons though:
I imported the saved settings of my 2.1.7 release I used in my previous 7 year old W7 system. I noticed a lot of rules concerning non-existent programs, and I deleted them.
In particular, I had maybe 10 Opera different locations, so my guess if that when it auto-updates, it programs an install in a different directory at the next reboot. That would explain while Opera is often blocked when I reboot. It would be nice to be able to setup wildcards in the rules, such as *\opera.exe.
Maybe having 30 to 40 invalid rules was the cause of the other problems?
Anyways, the config is clean now, I exported it, and will do what you ask next time I have a problem. If I don't, we could conclude that too many invalid rules are a problem.
I compared the permissions to other folders in C:\ProgramData, they are the same.
It seems to me TWv3 didn't forget your rule after all, but because Opera always got updated to a different location, it wasn't whitelisted anymore, so you though the firewall rule stopped working. This would be simple to check by verifying if another program (that didn't change location) is still working.
I'm quite sure that a large number of invalid rules isn't a problem. That you see them listed differently in the UI list is purely a GUI feature.
New version up with reported issues from the past 24 hours corrected.
- Fix GUI crash on Windows Server 2012 R2
- Fix performance regression in Connections window
- Add special rule for Windows Defender to keep it whitelisted after an update)
Download [fresh and hot].
I think the UWP APIs really might not be supported on WinServer 2012 R2. Installing a UWP app is possible but not easy without the Store, so instead of trying if I can actually run a UWP app there, I searched on the internet. Things point in the direction that it is not supported, though proofs are circumstantial at best. Add to this that I don't expect people to run Store apps on a server anyway, so I ended up disabling UWP support on WinServer 2012 R2. I *did* check Server 2016 too, and all the UWP stuff works nicely there in TinyWall.
The performance issue of the connections window was totally my fault, an oversight and a regression in the previous beta. Fixed now.
As for Windows Defender, I finally realized (duh!) that the "special exceptions" system in TinyWall is the perfect way to handle such things. It is technically perfectly suited for the task. In the end I didn't even have to write a single line of code for Defender, all was done as a simple addition to the XML database. It might take up to 30 minutes after a Defender update to get the new version automatically whitelisted though. I also decided not the add it as a "recommended" special exception that is default-on after installation, because Defender in its standard configuration can upload your files to submit samples, so I couldn't do it in good conscience. Which means you'll need to enable it manually in the settings. Of course after that there is no need to add a rule manually anymore.
Thank you very much. I have installed this and given it a very quick test but it appears great.
I think the upgrade lost some settings from the "general" page. I upgraded as my administrator user, not my normal user.
A slight anomaly, if you log in as a different user, any UWP apps the user does not have get the X deleted icon. I guess this is to be be expected.
That is expected. TinyWall has two settings files: the firewall settings are stored globally for the whole machine, while some GUI and controller settings are per-user. You won't see the normal user's settings when operating the GUI from the Admin account.
(Also, I once had a report that per-user settings might not be preserved over an upgrade a few weeks ago, which I still haven't verified, and I also don't think I will before the final release. They are only GUI customization, not firewall settings.)
Nice catch. I might not be able to change how that works due to permissions, but I'll take a look at it tomorrow.
The version 2.99.15 seems working well on my W10.
So what I understand is that we are now able to block the UWP apps, by default. And then whitelist just what is needed, the same way as normal apps? That is wonderful if so. I don't use those apps.
Yes, though the part about being "able to block the UWP apps, by default" has been always so, even before the UWP support. What has changed now is that UWP apps have become much more easier to whitelist and manage.