1. What version of CIS, or Comodo Firewall, are you currently using:
COMODO Internet Security 7.0.317799.4142
2. What actually happened or you saw:
The widget currently has an option called “Always on top” which is supposed to keep the widget on top of other applications, the issue with this “always on top” is that other applications also using always on-top can get on top of the widget even when that setting is enabled for the widget (fullscreen applications can do the same). Thus, it is not truly always on top.
3. What you wanted to happen or see:
I would like to see an additional “Always on top” that really fights to ALWAYS stay on top, even over other fullscreen applications and other applications using always on-top techniques. (This could be called something such as “Aggressive always on top” perhaps). This should not be enabled by default, but should be optional.
4. Why you think it is desirable:
The main reason is making the widget more resilient in situations like screenlockers etc, currently a screenlocker would be able to stay on top of the widget but with this suggestion the widget should be able to stay on top of the screenlocker and let the user clear the sandbox and start killswitch etc, assuming those are pinned to the CIS taskbar.
The reason for keeping two different always on top options is that a more aggressive always on top isn’t always desirable, for example if you often use full-screen applications etc.
5. Any other information:
When this setting is enabled, any CIS window that is launched from the Widget should also inherit the aggressive always on top property and maintain it until that CIS window is closed. This is to make it even more resilient to screenlockers.
Interesting suggestion. However, I wonder if whether, in those times when the widget cannot be accessed due to a screenlocker, whether it is still possible to open CIS in another way. Can you confirm that there is no other way a novice user could open CIS in that situation without restarting the computer?
I don’t know… I can’t think of any way to do that.
Edit: I just realized a huge drawback for the screenlocker argument, even if the widget would be visible, if you click for example the icon to open the “reset sandbox” window then the normal CIS window for reset sandbox will open… and it won’t open as always on top, so for this wish to be effective against screenlockers then if the widget is set to aggressive always on top then the launched CIS window should also inherit that aggressive always on top setting (and maintain it until that window is closed)
Edit 2: Edited wish to accommodate for the above issue, I would argue that it is not two wishes in one (please don’t claim it’s two wishes and I’ll have to settle with one, they’re both needed equally much for the other to be effective, it’s a necessity to have both for one to exist otherwise it’s just a wasted feature.
This is an interesting wish, which is difficult to figure out how to process. I believe that the reason it is not always in front is because of Windows limitations, as I submitted a bug report similar to this a long time ago which was rejected as it was due to Windows and not CIS.
However, your report is making me think that there is another, major issue. This is that currently a screenlocker can control the screen such that the user cannot access CIS to kill it, regardless of whether it is through the widget or otherwise. If you can replicate this I think the best approach would be to create a bug report for it. It would be more likely to be addressed through that avenue, although if necessary it could always be changed to a Wish later on and moved accordingly.
My thoughts is that I don’t have a screenlocker to test with and even if I did I only have one computer and I don’t want to run malware on it.
If I put it in this way, if one application is able to use “always on top” in order to stay on top of the widget (which is also using “always on top”) then logically a screenlocker could do the same thing for malicious purposes. Also, what other means to we have to get to CIS? Task bar? The screenlocker would obviously be running in full-screen so we’d have no taskbar (And the screenlocker would continuously check that it is in fullscreen mode so that if it is minimized somehow it would pop right back up) Alt+Tab? Even if we were to be able to choose CIS using Alt+Tab the screenlocker would still show on top of CIS because the screenlocker is set to be always on top while CIS is not. Ctrl+Alt+Del? Maybe, but the default task manager still doesn’t use always on top so the screenlocker would be on top of that too.
Note that the above descriptions of a screenlocker may not be correct, it’s just how I would personally make them…
Also I believe this would be of most use when using FV sandbox since you can’t reset the sandbox for other levels of sandbox… Just Sanyain.
Thank you for submitting this Wish Request. I have now moved this to the WAITING AREA.
Please be sure to vote for your own wish, and for any other wishes you also support. It is also worthwhile to vote against wishes you think would be a waste of resources, as implementing those may slow down the wishes you would really like to see added.
I have had a second look at this wish and have voted yes. :-TU
For some users the aggressive ‘Always on top’ mode could enhance security, especially when testing or checking different scenarios.
Under these circumstances the Widget maybe used as a type of system status monitor for the number of sandboxed items, connection traffic monitor etc.
Also under certain circumstances it maybe handy to have your regularly used CIS tasks just one click away without the risk of it hiding.
There was a mistake in the wording of the title which may have caused some users to misunderstand the wish. Thus, with permission from Sanya IV Litvyak I have reset the poll count to 0. That means that if you had previously voted you will need to vote once again. I will also start the 6 month countdown from this day.
Interesting idea, but wouldn’t “Always always on top widget” interfiere with full-screen programs, like games? I wander if better solution would be adding a key combination that will bring CIS main window (and any windows that it’ll produce) on top of whatever is on the screen? Or better yet, execute rkill-type program, that will terminate all non-critical \ non-cis processes.
Yes it would interfere with full-screen applications, it’s not a setting I’d recommend most users to enabled, however personally I have two monitors, my primary and secondary monitors, full screen applications are always run on the primary monitor while I have the widget on the secondary monitor, hence if “Aggressive Always On-Top” was available it wouldn’t be an issue for me.
Although from further testing I have arrived at the conclusion that the devs were probably right about the limitations in Windows, from my previous testing I noticed that other Always On-Top applications can stay above the CIS widget (when the widget had the always on-top enabled) however what I then realized in my newer testing is that they both have the “highest always on-top” if that makes sense, and it’s simply the last one to be active that gets on-top of the other, hence for the “aggressive always on-top” to work then the widget would have to have the “always on-top” enabled and it would have to force itself to be the active window, this would interfere with normal computer usage on an extreme level to be honest.
So honestly I believe that this wish is impossible, HOWEVER, wouldn’t it be possible to make the widget always show on-top of FV sandboxed items? So for example if a ransomware with screenlocking capabilities got installed in the FV sandbox then the widget is still kept on-top. (This should be possible? I mean, doesn’t Comodo decide that since they’re in charge of what goes on in the sandbox? ???)
I would like to thank everyone who has voted on this particular enhancement. As this wish has accumulated the necessary 15 points I have added this to the tracker for consideration by the devs. However, do note that even though this wish will be considered by the devs, it does not necessarily mean that it will be implemented. I will update this topic when I have any additional information.