Izumi:
> you should put MD5 hash of the installer on the download page so we can verify the integrity of our download.
Done, Thanks.

> (i get 404 not found)
Also corrected, thx.

Rilla927:
The application database and not notifying about connections are two different things. The database is not there to replace the popups. The database 1) makes it unnecessary for the user to know how each application should be configured and 2) makes sure that an application is not compromised at the time of whitelisting. In fact, some large firewall companies (who rely on popups) have their own databases of safe programs to reduce the number of clicks for their users.

m00nbl00d:
It is not supported. Currently you cannot block specific IPs or domains. The way TinyWall works is that everything is blocked, and you can unblock specific ports for specific applications on your computer. IP-blocking capability will probably come in a future version.

Izumi:
Rilla927:
The application database and not notifying about connections are two different things. The database is not there to replace the popups. The database 1) makes it unnecessary for the user to know how each application should be configured and 2) makes sure that an application is not compromised at the time of whitelisting. In fact, some large firewall companies (who rely on popups) have their own databases of safe programs to reduce the number of clicks for their users.

Click to expand...

Okay, I'm missing something here. I'm just trying to understand how this works.

If the FW opens ports automatically, where does it get this information from if it isn't a built in data base?

Firts of all, thank you all very much for your input and feedback. I really appreciate it.

tony62:
Thanks for the screenshots. I see some small UI corruption in the connections dialog (checkbox sliding into the list), which doesn't happen on my development machine. I'll try to workaround that.

> A window or tray menu link to view blocked processes connections.
Currently there is no feature to show blocked connections, but I see that it would be helpful. I'll sure implement it, I'm only unsure if I will do it in the current 1.0 version or in 1.1 after that.

> What is the 'Private zone'?
That is just information showing you in which firewall/network zone you currently are. It doesn't do anything, it is only informational. All applications you unblock will be allowed in the same zone only that you unblocked them in. So for example, if you have a laptop and you're surfing on a public WiFi (which puts you into the Public firewall zone), you can have a different set of applications enabled than at home.

> What is the 'Prompt for profile association for recognized applications check box for'?
TinyWall has a built-in list of safe applications that it can recognize and knows which communication profiles to allow for them (for example, Internet Explorer will be allowed ports 80/443 outbound, which is the 'Web browser' profile). If you are unblocking a reocgnized application, TinyWall will not ask you for the profile because it already knows how to handle that application. On the other hand, if you are unblocking an application that TinyWall doesn't know yet, you will get an extra prompt where you can tighten the rules on that app instead of giving it full access to the network. So here is how this option comes into play: if 'Prompt for profile association for recognized applications' is checked, you will always be asked for the profiles, even for recognized/known applications. This is basically just a UI/comfort setting and does not influence firewall operation.

> Add application to allowed via connection's window
Already thought about that and I am willing to do it, but the current inner workings of the controller app inhibit such a feature. I need some time to rework things. At latest, I will definetely implement it in the first post-1.0 release.

> Have connections window remember size & include a maximize button
Will do that right away.

Click to expand...

I see this as being the sort of firewall I've been waiting for in a very long time.

UTIM
Some useability suggestions, besides build in list
a) Option to allow Microsoft programs by default
b) Option to allow signed programs by default
Great work

Click to expand...

a) Unfortunately, most important MS executables that are part of the OS (eg. svchost) do not come signed, so the only reliable way to detect their authenticity is using hashes. But that can change with every Windwos Update, so I dunno if this will come.

b) If I want to intercept connection requests from programs and be able to decide what to do, I would need to install kernel-mode code, eg. drivers. So I won't go that way. Without kernel-mode I could still detect programs trying to connect, but only after they have already been blocked. Besides, this would trigger a certificate check for every blocked application, which would be very disk-intensive.

What I am thinking of is a way to do a one-time installation check of security software that update often (e.g Windows Update, antivirus...) and unblcok them automatically after confirmation by the user.

For this I need to collect signatures of antivirus updaters. So if anybody is trying out TinyWall and has antivirus software installed, please help me out here. Start the TinyWall/DevelTool from the start menü, and in the very first browse-button select the updater of the antivirus. Then click "Create" and send or post the XML output. Thx.

PS:
If you need more custom view, to better customize system log events by configuring auditing based on categories of security events such as changes to user account and resource permissions, failed attempts for user logon, failed attempts to access resources, and attempts to modify system files, and network activities.

Okay, for anyone who is using the beta and is wondering why he cannot get windows live messenger working: it is not enough to unblock msnmsgr.exe. A total of 3 executables need internet access to be able to log in:
C:\Program Files\Windows Live\Messenger\msnmsgr.exe
C:\Program Files\Windows Live\Contacts\wlcomm.exe
C:\Program Files\Common Files\microsoft shared\Windows Live\WLIDSVC.EXE

this simply sucks. i'll try to come up with an idea to solve situations like this in an automagical way in tinywall...

I wanted to include some larger changes in Beta2, but I am putting it out as fast as possible now because I discovered a critical bug. Basically, whenever you'd whitelist a windows service, it would bring TinyWall's own service into a restart loop. Not good. So the larger changes will have to wait until the next beta, but here is Beta2 with a lot of your feedback already incorporated and some extra fixes.

Please upgrade because once you trigger the bug it will be a bit more difficult to fix.

Upgrade notes from Beta1:
Uninstall beta1 first, then install the new version. To uninstall, as stated a 1000 times, Elevate from the tray menu->Manage->Maintenance tab->Uninstall. Save your work first because this will reboot your machine, but fortunately, starting from the new Beta2 a reboot upon uninstall will NOT be required any more.
Changelog:
- Fixed a bug that caused the TW service to crash when whitelisting other services
- Uninstallation no longer requires a reboot
- Renamed option 'Prompt for profile association for recognized applications'
- Connections window no longer needs admin privileges
- Correct UI glitch when resizing Connections window
- Connections window remembers position, size and has min/max buttons
- In the list of application exceptions, mark services with "Srv:" prefix and output service name instead of executable
- In the settings window, rename button "OK" to "Apply". This is to clarify that changes are not saved until Apply is clicked.
- Fix: password dialog was sometimes hidden behind another window. Make sure it comes to front when shown.
- New application profiles included

Wait, if I install TinyWall and it had an update, I will uninstall the older one and install the new version, does my rules created by TinyWall disappear?

Click to expand...

In the current beta2, yes. I will 100% correct that, but as I said, I did not want to delay the fix for the service-crash. Future versions will have an update capability that will preserve your current settings and simplify the update process.

Allowing inbound connections makes your computer totally unprotected. Maybe you should consider another approach. Leave only all outbound connections, but keep blocking the inbound connections, in case of a worm, if you enable it after you are infected, is already too late. Or if the purpose is to disable Windows Firewall completely, rename this action differently, like "Disable Firewall" instead of "Allow all connections".

Yes, but there are some programs that do need inbound connections. I know Avast needs a inbound cuz when I tried it when I was using WF it was blocking the incoming connection and I didn't know what port it used so it wouldn't work.

The FW I'm using now shows Returnil needs a inbound on port 443.

When your program is uninstalled does it mess with any rules in windows firewall at all?