Guys, can your apps connect to the net if you just select whitelisting? I think Detect option should be improved cause it finds only few out of many existing apps on my PC.
Switching the language does not work here (hit apply after changing). Or do I need to shut it down and start the application?
Whoawhoawhoaa... who ruined my surprise? As you can see I relased TinyWall recently, and by the time I got here to write about it, you've already discovered it Well done my young padawans. I've come (even if I'm not the first) to bring you TinyWall 2.1! In the end this release did turn out rather big, so big that I seriously though about naming it version 3.0. This release brings new features, a load of fixes, as well as security and usability enhancements. For all those people who just want to go ahead and install it without further ado, you know the drill: visit tinywall.pados.hu and get it from there. All links already point to the new version, but just to be safe, I'm not enabling the auto-update for old clients for a short time yet. This gives me a chance to fix any potential last-minute bugs you might find before the whole world updates to it. If you want to keep your current configuration, be sure to export your current settings first (Tray->Manage->Maintenance->Export), which you will be able to import again after the upgrade. Otherwise you will need to reconfigure TinyWall after installing the new version. Now kids, I'm gonna split you up into two groups. Most of you can stop here, and those who don't mind reading my multi-page techie ramblings, read on. This version, even if somewhat smaller than the transition from v1 to v2, is definitely on a similar scale, and the only reason TinyWall has not been rebranded to v3 now is because many of the changes are not so much visible to the user. You can see what I mean if you compare the length and complexity of the full changelog and the user-friendly changelog. But to get a feeling for the amount of changes that went into this release, my version control system tells me that 5185 lines of pure source code have been touched in commits. By "pure source code" I mean that this is not even counting databases, localizations, binary files and changes to whitespace. So much for the "small maintenance release" that I was planning... Anyway, even after all the feature additions and lots of new localizations, the installer's size has only increased by 96kBytes. This is thanks to some of my explicit efforts to keep the size low. Not that it would matter if TinyWall was a couple of megs larger, but this is kind of fun, and the application is called TinyWall... it has to live up for its name, doesn't it? Ok, so you have a full changelog >>here<<, but I'm gonna top that with some additional information below. Windows 8 support and Multiple controller instances It would be hard to pick just one change that I would coin as The Most Prominent, but support for Windows 8 is certainly on the list. TinyWall 2.0 was already working on Microsoft's newest OS as earlier reports have confirmed, yet I could still find some non-obvious but all the more important places that needed adjustment. Some changes for this were simpler, (like adjustments to how the installer creates shortcuts), while others were... For one, the communication between the client and service had to be redesigned to properly account for Win8's connected standby mode. This non-trivial change lead me to go some more steps further which ultimately resulted in multiple enhancements, like the ability to launch multiple controllers. Earlier, only one TinyWall Controller could be active at any time, so if multiple users logged in in parallel, only the first one was able to control TinyWall. This limitation is now obsolete and the new TinyWall correctly supports multiple user sessions – not only on Windows 8. You should also see the 'Operation failed' message much less often, if at all. I also slightly altered the operation of "Whitelist by window" (Ctrl+Shift+W) to make better sense in a Metro environment. The whole point of Metro apps is that most of the time only a single application is visible on the screen. So what's the point of having to pick windows by mouse? Obviously, the changes for this only mostly affect Metro apps. Wait, did I just say "mostly"? Ask Microsoft why the desktop-style Windows Explorer presents itself as a Metro app... The list of changes for Win8 does not end here though. The Metro UI was still causing me a headache. The problem was that TinyWall uses bubble notifications in general to communicate with the user about important security events, to confirm user actions, and to feel 'alive'. This important behavioral aspect got completely ruined by Metro. Arrrgh! The basic solution here would be to use the new Win8 Toast Notifications. However, this soon lead to more problems, like having to drop support for the .Net Framework that natively ships with Windows 7, or the fact Win7 does not have toast notifications at all. In the end though, I've come up with my own solution to keep the best of all worlds. What this means is that in the end TinyWall's requirements did not change a bit, not even the least, yet it is still able to use Win8-style toast notifications when you are in a Metro app. CODE NINJAAA ! So, might TinyWall be the first and as of yet only free firewall controller with basic graphical Win8-Metro support? I'm not sure, you tell me. On a separate note, I could also mention that the new TinyWall passes Microsoft's automated "Windows App Certification Kit for Windows 8" tests. Not that it matters a lot though. Security enhancements As of now TinyWall performs full certificate validation of binaries that you whitelist. This does not only allow TinyWall to avoid falsely recognizing an executable as "known", but TinyWall is now also able to (and it will upon whitelisting) warn you if it finds an executable that has been tampered with. I immediately made use of this new feature inside TinyWall too to increase communication security between the controller and service. Obviously, TinyWall's service must run with full admin privileges, so making sure that only the legit Controller can control it is important for security. Earlier this was solved by letting the service and controller do basic passphrase authentication to each other. While this was certainly enough to stop casual attackers, with some reverse engineering it was still possible for a stranger to pose as the controller. In this new version, this is much harder now as circumventing the new protection is only possible by changing/infecting TinyWall's binary (which would also break cryptographic validations). Last but not least, I noticed that I forgot to cryptographically timestamp my binaries in earlier versions. This is important because un-stamped binaries are reported as having an invalid certificate after it expires, even if the binary has been signed within the validity period. This is not a problem anymore for the new TinyWall. Removal of network zones For the first time in TinyWall's history, a major feature has been removed. Earlier TinyWalls automatically detected the active network type assigned by Windows, and switched rule sets accordingly. This was supposed to be both a security and comfort feature, but it really backfired. Almost nobody used it knowingly, but a lot of people experienced losing their configuration because of it – at least that is what they have thought. People didn't really lose their config in reality, what happened is that they roamed to a different network, installed some software or connected to a VPN, which made Windows switch the network type, which made TinyWall load the rule set for that zone, which... at the first time was empty. In any case, even though the feature worked as expected AFAIK, it caused more pain than it was of use. So I removed it for now. Usability enhancements There's a lot to list here. A lot of you asked for the ability to disable the global shortcut keys, so it has been implemented. Also popular was the request to timestamp the list items in the Connections window, and coupled with the (also new) ability to sort by any list column, you can now order your block entries by the time of their occurrence. In the Manage window, application exceptions can be removed in batch. Some visual glitches have also been corrected, for example you will not receive a partially constructed (and unusable) Manage window while it is still loading. Also, upon Controller startup an ugly empty form will no longer flash, and thanks to windows forms not loading at all until the user requests it, application startup is also faster. The traffic speed meter reports accurate values now, and there is a large number of new translations: Dutch, German, Hungarian, Spanish and Russian. Oh, and the Potuguese translation actually works in this version. Bug fixes Many bugs have been fixed. One that most of you will have seen is that you were unable to whitelist privileged apps by window, even though an earlier changelog (2.0.0) states that you should be able to. This now really works, and therefore you should need to use the 'Elevate' feature much less often. Also of interest is a mistery-crash in the service. It was especially bad because the service crashed when applying certain saved firewall rules, so restarting the service did not help, it only got it into a restart loop . Even though I received multiple reports about it, I could not reproduce it for a long time, and even worse I could not think of any reason how it was even possible for the service to receive invalid rules. Then one day (actually, recently) it also happened to me during debugging, which allowed me to finally analyze and circumvent it. Hehe, note I said 'circumvent', because it was actually an accumulation of two idiotic (and afaik undocumented) Windows API behaviors, so not really my fault in the first place. Last but not least, there are also a couple of fixes that will allow you whitelist more things that you were previously unable to (e.g. official MySql service anyone?). And multiple crash fixes, both in controller and service. In the end, following my personal tradition, I am proud to release yet another TinyWall without any known bugs. Which of course does not mean that it is free of bugs, but hey, if you find any, you'll report them, right? I hope you all like the changes and will find TinyWall 2.1 a solid version. If not, just tell me and I'll be here to fix things up
Sure, if you've whitelisted the correct executable. Check in the Connections window, make sure to open it before opening the app. It was never the intention to find all apps on the PC. If TinyWall whitelisted every executable it found, it would also often whitelist malware. Besides, if you want to whitelist everything, why use a firewall in the first place? Anyway, being able to correctly recognize more apps and to maintain the database up-to-date is gonna be the objective of a lot of my thoughts now, and will hopefully see a solution realized in development.
I got a error trying to install the new version. I did Uninstall version 2.0 first and reboot the computer. Here is the error I got: "Error writing to file, TinyWall.XmlSerializers.dll Any idea? Thanks
Hmmm.. frankly, no. First time I see that. Try running >this<, wait for it until it tells you that the uninstall has finished (might take a while), then after a reboot, try the setup of 2.1 again. This utility was made for TinyWall v1 because it had known uninstallation problems, and honestly, it was never ever needed since v2 was released. Or did you maybe had v1 running?
By the way, for all the others trying out 2.1, you can of course, but there is no need to uninstall 2.0 before that. Just run the new installer and everything will be updated in place. Should be a clean upgrade path, except for having to export your settings if you want to keep them.
Try to install over the top of v2.01 and I got the same error. Reinstalling v2.01 with no problem. No error, this is strange...
Hello ultim. Nice to see you back with some new work. Yes you are the first. But this means that from now on if you want to use TinyWall you will have to install NET Framework 4.5. Is that correct ? I have another question. As a user, when you will take advantage of the toast notifications, because like it is now, TinyWall is a tray application. When toast notifications do appear ? Do they do something if the user clicks on them ? Windows Firewall rules are applied per path basis. From what I read about this new feature, you probably read the hash of the file and store it for the whitelisted applications and if a malware tries for example to delete firefox.exe and place itself in the same path and name itself as firefox.exe, you will alert the user because the files don't match. Is this correct ? If a malware already gained administrative privileges and can replace files in Program Files folder, then it can simply try to stop Windows Firewall service, or it can inject itself into a running process. This is how malware usually work. In this scenario, your file will still have the same hash, but it will be controlled by the malware. Does this feature work in this real world scenario ?
I would like to try this new version but, I get the same error "Error writing to file, TinyWall.XmlSerializers.dll. I tried this: First time I see that. Try running >this<, wait for it until it tells you that the uninstall has finished (might take a while), then after a reboot, try the setup of 2.1 again. This utility was made for TinyWall v1 because it had known uninstallation problems, and honestly, it was never ever needed since v2 was released. Or did you maybe had v1 running? DID NOT WORK!
Seven64, I was talking about v2.0.1, the new version is 2.1.0, a little confusing I admit. Anyway I gave up for the time being.
I'm having the same problem, freshly installed Windows 7 x86. TinyWall.XmlSerializers.dll Only Firefox and Bitdefender Free installed....Nothing else has been installed or uninstalled.
Oh, OK thought I was the only one having problems getting this new version installed. I tried with a snapshot with newly installed Windows 7 x64, same problem. Thanks, Antarctica.
No problem. I hope ultim will find a solution to this problem because I really like this application.
Feature Request: Have Tinywall (optionally) to automatically update itself (not just notify but update) when an update is detected. Probably check for update when computer starts up or once a day. Another is to regularly update the MVP hosts file or maybe pull it directly from the website so that even if you are busy, the hosts file will still be updated. EDIT: Maybe you could also change the hosts file to hpHosts (Possibly the optimized one, yes I am bringing this up again, ) since it is regularly updated, unlike MVP hosts.
Thanks guys for reporting the installation problem. 2.1.2 is out to fix this issue. The problem was a wrong tool directory path in my project file. That path got accidentially overwritten when I upgraded my development environment. Please download 2.1.2 from http://tinywall.pados.hu/download.php and installation will be a breeze now.
Thanks ultim for the quick fix, I really appreciate. Like you said, installation was a breeze this time.
Not correct. Vista and Win7 users do not have to install .Net 4.5 to use TinyWall. As I said earlier, the system requirements did not change. Of course toast messages need .Net 4.5, but toast messages are only available on Windows 8 which comes preinstalled with .Net 4.5, so this is completely transparent to the user. TinyWall will use tray notifications if you are on the classic desktop, and will use toast notifications if you are in a Metro app. Most times you will see a toast from TinyWall when further user input is needed in a dialog for whitelisting, so clicking on it will bring the classic desktop to foreground. No, the certificate check is only done once during whitelisting, as I've written earlier. TinyWall still does not continously monitor files for change. This has been on my experimental try-out/idea list since long, but I've always had higher priority stuff to implement. You misunderstand the purpose of this feature. The problem is that during normal PC usage, a lot of executables will try to connect to the internet that do not have a descriptive name. firefox.exe does, but svchost.exe, waahost.exe and gameoverlayui.exe do not. So if the user doesn't know which software the exe belongs to (or is simply a non-techical user), how can he decide if it should be safe to whitelist it? Checking for certificates helps to identify safe software for the user, and checking for its validity helps to filter out self-signed and fake certificates. Earlier versions of TinyWall used certificates to identify legitim software, but the certificate itself could still have been forged. This new version of TinyWall closes that security hole, because it will only accept valid certificates from now on. So to summarize, this feature is really usefull, but it addresses a different problem than what you have thought about. I would also say that your claim "This is how malware usually work" (infecting other processes) is not exactly so. While certainly a lot do that, also a lot (maybe just as much) will simply try to install an executable and will run in its own process. Some use a file name of other known software to try to pose as them. TinyWall's mentioned abilities are used to identify both authentic executables and impostors: as an example, a malware might be called firefox.exe, and it might even have Firefox's certificate (a forged one with the same public key), but TinyWall will still be able to detect the impostor thanks to its new features. In this case, this latest version of TinyWall will not simply tell you that the executable is unknown, it will warn you that it is most probably not Firefox that you were expecting. Of course, even if the original application or executable is safe, the process could still have been infected. However, even if a malware has successfully infected the files of an otherwise good application, it doesn't matter as long the application is not whitelisted in the firewall. This is why I find TinyWall very good here, because its no-popup approach will prevent the user from whitelisting all applications that want to connect. The point of TinyWall is that the user will only whitelist programs that he really needs to go on the internet, thereby reducing the risk of letting infected applications through. Another case is when the user has already whitelisted an infected application, for example because he actively wants to use it (but doesn't know it is infected). This is why firewalls should restrict internet access even for trusted applications, so that an infected process won't be able to communicate with everything on the network. TinyWall does a pretty good job here too, with its multiple internet blocklists, or its ability to cage processes to the local network.
