Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Allow unlimited time to wait for response, or until process/program is terminated. #994

Open
tv21 opened this issue Jul 22, 2023 · 2 comments
Labels
feature a whole new feature

Comments

@tv21
Copy link

tv21 commented Jul 22, 2023

Summary:

I would like to request that OpenSnitch give the user the option to make it behave more like Little Snitch on MacOS in this regard: When a process or program generates a popup, leave it on the screen until the user responds to it, in other words don't automatically take a default action just because the user has not responded.

The reason for this is simple, some of us leave our computers running 24/7 for various reasons but we have to sleep and to leave the computer to attend to other thing. It is not safe to make the default action allow (that would sort of defeat the whole purpose) so the default is left at deny, but under those circumstances OpenSnitch will generate an automatic deny. Then when we do come back to our computers, some things may have stopped working and we have no idea why because OpenSnitch denied the connection and closed the prompt window but we never saw that.

The way Little Snitch handles this is to simply leave the prompt window up until the user responds, OR the program or process that is requesting the outbound connection terminates. In the latter case, LS flags the process as terminated and the prompt window changes to show that, then a few second later it goes away entirely. This makes sense because at that point accepting or rejecting the connection would be irrelevant because the program or process is no longer running.

The lack of availability of a good alternative to Little Snitch is one of the few things that has kept me from switching from MacOS to Linux, and I was hoping OpenSnitch would be that alternative but I can't have it making decisions for me just because I took a bathroom break or something. I really need it to leave the prompt on the screen until I explicitly approve or deny it, not just deny something because I did not respond quickly enough. Could you please make that an option in future releases? Or at least not arbitrarily limit the time that can be set for a notification to remain on the screen before taking the default action? I mean, if the upper limit could be set as high as 604800 seconds, that would be a week, and if I haven't responded to a prompt in a week I'm probably dead!

@tv21 tv21 added the feature a whole new feature label Jul 22, 2023
@gustavo-iniguez-goya
Copy link
Collaborator

Hi @tv21 ,

This has been requested a couple of times before (#783), and was closed as not planned, for a couple of reasons:

  • The kernel has a timeout for connections that cannot be established (around 2 minutes, in 3 attempts of 30s each).
  • While a pop-up is displayed to the user, the DefaultAction is applied on new connections that are not already allowed/denied.
  • We offer several options to let the users know that something happened.

It is not safe to make the default action allow (that would sort of defeat the whole purpose) so the default is left at deny, but under those circumstances OpenSnitch will generate an automatic deny. Then when we do come back to our computers, some things may have stopped working and we have no idea why because OpenSnitch denied the connection and closed the prompt window but we never saw that.

You should have 2 visible warnings of what happened: a desktop notification in your systray, and the systray icon changed with an exclamation mark:
image

On the other hand, the "automatic deny" can be temporary. You can configure the pop-ups to generate a tempory rule of 30s for example, so when you come back you'll probably be prompted again to allow/deny it (if it's still alive).

The way Little Snitch handles this is to simply leave the prompt window up until the user responds,

What happens if another process tries to establish a new connection not allowed while there's a prompt window already opened? does it stack the pop-ups or applies a default action?

OR the program or process that is requesting the outbound connection terminates. In the latter case, LS flags the process as terminated and the prompt window changes to show that, then a few second later it goes away entirely. This makes sense because at that point accepting or rejecting the connection would be irrelevant because the program or process is no longer running.

Does it show to the user a notification explaining what happened? or does it just close the prompt window?

I mean, if the upper limit could be set as high as 604800 seconds, that would be a week, and if I haven't responded to a prompt in a week I'm probably dead!

What do you expect of the rest of the connections that are not allowed/denied yet while a prompt window is opened?
Apply a DefaultAction?

@tv21
Copy link
Author

tv21 commented Aug 4, 2023

What happens if another process tries to establish a new connection not allowed while there's a prompt window already opened? does it stack the pop-ups or applies a default action?

Sorry for not responding sooner, I've been away for a bit. Anyway, it does stack the pop-ups (the ones that were not cancelled because the program terminated). So if you walk away from the computer, the first pop-up you see when you return will be the one for the first connection that had not previously been allowed/denied, and when you respond to that it will show you the next one, and so on. In the case where a program terminates, it simply closes the pop-ups associated with that program after a short delay - if you are not there to see that happen then there is no indication that those pop-ups were ever there, but as far as I'm concerned that's fine - if the program or process terminated then there is no point in allowing a connection anyway, and eventually it will come up again when I am at the computer.

What happens if another process tries to establish a new connection not allowed while there's a prompt window already opened? does it stack the pop-ups or applies a default action?

Basically what it does is force them to wait their turn, but be denied in the interim - the default action is to deny the connection until the users responds to the pop-up. And that is what I wish OpenSnitch could do. What sometimes happens in Little Snitch is I will get a popup I don't recognize and that I have no idea how to respond initially. It could be I don't recognize the program or process, or it could be I don't recognize the address it is trying to go to. In some cases Little Snitch will helpfully show what I assume is reverse DNS information, showing the address(es) that resolve to the IP address the program is trying to connect to, but in any case I will often take the opportunity to use a search engine to look up the program, process, or IP address (in cases where the reverse DNS isn't given). The obvious problem with doing that in OpenSnitch is you just don't have enough time; too often the prompt disappears while you're considering what action to take.

On the other hand, the "automatic deny" can be temporary. You can configure the pop-ups to generate a tempory rule of 30s for example, so when you come back you'll probably be prompted again to allow/deny it (if it's still alive).

I had not thought about that, my only thought is that could still be kind of annoying at times in that if the default is that you deny for 30 seconds, there are still going to be times when you are about to click on a choice and the pop-up just disappears. The worse scenario is that you are just about to click on "allow", and the pop-up disappears and a pop-up for a completely different program or process appears and it is definitely something you would not want to allow (unless OpenSnitch has some kind of enforced delay between the closing of one pop-up and the appearance of another, or a delay after a pop-up appears before a click will be accepted, or something like that). I will need to try that and see if it works out, thanks for the suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a whole new feature
Projects
None yet
Development

No branches or pull requests

2 participants