Excluding an app from TrackerControl should pass traffic through, not leave the VPN

[kasnder]

"Exclude from TrackerControl" currently means "leave the VPN" (apply = false →
addDisallowedApplication, ServiceSinkhole.java:1778). That is a kernel-level
bypass, and it is not what the toggle is supposed to mean.

Consequences:

• It is incompatible with always-on VPN + "block connections without VPN":
  under lockdown an excluded app gets no network, not the raw network.
• Toggling it requires rebuilding the tun, so it cannot change at runtime.
• It collapses two independent choices — is this app filtered and is this app
  in the tunnel — in exactly the way Route apps around the remote VPN without leaving TrackerControl #730 has just separated is this app
  filtered from is this app routed through the remote VPN.

What we actually want from "exclude" is a passthrough: the app stays in the
tun, its packets are relayed unchanged, and no block decision or recording is
made for it.

Scope of the change

Once a packet is in the tun there is no bypass — it can only leave through a
protected socket, i.e. handle_tcp / handle_udp. So passthrough cannot skip
the relay. It skips the per-session work: the create_packet +
is_address_allowed JNI upcall, the DB write, the SNI reassembly, the logging.
The per-packet copy stays, so throughput and battery land roughly where filtered
apps already are. The win is semantic (lockdown-compatible, runtime-toggleable),
not performance.

The mechanism largely exists already: tracker_protect = false is passthrough
with monitoring — in the tun, seen, not blocked. The missing state is "in the
tun, relayed, not recorded". That is one more verdict at the same fork in
handle_ip() (ip.c:344) that #730 turned into route_decide(), and can follow
the same shape: a sorted UID array pushed over JNI, an I/O-free filter_decide(),
mirrored by a JVM-testable Java class.

Open questions (design, not plumbing)

• System apps. !includeSystem && rule.system uses the same
  addDisallowedApplication path. Converting that set to userspace passthrough
  would drag all system traffic through the relay — a real regression. Argues for
  keeping the kernel exclusion available as a separate, clearly-labelled escape
  hatch rather than replacing it.
• DNS. Port 53 skips the UID lookup entirely today, so a passthrough app's
  queries would still be parsed and attributed unless we pay the fwd53-style
  cost described in Route apps around the remote VPN without leaving TrackerControl #730. Since attribution is global anyway, "still monitored"
  is probably right — but then "excluded" no longer means invisible, and
  shouldTrackApp (ServiceSinkhole.java:2431) has to change to match.
• UID on packet 2+. Same uid == -1 trap as Route apps around the remote VPN without leaving TrackerControl #730. Easier here: stamp the
  verdict on the session at creation, since existing sessions already
  short-circuit to allowed = 1.
• Configurability. This is a third orthogonal axis on top of Route apps around the remote VPN without leaving TrackerControl #730's two.
  Given the simplicity-over-configurability rule, it should fold into the
  existing per-app control as a tri-state rather than becoming a new switch.

Proposal

Make passthrough the default meaning of the per-app exclusion toggle, and keep
addDisallowedApplication as a separate escape hatch for apps that genuinely
break inside a userspace stack (VoIP, captive portals).

Follows on from #730.

[kasnder]

Two notes from tracing this against current master, both narrowing the proposal rather than disputing it.

Don't repurpose the existing toggle in place — add passthrough alongside it. "Exclude from TrackerControl" is used for two different goals today: recovering an app that breaks inside the userspace stack, and keeping a heavy app off the relay entirely. The issue's own scope section concedes the per-packet copy stays, so switching existing exclusions to passthrough silently re-imposes that copy on the second group — which lands on constraint 3 (battery is a first-class constraint), and does so for users who never asked for the semantic change. Suggested shape: passthrough becomes the meaning of the toggle for new exclusions, existing exclusions migrate to the kernel-bypass tri-state value, and addDisallowedApplication stays as the labelled escape hatch. That also disposes of the system-app question — !includeSystem && rule.system keeps the kernel path, and no system traffic is dragged through the relay.

The three open questions look answerable without further design work. DNS: since attribution is global anyway, leaving a passthrough app's queries parsed and attributed is the right trade — pay nothing, and change shouldTrackApp (ServiceSinkhole.java:2431) so "excluded" no longer implies "invisible" in the UI. UID on packet 2+: stamping the verdict on the session at creation works here precisely because existing sessions already short-circuit to allowed = 1, so there is no second decision to keep consistent. Configurability: tri-state on the existing per-app row, not a fourth switch.

One thing worth stating explicitly in the eventual implementation: passthrough is not a bypass of the block decision only — it also skips the DB write and the SNI reassembly, so an app in that state disappears from the tracker log. That is the intended meaning of "not recorded", but it is a visible behaviour change for anyone who currently reads the log for an excluded app, and reads differently from tracker_protect = false (seen, not blocked). Worth a line in the tri-state's own labels.

The route_decide() shape from #730/#737 does transfer directly — sorted UID array over JNI, I/O-free decision, JVM-testable mirror — so the plumbing half is the easy half.

---

Generated by Claude Code

[kasnder]

Closing this as superseded rather than declined — tracing it against current master, the state this issue calls missing has since landed, and what is left is not user-visible.

"In the tun, relayed, not recorded" already exists as TRACKERS_ALLOWED. The issue reads tracker_protect = false as "passthrough with monitoring — in the tun, seen, not blocked", which was true when it was written. It is not true now. shouldTrackApp() (ServiceSinkhole.java:2565) returns false when tracker_protect is off, and it gates both blockKnownTracker() and the dh.updateAccess() app-log write (ServiceSinkhole.java:1031). So that state is already not blocked and not recorded. 73d9dac surfaced it as one of the four options in the per-app protection state, which is where a user reaches it.

The residual delta is invisible. A native filter_decide() verdict would skip the is_address_allowed upcall, the DB write and the SNI reassembly for that UID. Against TRACKERS_ALLOWED the only behaviour a user could observe is the traffic log (dh.insertLog), which is off by default — and the issue's own scope section concedes the per-packet copy stays either way. That is a fast-path optimisation inside an existing state, not a new state, and only worth doing if profiling shows the upcall actually costs something.

A fifth option would undo 73d9dac. That commit consolidated three booleans with eight combinations down to four meaningful states. Adding a fifth radio option whose only difference from TRACKERS_ALLOWED is a default-off log is the configurability proliferation constraint 1 exists to prevent — and it would land on users as two states they cannot tell apart.

The lockdown motivation is already covered. Onboarding has a dedicated lockdown slide with a confirm-warning (ActivityOnboarding.java:181-198), the troubleshooting page states that lockdown means TC "cannot work correctly" (strings.xml:82), and on Android < S ActivityMain.java:302-310 refuses to enable at all, un-checking the switch with msg_always_on_lockdown. The app's position is already "do not run TC under lockdown", not "lockdown works but excluded apps quietly lose network" — so this is a property of a configuration we tell people to avoid, not a live defect.

Two genuine gaps did turn up while checking that last point — the enable-time check is SDK_INT < S only, so it no-ops on current devices, and title_lockdown_enabled is defined but never used despite the troubleshooting text promising that notification. Both are unrelated to passthrough and are now #743.

The route_decide() shape from #730/#737 is unaffected and stays as shipped.

---

Generated by Claude Code