Rule Insights

A firewall rule list has a quiet problem: it looks like proof. Thirty entries, thirty things you apparently stopped. But the fact that a rule is in the list never meant it had ever stopped anything. A rule can sit there for a year against a domain the app stopped using before you wrote it.

Every domain rule now carries its own record, on the row itself: how often it fired, and when it last did.

The counter reads the last 30 days. It counts the times the rule actually decided a connection, not the number of connections an app attempted.

Subdomains count toward the parent rule. A rule on example.com reports the hits from cdn.example.com and api.example.com as its own, which is what a rule on a domain means in the first place: one rule, one number, rather than a number scattered over hosts you never wrote a rule for.

A high count on a domain you barely recognise is the interesting case: something on your Mac talks to it constantly, and the rule has been earning its place all along.

A rule that has not fired in weeks is worth a look, not a reflex. Some rules are quiet because the app is quiet: a service you use twice a year does not produce hits in a 30-day window. Others are quiet because they can never fire at all, and those are the ones Rules › Clean up names for you, with a reason.

Privacy tools are unusually easy to believe. They show a list, and the list feels like protection. NetMute would rather show you the measurement, including when the measurement is boring.

The honest limit sits right next to it: IP and CIDR rules carry no count. At that layer the system's report contains no attribution back to a specific rule, so there is nothing to count. Printing a zero there would be a made-up number, and a made-up number in a privacy tool is worse than a blank.