UI fails to report correct history status of events

[SamuelLanders]

What happened?

Portmaster does not appear to have logged tracking of the status of whether it blocked (or not) a connection. This means that all connection events are filtered against the current rules and status of whether something was blocked or not, and are dynamically calculated continuously. This also means that if you change a setting then all historical data on event blocking is updated to reflect against the new rule setting. As this is not an accurate reflection of what really happened I would consider it either a bug or a security failure.

One would need to be using wireshark on a secondary system to be able to confirm if this software is doing its job correctly or if anything malicious is changing rules dynamically hidden in the background, as the history status cannot be trusted.

What did you expect to happen?

I would expect the logging to record actual status of an event and reflect this in the graphs depicting such. Changing a rule should not be able to affect the results of previous events shown in the logs.

How did you reproduce it?

Change a rule from allow to block internet access on any application that has previously sent traffic to the internet. All traffic shown as historical is then shown as being blocked, even though it was not blocked.

Additional information

Feature implementation that could be used with the fix of this issue: There should be both a display of historically accurate blocking status AND a flag identifying if that same traffic would be blocked or allowed against the current rule set.

I would recommend a blue and purple status flag at the end of the logged historical status display that on mouse highlight performs a popup notification that the traffic shown will in the future be blocked or not as based against the current rule sets. Blue would be for it is allowed traffic against the current rule set. Purple would be for it is NOT allowed against the current rule set.

This means that the traffic would be displayed in the current red or green status based upon its historical data, but have an identifier at the end of the line of data to help users know if a setting currently affecting such traffic would change the future use of such traffic and this would be dynamically calculated continuously.

Debug-Info: https://support.safing.io/privatebin/?4f7aa2f126a3040c#765m4s8J3YvdJEGizuxZPiimtArEkDMgWg4fn1piHbSe

[dhaavi]

Hey @SamuelLanders, thanks for the excellent report!

Decisions about connections (Verdicts) are indeed saved and not dynamically generated.

Not too long ago it was impossible to change the verdict of a connection. We needed to change this, as when the SPN is enabled, we need to block any current connections to force them over the SPN, as the current SPN OS Integration is on layer 5, similar to a proxy.

What happened previously is that if a user changed a rule, nothing about the connections changed and a good share of users was confused and thought that the rule was not being applied or was not effective for some reason.

The data model of the connection actually saves all the necessary information, the only missing thing is to update the UI - which is where our current resource bottleneck is.

Here is what the saved verdicts look like:

	// Verdict holds the decisions that are made for a connection
	// The verdict may change so any access to it must be guarded by the
	// connection lock.
	Verdict struct {
		// Worst verdict holds the worst verdict that was assigned to this
		// connection from a privacy/security perspective.
		Worst Verdict
		// Active verdict holds the verdict that Portmaster will respond with.
		// This is different from the Firewall verdict in order to guarantee proper
		// transition between verdicts that need the connection to be re-established.
		Active Verdict
		// Firewall holds the last (most recent) decision by the firewall.
		Firewall Verdict
	}

from

portmaster/network/connection.go

Lines 111 to 124 in dc5dd35

	// Verdict holds the decisions that are made for a connection
	// The verdict may change so any access to it must be guarded by the
	// connection lock.
	Verdict struct {
	// Worst verdict holds the worst verdict that was assigned to this
	// connection from a privacy/security perspective.
	Worst Verdict
	// Active verdict holds the verdict that Portmaster will respond with.
	// This is different from the Firewall verdict in order to guarantee proper
	// transition between verdicts that need the connection to be re-established.
	Active Verdict
	// Firewall holds the last (most recent) decision by the firewall.
	Firewall Verdict
	}

I like your recommendation. I thought of just placing both old and new verdict next to each other with an arrow in between, so it is immediately clear that the connection is transitioning.
I think we will need to try a couple things and see what works best when actually looking at it.

Thanks again for your well written and elaborate issue.

[Raphty]

We are restructuring our co debase into a mono-repo where all Portmaster components will live happily together.
This issue has been moved due to this restructure.

[github-actions]

Greetings and welcome to our community! As this is the first issue you opened here, we wanted to share some useful infos with you:

• 🗣️ Our community on Discord is super helpful and active. We also have an AI-enabled support bot that knows Portmaster well and can give you immediate help.
• 📖 The Wiki answers all common questions and has many important details. If you can't find an answer there, let us know, so we can add anything that's missing.