1. What actually happened or you saw:
A process tried to access the Internet.
2. What you wanted to happen or see:
When I temporarily blocked that process, I would liked to have seen it remain blocked for the session rather than for just a billionth of a second.
3. Why you think it is desirable:
While I take great joy clicking through dialogs, I hate to repeat myself.
4. Any other information:
This is my original post on this topic…
Presently, if you temporarily block an application from the Internet, … one billionth of a second later that application will ask for access again, and you must re-block again. You might have to click Block > Block Only three or four times in a row before the app stops asking. Instead, why not allow Comodo to remember that single-user-block for about 20 seconds (allowing any rapid and subsequent attempts to be blocked, too)? That way, the block remains temporary, yet the effect will be carried out for more than a billionth of a second.
Thanks! Fine product, by the way … especially for free.
Okay, so if I am understanding this correctly, you would like to see the block option have a few options. The first would be block once, the other would be to block for a certain amount of time, perhaps 20s. Is that correct?
From my experience the “Block Only” option will block for the process/application session, I think the issue you’re seeing with multiple pop-ups for the same thing might be a result of the queue system or perhaps some other bug.
I just tested it with ping, I tried to ping 126.96.36.199 and I got an alert from CIS and I chose “Block Only” and that was that, it was not allowed to ping for the rest of the session and I didn’t get any more alerts.
Perhaps an extra block option that allows a session block (any process that is temporarily blocked remains blocked until Windows is restarted), or time buffer for the existing block option (a temporary block will enforce that block request for 20 seconds, allowing subsequent ‘retries’ from a process to be caught, and blocked without bugging the end-user).
Both solutions are ideal since nothing has changed between a request to temporarily block, and a new request to access the Internet a billionth of a second later. Also, if you block something like an Nvidia driver updater with a session block option, you can rest assured that Comodo will continue to block that request until you reboot. A third option (as inspired by Sanya IV Litvyak’s posting) would be to flush the popup queue of any following requests from a blocked process, however I find that temporary blocks do not always last for the Windows session, personally.
These options fix the grey area between always block, and temporary block.
Whilst actually being quite in love with the idea of a “block-per-session” function finally being added to CIS,
I’d regard it being rather sufficient and maybe a little more convenient if the user would be enabled to block a certain program just “per internet session”, not necessarily for the whole “windows session”.
So one wouldn’t have to restart the whole system only to re-allow internet access for a program he or she only temporarily intended to see “blocked”.
What’s your opinion on that sort of “compromise”, BoWeavil?
You do bring up an interesting point that I had not considered, however; I have an always-on connection that effectively corresponds with my Windows session. I can kill my Internet connection, but usually have no need to do so. If others connect at-will, your idea may be the better choice.
I have to wonder if a momentary loss of Internet connectivity would become a new problem with an Internet session version of the scheme, though. Maybe an over all solution would be a single contextual-menu option (right-click on the Comodo icon, and choose) that would lift all temporary blocks?
Come to think of it, I thought this was the behavior as well, although I am not sure if it is for the entire session or just until the file is closed.
BoWeavil, are you sure that the files you are seeing this behavior with are not being closed and re-opened by another program? Also, are you sure they are trying to connect to the same IP address, and not possibly trying multiple ones.
I’m not sure exactly how it works, but if it is either of these two behaviors we need to be very careful about the wording of this wish.
In my experience it is the same process, same IP, and same port, per block.
For example, when I just fired up Internet Explorer it tried to access 192.168.0.1 on DNS port 53, twice (two popups). That means I must click Block >> Block only, 4 times. If Internet Explorer kept trying beyond two attempts, I strongly expect that I would have to keep clicking until one of us got tired.
Forget PING, as it is in a CMD Console window and operates a little differently than a Windows program. Please try something GUI based, like a browser, to see if you can replicate what I am seeing. I will include that I am running Windows 7 Home Premium 64-bit SP1 on an Intel Core 2 Quad with 6.00GB Dual-Channel DDR2 in case no one else is seeing what I am seeing.
I did some testing with Chrome and wrote down the alerts but got annoyed by the many many many many connections behind the scenes when not even relevant to any open website etc so I eventually stopped doing it with Chrome but until then no replicate alerts or what one would call it.
After giving up on Chrome I turned to Internet Explorer which had a lot less alerts in general, and indeed I was able to replicate it… once, out of I don’t know how many tries, you can watch the video here.
I still believe that this behavior is a bug, when clicking “Block Only” It’s supposed to create a session block, the session being that of the program, so if killed then it resets. You can see that it remembers my “Block Only” answer for when I for example try to connect to sweclockers.com a second time as well as most of the time.
Other than that I remember having this issue with HIPS, especially when clicking “Block and Terminate”, then it will show another alert right after with the same things…
Either way, point is this behavior is most likely a bug and a wish for it to change may a) not even get verified and b) get less attention than a bug report.
BoWeavil, I am going to move this Wish Request to Rejected. The reason for that is that this does not seem to be an enhancement request, but it does reveal that there is likely an issue with CIS installed on your computer.
Please create a new bug report for this issue in this section of the forum. Be sure to use the format provided in this post. Just copy and paste the code. Then replace the question marks with your responses.