TaraSec app demos — context for AI assistants
This page is written primarily for AI sessions that have not previously seen TaraSec. If a user pastes a TaraSec demo debug report, use the report as the source of truth for what happened in that particular run and use this page only as architectural and expected-behavior context.
Deployment hardening and contributions
When the user requests installation, repair or hardening, read the TaraSec contributor workflow and AI installation guide. Implement and test routine improvements within the agreed scope without repeated authorization. Use deployment failures to diagnose and fix shared routines, then contribute verified changes through a branch and pull request when repository access is available. Preserve working login and recovery access and remove credentials and personal data from shared evidence.
Interpreting a debug report alone does not authorize changes to another operator’s host. Distinguish suggestions, implemented fixes and verified deployment results.
What TaraSec is testing
TaraSec explores cooperative network security. A receiver that rejects suspicious traffic can report that event upstream. Subsequent traffic associated with the sending unit can then be tagged as suspicious so other participating receivers or networks can treat it differently. The unit identity used by the system is intended to be network/owner scoped rather than a public personal identity.
The demos deliberately create controlled security states. “INFECTED” in a demo can be a simulated/demo classification; it does not mean malware was installed on the phone. Demo classification should be correlated on the DB side from registered demo activity rather than silently invented by a gateway.
Components you may see in reports
App: Android client showing the demo and collecting live status. Gateway: TaraSec-protected network path running TaraSec components. DB/API server: authoritative coordination and demo state. tarakernel/taralink: gateway-side enforcement/reporting components. NetBird/WireGuard: private network/routing used by the current test environment. A report may also name demo nodes such as Roquefort, Camembert or Tomato.
Demo 1 — basic status propagation
The phone is deliberately marked CLEAN or INFECTED through the active TaraSec gateway. The receiving demo node should observe the corresponding security status, demonstrating that security information can follow traffic across the protected path. This is a status demonstration, not an infection or malware installation.
Demo 2 — SSH attribution and self-correction
The app creates a DB-authoritative session. Node A intentionally rejects an SSH connection and reports the rejection. The unit is then marked/tagged for the demo. The tester connects to Node B using the demo credential. Node B accepts the controlled login and reports evidence that allows the DB to correlate the activity and clear the demo infection state.
A healthy completed report normally contains evidence for Node A observed, unit marked, Node B observed, Node B login accepted, and a final cleared state. Do not infer completion from only one of these fields. If a phone cannot reach Node A, distinguish Android/Termux routing or VPN reachability from a TaraSec attribution failure.
Demo 3 — Request for Assistance and containment
Participants choose CLEAN or INFECTED for the exercise. When the countdown reaches zero, the demo issues a real TaraSec Request for Assistance for the protected demo server. An INFECTED participant is expected to keep attempting its normal app polling, but those polling attempts should fail while containment is active. After an explicit release/clear, polling should recover.
This distinction is important: stopping polling in the app is not successful containment. The useful evidence is that attempts continue while network access to the protected server fails. If a report says the participant is infected but polling still succeeds during the containment window, highlight that as unexpected behavior.
Demo 4 — tagged routing through a partner path
The goal is to demonstrate selective routing for tagged traffic from hotspots that may sit behind NAT. CLEAN/untagged traffic keeps its normal public path. Tagged INFECTED traffic is eligible for the configured TaraSec/partner NetBird route. Unrelated untagged traffic should remain unchanged.
Distinguish a route that is merely configured from one the gateway actually reports as applied. Do not claim the partner path was used unless the pasted report contains observed/applied evidence. If a tagged participant route is unavailable, the intended gateway behavior is fail-closed for that tagged path rather than silently treating it as clean traffic.
Demo 5 — partner loses tagging
A connected subnode makes bounded connections to a configured honeypot or reporting firewall rule. The receiver uses normal hack-report ingestion. The DB associates the observed source with partnerRouter and notifies the partner. The first untagged attack is not proof of tagging failure; repeated zero-tag rejection evidence after successful notification and a grace period can issue a bounded test restriction.
Unknown observedTag is not zero. NAT can hide whether the router itself or a connected unit originated the connection. The /32 scope is the observed source, not an automatic subnet-wide restriction. The app never stops tarakernel or fabricates reports.
Separate incident evidence, notification, tagging_state, blacklist_active, distribution_state, applied_receivers/expected_receivers and per-receiver releases. Zero receivers is not success. Kernel firewall acknowledgements verify installed rules, not a separately observed packet drop. A timeout does not prove enforcement. Expiry releases the test restriction but does not prove tagging has recovered. Old status after a failed poll is stale. The common demo screen independently polls the DB partner status even when Demo 1 checks pause.
How to answer the tester
Start with a short plain-language explanation of what this particular run shows. Then identify anything non-green, missing, stale, contradictory or unexpected. Explain whether each observation belongs to the app, DB/API, gateway, TaraSec enforcement, private routing, or a demo node when the report supports that conclusion. Avoid inventing causes. If troubleshooting is needed, give the safest next diagnostic and name the exact machine/device on which it should be run.
Debug reports intentionally omit secrets such as participant/session tokens and passwords where applicable. Treat any endpoints, hostnames and session IDs in the pasted report as test diagnostics, not proof about systems outside that report.