If this gets implemented, I hope the (optionally) part is included. I personally detest silent updaters, forced upgrades, and forced update checking.
Okay, I think TinyWall looks okay now, with two rapid fixes to the major 2.1.0 release. Consequently, I have enabled the auto-update functionality of old clients. Pre-2.1 users should be getting "update available" notifications soon, and they will be updated to 2.1.2. Also, here are some replies I missed (sorry): Hosts and database updates are already completely automatic in the background. The only kind of update that requires user interaction is a program update. For now, this is likely to stay non-automatic. TinyWall already tries to update the hosts file regularly and automatically in the background. The only reason you have perceived it differently is because I haven't released updates for the hosts file for a long time, 'coz I was lazy busy. Currently it is up-to-date however, and I will do my best to keep it so until I implement a mechanism that doesn't require actions from me. I promise the situation will be better now than it was over the past year. I know hpHosts but its size worries me. It is much larger than the MVPS hosts, and even though I didn't have performance problems when I used hpHosts, other people already get slowdowns when they install the smaller MVPS hosts file. And of course I want to avoid people blaming TinyWall for the slowdown. MVPS is still a very good quality and highly respected hosts file on the internet. If you think you need the extra protection that hpHost provides, TinyWall's hosts file management can be disabled so that you can install your own hosts file. Hmmm... you're right, whitelisting from the Connections window behaves a bit differently than whitelisting otherwise. I mean you should be able to click on the bubble notification to edit the newly added exception (for example to define a lifetime), but you can't. Looks like you've found my first "TO DO"-item for 2.1.3
Updating from v2.1.1 to v2.1.2 shows this window and the setup ended without updating the installation. Going to do a clean install now.
BUG REPORT: I can't seem to add programs in a bulk manner. (Try adding 5+ programs at once then click apply. An error will appear in the TinyWall tray.
Problem Hi, Shows 2.1.2 update, but came up with a "Change Repair or Remove" screen, can't change it, don't want to remove it, so I tried to repair it. It wiped out all my 'Connections' Had to re-set them.....
Hmm... even though I explicitly tested upgrade installation from 2.0.1 to 2.1.0 and everything worked fine. And now after I read about these issues, I also tested upgrading from 2.1.1 to 2.1.2, and still no problems. So either there is an upgrade problem between other two specific versions (like 2.0.1 to 2.1.2, but I see no reason why this would be problematic when my other tests worked fine), or this issue only affects some systems. I am disabling the built-in auto-update to 2.1.2 until I investigate the issue. Either way, the problem, if any, is only with the installer and not with TinyWall itself, so you should still upgrade to 2.1 using the download from the homepage. The installer issues only mean that you might need to uninstall the old version first before installing the new one. And when given the option, don't hit "Repair". This is expected upon upgrade to 2.1. Due to changes in the code, an upgrade to 2.1 will reset your settings, by design.
Thanks for the reply. I went to the 'Home Page' and did the 2.1.2 download, but comes back now saying, "..windows installer package error" , won't download I'll try to start over and uninstall it and re-install from the "Home Page".
@ultim: I just wanted to say thanks for the recent updates. As a small token of my appreciation, I've sent a donation your way. Your little firewall controller is perfect!
Is there any chance you will add a mode for users that want to be prompted when applications request internet access instead of silently blocking everything that does not already have a packet filter rule? Also, many techs like myself like the ability to tweak Firewall settings. The more control, and support for tweaking the firewall the better. This could be added as a separate mode that is not enabled by default.
Very hard to say just yet. Recently I've been thinking a lot about what TinyWall's future should be. There's a clash of multiple fronts here, like NewFeatures vs. Time vs. PopularRequests vs. PersonalInterest vs. OriginalIdea, and obviously, finding the optimal trade-off that all of us will be pleased with is challenging, to say the least. You can already edit most details of any firewall exception that TinyWall creates, remote an local IPs being probably the only notable property that you can't. For already added exception, you can edit them in the Manage dialog, but for newly added exceptions, there are even easier way: - Enable "Prompt for exception details", and you'll be given the option to fine-tune every new exception in the future, - or click on the bubble notification that tells you the app blabla.exe has been whitelisted, and you'll be given the same chance. Or did you want to tweak other options?
Ok, there is nothing wrong with the installer, or with TinyWall, or with the upgrade. The automatic update didn't work, because the update server was handing out an old version for automatic download than what it should have. All I needed to do was to upload the most recent TinyWall to the update directory on my server, something which I apparently forgot earlier xD. Also, this only affected automatic updates, if you've downloaded the installer from my homepage using the download link, you've already got the correct release. So you don't need to do anything, and no issues here. So the only thing to be aware of, is that you'll need to re-add your exceptions after upgrading to 2.1 the first time, or you can export and import the settings (updating inbetween). This however, is not a bug, but by design, and it was anounced earlier on this forum that this is probably going to be this way. Changing the settings code was necessary to efficiently support many of the new features in 2.1. This also means, don't wait for a future 2.1.x release that will not make your settings reset, because there is certainly not going to be any. On a different matter, TinyWall 2.1.2 is out now since a few days, and still nobody reported a bug. Not here on Wilders, not on other forums, not in my mails, not anywhere... C'mon people, you can do better than this. Start hunting! EDIT: Correction, kupo says he can't add new exceptions in a bulk manner. I can't reproduce it though, seems to work just fine for me. Anybody else with similar experiences?
Regarding the fine-tuning of firewall rules: It is feasible by using the WFAS MMC snap-in in safe mode. Also, while in safe mode, one can customize the predefined "Recommended" and "Optional" rules ("Special Exceptions" tab) by editing the .xml file located at "ProgramData". Personally, i removed all the "Optional" rules and inserted predefined rules for my main internet-facing applications, when i had TW v. 2.0 installed (haven't installed the new version yet). Whitelisting them is as easy as checking them (=> copying the .xml file and checking the appropriate rules can make the installation and initial configuration of TW an ultra-fast process for a relative/friend). @ultim: 1. Is it possible to extend the 2 minutes time-window of displayed blocked applications? Even better, do you consider adding a separate logging -not just displaying, i mean- function of blocked connections, if you decide to preserve the "silent" character of TW (the wise thing to do, IMHO)? 2. How TW handles the WSH rules? 3. Thank you for your work/time/intention.
upgraded my installation several days ago some notification about some icon at the end no issues otherwise, everything is fine and dandy
Running good, only complaint is HOST file is outdated (Updated: May-21-2013). New one is Updated July-08-2013.
That xml file is what I usually refer to as "TinyWall's profile database". Nice, CGuard, for being creative, but please guys, don't edit that xml file yourselves. First and most importantly, your changes won't stick. That's because every time TinyWall looks for an update, it will download the server's xml file if it is in any way different than the installed one (hashes are used to determine if they are different). This happens even if there are no updates otherwise. So you either disable update checks, or your changes will be overwritten upon the next check. And guess what, I strongly recommend you not to disable update checks. Second, unconcentrated or inexperienced users can easily violate the xml schema, which will lead to TinyWall not being able to load that file. While it will not blow your PC to smithereens, it will leave TinyWall in a less-than-usable state, because many built-in rules are stored there that are required for your PC's normal operation. Last but not least, it is a very round-about way to set up a pre-configured firewall to your friends, and certainly not the easiest. You could just simply use the import/export feature for this, which will work equally well (just make sure all programs are installed to the same paths on both PCs, for example to their default paths). Exporting then importing is a supported method to reach the same goal, and will even work across versions. As for the contents of the ProgramData folder, I cannot guarantee that their format will stay the same. Also, having to boot to safe mode to edit this file is not very practical. That xml file is simply not meant to be edited by users. If you want a program to be included there, drop me a mail and there is a very big chance that you will see it in the next version of the database, which is not tied to program updates, so can happen a lot faster. The basic answer is, that the current behavior is due to a technical limitation in Windows, that you can only get information about blocked packets and connections by letting them to be logged by Windows first. Events in Windows' event log are written to the HDD. So if you have even just a moderate amount of blocked processes, continuos connection monitoring will prevent your HDDs from spinning down (or it will make them spin up often), will consume a lot of power on laptops, and will shorten the lifetime of SSD drives. To the best of my knowledge, other firewall controllers are also affected by the same issue, even if they think it is not worth telling you. For the reasons above, I decided it is generally the best to not continously log blocked connections in TinyWall. Specifically, TW will only monitor blocked connections when in auto-learn mode, when the Connections window is open, or when it has been closed less than 2 minutes ago. TW will otherwise disable Windows' network block logging to prevent the side-effects I have described. Everyone is free to judge how serious these side effects are. Obviously, if you are on a dekstop system, you are not concerned about battery life. Also, how much disk activity it causes depends on the number of events that need to be logged, which will vary between systems and usage scenarios. I am simply not taking the risks. The fact that this logging is not enabled by default by Microsoft makes me think that my concerns are valid. The good news is, I might have just found a way around this problem two days ago, but I didn't yet get to test it. Wish me good luck. Simple, as all other firewalls should: by not touching them. Firewalls are not supposed to tamper with WSH networking rules, instead, services are supposed to set their own WSH restrictions during install. This is also the semi-official recommendation by Microsoft. Let me shed some light on this for non-initiated readers: the networking portion of WSH (Windows Service Hardening) consists of simple firewall rules, which are much similar to normal firewall rules, except with two simple exceptions: 1) WSH rules take precedence over "normal" firewall rules, and 2) WSH rules can only block. So the only goal of WSH rules is to restrict services from doing things they shouldn't. But because TinyWall only allows services what they should be doing (and otherwise blocks them), WSH networking rules basically become redundant and provide only little additional security. WSH rules have the additional advantage that hey cannot be overriden using firewall rules (e.g the Windows Firewall can't allow a service if a WSH rule says otherwise), but TW does not delete your WSH rules, so this advantage is still in effect. Anyway, any firewall that touches WSH networking rules is a bad firewall. Not just because of Microsoft's recommendation, but it is pretty easy to see that this is the only way it makes sense. The only thing TW could/should do with WSH is to set a WSH restriction on its own service during installation. I might just actually do that.
Thx. Not any more. Please leave TW two days to update your hosts files, because that is how often it checks for updates.
2.1.3 was released that contains a fix for a recently discovered issue, reported to me by e-mail. The changelog is short, and I would usually wait before more changes pile up, but I find this fix important, so I did not want to delay. Previous installations will auto-update. The issue that this update fixes is exclusive to 2.1, it did not happen in 2.0. Code: Changelog for 2.1.3: - Fix: A network zone change left outgoing connections unfiltered (2.1 regression) - Various Hungarian, Japanese, and general localization updates On a different matter, I would like to give proper public attribution to the person who sent me the very nicely illustrated Translator's Guide, now part of the localization pack as a PDF. Unfortunately, it was quite some time ago, and I was clumsy enough to lose his contact. If he reads this message, please contact me.
2.1.3 (and now also 2.1.2) are broken here. It does not import my settings which I exported with 2.1.2. Is there a download link for 2.1.0?
