[Bug Report] Action names (Deny vs. Reject) and colors are misleading

[mixmastamyk]

Half bug, half enhancement. I recently spent hours on an issue and even bothered Mozilla about it because the Opensnitch GUI has Actions labeled as Deny, Reject, & Allow.

The first problem is the words Deny and Reject mean 99% the same thing, so they are confusing. Which to choose, I don't know. Second, the behavior is very different.

Deny seems to drop the connection into a black hole so the program sits there doing nothing until the connection times out. This causes a web browser to hang in some instances, for example blocking rendering on css or javascript from third-party domains. Been suffering with this.

But, Reject rejects it immediately! Program gives an error right away. That's what I typically want to default to. The most safe and convenient.

Third, the color for Deny is more attractive. When you want to block something, red seems like what you want, like a STOP sign, etc. The Reject color is purple, which is different but not obvious it really means NO.

So, I've been making my hundreds of rules with action:Deny, but I should have been using Reject all this time !

• Please change the name Deny to Drop
• Please change the color of Reject to the red one ! Deny could be purple:

i.e.:

Label	Text
Allow	green
Drop	purple
Reject	red

Include the following information: All versions, all supported OS.

To Reproduce:

Create a new rule and look at the dialog box for action. Don't forget pop-ups and Preferences.

Cheers and thanks for considering.

[blaccod]

Well, I think the reason why it is called "Deny" instead of "Drop" is simply because this is an application firewall, so the two options are either "allowing" or "denying" the application from contacting something. At first, selecting "Deny" already rejected the package using iptables under the hood aa3eb13, meanwhile the ability to explicitly say whether the packet should be dropped or rejected is much newer 8d3540f. You can see an old screenshot showing only two options in the Wiki

The problem of dropping packet causing browser slowdown is also reported by #481, and was the reason why "reject" was added as an explicit option.

I think the devs did not change the keyword at that time because 1. They forgot (lol) and 2. Changing that will make it confusing for existing users, break existing rules, and realisitically won't affect 99% of users (all they care is the program not snitching and connecting to the Internet, whether the packets are dropped or rejected is irrelevant)

Would a name change make it clearer? Maybe, if the user is already familiar with the underlying firewall terminology. Both iptables and nftables use drop and reject in their rules, as they're talking about individual packets. OpenSnitch, to me, looks more like ufw where we make broad rules without caring about the firewall backend and its syntax, and ufw also uses "deny" and "reject" in their syntax.

Third, the icon and color for Deny is much more attractive. When you want to block something, red seems like what you want, like a STOP sign, etc. The Reject color is boring... don't look here. But the opposite is true.

I don't entirely agree here. Both achieves the same end result (the program can't connect to Internet), and coloring "drop" gray makes it not stand out. I feel like purple is distinct enough from green and red, no? GitHub also uses the holy trinity of red, green and purple for issues and PR coloring.

But, Reject rejects it immediately! Program gives an error right away. That's what I typically want to default to. The most safe and convenient.

I agree with you here. There are arguments to be made on dropping packets for incoming connections, but for outgoing ones, I can't think of any advantage of dropping over rejecting packets. And the docs/README can certainly benefit from a clarification between allow, deny and reject.

[mixmastamyk]

Hi, thanks you reminded me of the text color, which I forgot to mention.

Third, the icon and color for Deny is much more attractive. When you want to block something, red >> seems like what you want, like a STOP sign, etc. The Reject color is boring... don't look here. But the >> opposite is true.

I don't entirely agree here. Both achieves the same end result (the program can't connect to
Internet), and coloring "drop" gray makes it not stand out.

