0strodamus

I would like to suggest the following relatively minor improvements to NOD32: 01) Allow the HIPS rules window to remember the last size and position. It is tedious to have to resize this window every time. 02) Add a setting to make the alerts popups open the advanced options drop-down as default. 03) Better wildcard support for the HIPS module. For example, allow items such as "C:\Windows\*.log". 04) Allow wildcards for Source Applications in HIPS rules. As the final rule of 3 out of 4 policies is to allow the action (including the default policy), this would NOT be a dangerous modification. There are instances where this would be quite useful. Some examples: a.) on a system running the Surun application every application needs to be able to launch surun.exe b.) many applications may need to write to "C:\Windows\Rescache\rc000*\rescache.hit" c.) many applications may need to write to "C:\Windows\CSC\v2.0.6\namespace\localhost" It would make rulesets much smaller to integrate all these actions into a single rule for Source Applications "C:\Program Files\*" and "C:\Program Files (x86)\*", instead of so many separate rules. If you've made it this far into my post, thanks for taking the time to read. Any consideration of these changes by the ESET developers would be greatly appreciated.

This is happening to me too, but with EAV, not ESS. It is not the Application update. That worked fine. It is the virus signature database update. This happened with the scheduled update and also a manual update I initiated after a reboot. The last successful update was 8704 (20130819). The update GUI needs a Stop or Cancel button added (unless there's another way to cancel an update I'm unaware of). FYI: There's a couple other users affected who posted in the beta feedback thread.

I don't see anything in the link you provided that states that Windows Defender will disable itself when a 3rd party AV is installed. My post was not intended to be negative. In my opinion, wrong and inaccurate information can often cause more harm than good. I think the information you provided may not be accurate, but of course I could be wrong. That is why I asked about a reference. The burden of proof is on you because you made the statement. This is the nature of having a dialog. I'm sorry if you perceived this as some sort of a personal attack. At any rate, it doesn't matter and I don't want to contribute any more than I already have to derailing this thread.

Where are you getting this information from? IMHO, this beta feedback thread is getting derailed by too much conjecture.

Thanks for the reply Marcos. I'm a home user, so I'll have to just use ecls.exe and go without the GUI results window. I found the knowlegebase article on how to use it, so I should be all set.

Is there any way to manually run a GUI scan other than via the Windows explorer context-menu? I know I can use ecls.exe to perform manual scans. I am just wondering if there is a way to use the GUI from a command line or sendto shortcut and launch a scan of folders and/or files like the context-menu does. I searched the knowledge base and Wilders without success, so I am guessing that it can't be done and would like confirmation. Thanks!

Jetico has released an updated version that fixes the compatibility issues. My sincere thanks to JavierSeguraNA for kindly replying to my thread and for confirming the compatibility issues.

If a user chooses to limit the context menu items displayed in the settings, it causes the context menu text to be too long. Can you revert the text back what it was in version 6 when a user limits the context menu items? I know it was added for clarity, but if a user has selected what to display in the settings, then they don't need the extra text for clarity as they already know what they chose. I hope that made sense. version 6: version 7:

I miss the eye icon, but the e icon isn't so bad. I'm happy the animations are still in place. For me, they are what's most helpful as far as the tray icon is concerned.

Good luck with that! I'm having a hard time finding anything wrong with it too!

I agree that these types of rules can be dangerous, however, they can also cut down greatly on the size of a ruleset. I don't know how much of an effect this has on performance, but it can't hurt. For example, on my system I have a bunch of applications that try to write to "C:\Windows\Rescache\rc0005\rescache.hit" and "C:\Windows\CSC\v2.0.6\namespace\localhost". It would be nice to just allow these file accesses under a rule with source applications "C:\Program Files\*.*" and "C:\Program Files (x86)\*.*" instead of having to add each application one by one. I also use many NirSoft applications and they all write to separate configuration (.cfg) and report (.html) files in the Nirsoft folder that I have them all in. Again, it would be nice to be able to add as the source application "C:\Program Files\NirSoft\*", instead of adding them all individually. Another, example is that I use SuRun and run in a limited account. Many applications need to launch SuRun and it is the only HIPS allowed access that they need. In my opinion, it would be better to create a rule allowing "C:\Program Files\*.*" and "C:\Program Files (x86)\*.*" to launch Surun.exe instead of adding them all individually. And honestly, when the behavior of ESET's HIPS module in, for example, interactive mode is Rules > Ask > Allow on Failure, what is so dangerous? The HIPS will allow anything without a rule anyway. Am I wrong in this conclusion? I can only see the merit of it being too dangerous if a user is running in Policy-based mode as it is the only mode of the 4 available that will block by default. Thanks for the tip regarding quicker editing of the rules. That will come in handy.

After getting my bearings running v6 for a couple weeks, I went ahead and took the plunge with v7.0.104.0. So far, it is running smooth as silk. Great job ESET!

I would like the same feature to be added to the HIPS. I don't think you'll find an answer until ESET decides to add this ability. I've found some clever ways around other limitations in the HIPS, but not this one!

That's what makes ESET special! Why would you want them to just be average like all the other antiviruses?? You can always disable PUA if you don't want the detections. ESET should continue to detect all PUA!

Some improvements that I would like to see in the next beta. ALERTS: Add option to open the advanced options drop-down as default HIPS: Improve rules window to remember position / size HIPS: Allow adding a folder to "Source applications" like "Target applications"; i.e. C:\Program Files\*.* HIPS: Improve file wildcard support; i.e. C:\Program Files\*.ico or C:\Windows\*.log HIPS: Add command line parameter with wildcard support for cmd.exe