Packetman saysWelcome to the end-user experience page. I'm Packetman. The IT lead reading this page has the same question every IT lead has when introducing a new agent into the fleet: "won't users complain?" The honest answer is that DataStun was designed by an engineer who has run security tools on enough machines to know which patterns make users hate them, and the design decisions show. The agent runs silently — no popups, no scans, no scary notifications. Resource footprint is small enough that users do not notice. The tray icon (Windows today, macOS and Linux next) opens a per-device dashboard the user can actually read — they see what we collect about their machine, the destinations their software is reaching, the executables that have run. They have a Help button that opens an AI-fronted support flow with on-device secret scrubbing — passwords, API keys, credit cards stripped before anything leaves the machine. Browsers do not break, video calls do not glitch, no apps refuse to run because of false-positive DLP rules — because we are not a DLP and there is no MITM proxy. The page below covers what users see, what they do not, the tray and /my-device surfaces, the resource footprint, the blocked-flow story (not silent failure), the Help flow, and the apps-do-not-break promise. Every claim here is something an IT lead can verify with one test enrollment on their own machine.You’ll never know it’s there until you need it.
The IT lead’s pushback question: “won’t users complain?” DataStun was built by an engineer who has run enough security tools on enough machines to know which patterns make users hate them. The design choices that follow show the answer.
Simple enough for grandma, admired by the CTO.
/my-device dashboard when they open it themselves: where their device’s data went, drawn on a map; which program opened each session; their own performance grade and retransmission trend; any block or security alert that involved their machine, with the reason; their own hardware and posture. Only their device — never anyone else’s.Packetman saysPacketman here. Click most endpoint security tools and you get a green dot or a red dot: alive and reporting to the central team, or not. That's all the user gets. We think the people using these machines are smart professionals who deserve to see their own device. So the tray, or the Dock on a Mac, opens a page showing where that device's data went, on a map, how it's performing, and whether anything on it was blocked, and why. Their own device only, never anyone else's. Anything that's a security risk still goes central.Most endpoint security tools give the person at the keyboard exactly one thing when they click the icon: a green dot or a red dot. Alive and reporting to the central team, or not. We think that sells the user short. The people using these machines are smart professionals, and they deserve a view of their own device — so they can be part of the solution instead of a body the agent watches over.
Where their device’s data went, drawn on a map by country and organization. Which program opened each session. Their own performance grade, with the retransmission trend that explains a slow afternoon. Any block or security alert that involved their machine, with the reason and a way to ask their admin about it. Their own hardware and security posture.
Anything about any other device. The per-device page is scoped to that machine by a token minted at enrollment; there is no path from it to another user’s data, the fleet view, or the admin console. The content of their own traffic is not there either, because we never collect it.
Anything deemed a security risk: a blocked destination, an exposed service, a suspicious executable, a port reachable from the internet. Those reach the tenant admins and, where you have them, the site or business-unit admins — the same finding the user sees on their own page, plus the fleet context they do not.
This is the last rung of the distributed idea: the work happens on the device, the findings roll up, and the view is distributed all the way down to the person whose device it is. How it works →
Windows system tray today, macOS Dock tile today; Linux desktops next. The same items, the same predictable behaviour, no admin required to use them.
No setting-changes from the tray. No hidden right-click menu with elevated commands. The tray is for visibility and help; configuration lives in the admin dashboard where it belongs.
/my-device dashboardClick Open my device dashboard in the tray and the user’s browser opens to a per-device page that’s scoped to their machine. No login required — the tray opens it with a one-time dashboard token. Same surface that the admin sees at /agents/<id>, but limited to the user’s own device.
Engineered to live next to a real EDR (CrowdStrike, SentinelOne, Defender for Endpoint) without competing for resources. Numbers below are real measurements on a typical mid-range corporate laptop.
| Resource | Measurement | Notes |
|---|---|---|
| CPU (steady state) | < 0.5% | Background flow polling, every few seconds; spikes briefly during blocklist refresh. |
| RAM (resident) | ~ 35 MB | Single Go process; no JVM, no Electron. |
| Disk I/O | ~ 0 KB/s | No full-session pcap. Local state in %ProgramData%\DataTravel is < 5 MB. |
| Network (telemetry up) | ~ 5 KB/s | Compressed flow batches every minute; less when the device is idle. |
| Network (blocklist down) | ~ 60 KB/min | Delta-only updates; full refresh once per restart. |
| Boot impact | < 200 ms | Service starts after the network stack; no delay to login. |
Architectural rule: the agent never causes the problem it’s measuring. The split is deliberate: each endpoint does the first-hand work for its own traffic — observing, attributing, measuring, enforcing — which is why it fits in under one percent of a CPU, while anything that only needs doing once for everyone is done centrally. The heavy lifting — packet decode, AI inference, DPI, and long-term storage — lives on server-side infrastructure, not the endpoint. The one exception, Advanced Packet Diagnostics, is opt-in per test: the agent records a brief, filtered capture using tooling already on the device, then uploads it and deletes the local copy — no capture software installed, no full-session pcap, nothing left behind.
A blocked outbound flow is not a silent failure. The user sees a clear, friendly notification with the information they need to either keep working or escalate.
Block enforced at OS firewall. The flow refuses on the kernel side. The application’s connect() returns “refused” instead of timing out — users get a fast clear failure, not a thirty-second hang.
Notification fires. The user sees a tray notification: “Connection to example-bad.com from chrome.exe was blocked — this destination is on the global threat list.” Notification includes a link to the user’s /my-device Blocked tab for context.
One-click escalation if it’s wrong. If the user thinks the block is incorrect, the Blocked tab has a “Tell my admin this is wrong” button that opens a pre-filled support thread with the destination, the program, the timestamp, and the user’s description. Admin sees it in their inbox; the user sees the resolution thread.
Admin resolves. Admin can override the block tenant-wide (one click) and the change propagates to every agent in the tenant within 60 seconds. The user gets a follow-up notification when the destination is unblocked.
Click Help & support in the tray. The browser opens to /account/support, authenticated to the user’s specific device. AI assistant answers first; admin escalation is one click; central DataStun support is two.
Before any support message leaves the user’s machine, an on-device scrubber strips patterns that look like credit cards, API keys, private-key PEM blocks, password-field values, Basic / Bearer auth headers, and database connection-string passwords. The user sees the scrub markers in their own message — so they know what didn’t leave their device, before they send it.
Scrubbing happens before transit, not on the server. The redactions are visible to the user so they can verify what stayed local. Read the support-flow glossary →
No MITM proxy, no SSL stripping, no DLP-style content inspection — so the long list of apps that other security tools quietly break just keep working.
Chrome, Edge, Safari, Firefox: no certificate warnings. We don’t intercept TLS.
Zoom, Teams, Google Meet, WebEx: no stutters or quality drops. We don’t buffer media flows.
WireGuard, OpenVPN, Tailscale, corporate VPNs: tunnel traffic passes through normally.
Git, npm / pip / cargo / brew, Docker, Kubernetes CLIs: no cert pinning errors, no proxy config to manage.
SSH, RDP, VNC, Tailscale SSH: no inspection of session content.
Streaming, gaming, social, banking: no content inspection of TLS-protected traffic.
If a flow gets blocked because the destination is on the global threat-IP list, the application sees a fast connection refused — it doesn’t hang and it doesn’t silently corrupt. The user gets a tray notification explaining what happened and a path to escalate if it’s wrong.
The fastest way to answer “will users complain?” is to enroll your own machine. Individual tier covers 3 agents; the experience above is fully exercised on a single device.