Maybe it is a cultural thing (in which case I don't know how to bridge it), but in "the West" stop signs and stop traffic lights are always red. I said grey both because the Reject icon is currently that color and indeed I don't want Drop to stand out.

But since the other color text is purple perhaps that makes more sense to make them consistent.

[mixmastamyk]

Also forgot to mention, it is likely the case that the GUI labels can be changed without affecting other code. Though probably less tech debt to fix any misnamed Enums as well.

It makes sense this happened because of a historical accident, but hopefully we can fix it.

[blaccod]

Maybe it is a cultural thing (in which case I don't know how to bridge it), but in "the West" stop signs and and stop traffic lights are always red. I said grey both because the Reject icon is currently that color and indeed I don't want Drop to stand out.

Wait, I think I'm having a misunderstanding and we're talking about different things. Where in the GUI is the reject icon gray? The text for reject is purple in "Action" column of both "Events" and "Rules" tab

And has a white color everywhere else (e.g. here in the popup every time an app requests network access)

Slight tangent about cultural thing: In China "red" means good (red lines when stock market go up). But they also have a lot of red traffic signs, and I think the idea of "red"=block, "green"=allow should be universal enough to not cause problems

Also forgot to mention, it is likely the case that the GUI labels can be changed without affecting other code.

Yea, but then we will have two seemingly different words in the codebase that refer to the same thing. Imagine a new contributor trying to fix problems related to the drop rule, and they can't find the "drop" keyword anywhere in the code...

[mixmastamyk]

Mine looks like a thick grey X. Perhaps it is themed or an emoji font? so will differ.

Now that I think of it the icons look a lot like the Gnome/Mate emblems, so they probably differ based on what theme is configured. Or perhaps a QT version of the same.

[blaccod]

Yeah, that looks like the icon set theming of your desktop environment or something. You can change the theme in Settings to see if any other ones suit you at all. For example, this is dark_white.xml:

2. Alternatively, you can reconfigure Qt to use a different icon set. Look at this Wiki https://github.com/evilsocket/opensnitch/wiki/GUI-known-problems#no-icons-on-the-gui and this discussion [Bug] No Icons In App #998 as a start. Note that the newest version (1.8.0) is Qt6, not Qt5, so the above info needs to be adapted a bit.

3. You can install more Qt themes and force Opensnitch to use that. For example: QT_QPA_PLATFORMTHEME=generic QT_STYLE_OVERRIDE=Windows opensnitch-ui for some Windows 95 look :)

4. You can maintain your own "fork" of the Opensnitch UI. Clone the project, create a venv inside opensnitch/ui, install dependencies, then run ./bin/opensnitch-ui. As the UI and the opensnitchd daemon are two separate things, you can keep using the daemon installed using official methods, no need to recompile that part at all. Then you can install any custom theme/icon set you want and modify whatever. It's open source after all :)

[gustavo-iniguez-goya]

I have no preference on what terminology to use. As blaccod said, 99% of the users will understand what it means.
I do think though that Reject is stronger than Deny or Drop.

Same for the icon colors, I chose them just so the options had an icon. The issue here is that the color depends on the icon theme. We could create our own icons, but we should take into account light/dark themes, etc.

Regarding the color customization on the views: the GUI can be colorized based on patterns.

• each view has a configuration to customize the colors with a name: commonDelegateConfig, defaultRulesDelegateConfig, netstatDelegateConfig and defaultFWDelegateConfig

• documented here (and not everywhere else because it's no finished):

  opensnitch/ui/opensnitch/actions/__init__.py

  Line 21 in 3a5783d

  """List of actions to perform on the data that is displayed on the GUI,

• default configurations are here: https://github.com/evilsocket/opensnitch/blob/master/ui/opensnitch/actions/default_configs.py

• in order to customize the colors, copy one of the default configurations and place it under $HOME/.config/opensnitch/actions/name_of_the_config.json

  example to highlight rules rows based on patterns

  /home/user/.config/opensnitch/actions/defaultRulesDelegateConfig.json (the filename can be random)

  {
  "name": "defaultRulesDelegateConfig",
  "created": "",
  "updated": "",
  "description": "customize rules list. The name of this action MUST be defaultRulesDelegateConfig for now.",
  "actions": {
    "Highlight": {
        "enabled": true,
      "cells": [
        {
          "text": ["allow", "True"],
          "cols": [3, 4],
          "color": "green",
          "bgcolor": "",
          "alignment": ["center"]
        },
        {
          "text": ["deny", "False"],
          "cols": [3, 4],
          "color": "red",
          "bgcolor": "",
          "alignment": ["center"]
        },
        {
          "text": ["reject"],
          "cols": [3, 4],
          "color": "purple",
          "bgcolor": "",
          "alignment": ["center"]
        }
      ],
      "rows": [
          {
              "text": ["allow"],
              "cols": [4],
              "color": "white",
              "bgcolor": "green"
          },
          {
              "text": ["deny"],
              "cols": [4],
              "color": "white",
              "bgcolor": "crimson"
          },
          {
              "text": ["False"],
              "cols": [3],
              "color": "black",
              "bgcolor": "darkGray"
          }
        ]
      }
    }
   }

The idea is to allow users create rules/configurations from the GUI to highlight specific connections, events, etc.
Not configurable from the GUI yet. We'll get there soon.

[mixmastamyk]

Hi, I disagree that 99% understand the difference in terminology, as I and another user have just expressed that we didn't understand it. Also most people use browsers and not many other protocols, so the page slowdown issue affects them even if they don't know why.

Now that we've figured this out, am advocating for new users falling into the same trap.

I suppose we can forget about the icon part for now, as a change isn't straightforward with theming involved. Just removed that column from the little table.

[tredondo]

I do think though that Reject is stronger than Deny or Drop.

I'm from "the West" and an engineer, but web not Unix internals. I thought Deny was stronger than reject and was confused by the differences too - #1269

[mixmastamyk]

As a native English speaker I'll repeat that the two words (Deny, Reject) mean the same thing, they are synonyms. Perhaps the "D" sound sounds somewhat stronger than the "R" sound, but that is merely coincidence. 😅 Please use "Drop" instead of "Deny."

[Venomtek]

Why is this submitted as a bug? Just installed this awesome app for first time, coming from winblows I was using tinywall. Took me all of 30 seconds of my life to search the difference between DENY and REJECT and the implications. I don't see the problem here. RTFM?

[mixmastamyk]

@Venomtek
Why should every person who tries this have their time wasted? Even thirty seconds, but bet it was longer than that and longer on average, times ten thousand people. First you had to notice something wrong and wonder what possibly could be the issue. While your browser was slow AF.

The description was not very helpful, and still it explains how, but not the ramifications. That's one problem. But even if it was, the action names continue to mean the same thing for no reason.

Bad defaults and misleading names are often why FOSS continues to lag. I'm speaking up for the next ten thousand.

"So, put an egg in your shoe, and get outta here." </Biff>