Hello Ewen! He has a similar topic which other members and my self are trying to explain to him. That's what i was referring too
I was posed here because i thought these issues maybe related.
I was trying to help you guys improve COMODO because i like it (it reminds me of Tiny Firewall which is the BEST firewall. period). If there is tiny firewall for vista i would not bother you with my sugestions , but there is none..
I would suggest the comodo develdopers to take a look at how the tiny firewall 6.xx.xx works (they have multiple hash per exe, you can assign multiple group of policies to exe, etc...)
As i pointed in the other threads, you NEED/HAVE TO make sure (via hash, crc or w/e) that the executable that uses a given policy (firewall, defence,...) is the one that the policy was made for. I pointed couple of examples (and the simplest one is the install mode, the other are diff kind of bugs, leaks, usage scenarios, driver installs etc..) in which this simple "file path" executable->policy assosiation of yours can be a point of weakness because you really only on the "defense file modification rules and the user response" to keep the exe->rule policy integrity intact.
The security products are used mostly by user who don't know or don't want to bother with too much security details. For example (in case comodo is not in install mode), you may say the comodo notified you for some exe accessing explorer/driver/etc.... AS I USER THIS MEANS NOTHING FOR ME. It would been more meangfull if i see (after i install something for example) that i get a message from comodo saying: THE EXECUTABLE IEXPLORER/FIREFOX got modified... do you want it to PROCEED as BEFORE? Now, currently comodo can't do that because you really on simple file path to associated exe -> policy. Thats why i suggested hash, etc and got nearly "flamed" by the "patrons".
thanks
Topic: 3.0.25.378 Incorrectly Identifies Applications, Resulting in Wrong Rules [Merged] (Read 78943 times)
