See, I started all of this by reading the documentation about global rules. It mentioned the order in which it was processed, which only implies order of priority for rules. Furthermore, what you have said there does not show me that global rules do act as global rules. The behaviour of application rules are not what are in question here - I have set custom mode, as I wish connections without any assigned rules to be questioned. However, if when a global rule is created and the firewall still questions the connection with a pop-up simply because it could not also find an application rule, then no matter how you spin it, that is not a global rule. It may not be application-specific, but it also is not a rule that is applied to all incoming connections that match it (global) if the application rule filters still need to be queried in order for the connection to pass.
To be honest, now that I know that you can use wildcard entries for application paths (something that was mentioned no-where in the relevant documentation pages!!), I’m not quite sure what the supposed global rules section is attempting to accomplish, as the same functionality can be achieved within the application rules section. As best I can tell from what you have said and the exceptionally limited documentation available on the subject, there is absolutely no point in ever creating an “allow” rule in the global rules section - if there isn’t a matching allow rule in the application rules section then it will ask, and if there is a matching allow rule in the application rules section then, well, you didn’t need the entry in the global rules section entry anyway, as the application rule on it’s own was sufficient. It appears that it only exists to set certain block conditions.
I’d be quite happy to see if I was wrong here, but unfortunately, the documentation doesn’t cover any of this. It doesn’t mention wild-cards, it doesn’t mention that the order of global/application filtering is not simply in the priority of the rules, but that a global rule also requires an application rule in order to be allowed. If what I have said above is also true, then it completely skims over that rather pertinent detail.
The fact is that the existing documentation isn’t even consistent with the process that the firewall actually performs. For an outgoing connection, application rules are first - if there is no rule it asks, if there is a rule, it is allowed. Global rules are second. If there is a global rule but no application rule, it still asks. If there is an application rule but no global rule, it allows the connection. However, the order for incoming rules, according to the documentation, is reversed and yet, the result is exactly the same as outgoing rules. Global rules are asked first. According to the order then, if there is no global rule, the connection attempt should result in a pop-up. However, if there is no global rule it just passes right on by to the application rules. If there is a global rule… it still passes straight on to the application rules and will query the connection attempt if there isn’t a relevant application rule.
Simply put, the order is ignored in favour of the fact that if there is no application rule, the firewall will always query the connection, regardless of order. Inversely, the firewall will never query a connection if there is a lack of appropriate global rule, regardless of the order in which the rules are checked. So firstly, the documentation fails to mention that the filter checking order mentioned in the global rules documentation section is not, in fact, simply a priority check, but a layered check. Then it fails to mention that the order is not actually entirely true and that application and global rules are not checked equally!
I appreciate that this wildcard functionality is there. What I don’t appreciate is the documentation not actually stating this fact, nor that the documentation doesn’t make clear the true functionality and order of global rules. Nothing on any relevant manual page mentioned anything about either of these crucial points.
I don’t ask that you change the documentation into a hand-holding baby-speak exercise, but adding crucial information about the way that your firewall acts would be quite helpful!