Privacy Policy

1. Two parts, and which one you are using

The agent runs on a server you administer. On its own it reads local counters and prints them to your terminal or emails them to an address you configure. It sends nothing to the author of this software, contains no usage analytics, and needs no account.

The dashboard is optional. Only once you run sudo hyn link and approve it does a server start sending telemetry to it.

The dashboard is not run by the software's author as a public service. Whoever deploys it operates it and is the controller of the data in it. For this deployment that is [YOUR LEGAL NAME / COMPANY], [POSTAL ADDRESS], contactable at [CONTACT EMAIL].

2. What the agent reads on the machine

All of it comes from the operating system and stays on the machine unless you link it to a dashboard.

System and resource usage

Hostname, operating system, kernel, uptime, processor model and core count, per-core clock speeds and governor, every temperature sensor the hardware exposes, processor utilisation, load, pressure stall information, memory and swap, per-filesystem capacity, and disk throughput.

Network

Per-interface throughput, errors and drops; link speed, duplex, MTU and MAC address; TCP connection states, retransmits and connection-tracking usage; the local IP address; latency and packet loss to the configured probe targets; the machine's public IP address; and on wireless links the network name and gateway.

Processes and accounts

The process list, and for the heaviest processes their name, resource use and the account name of the user running them. It also reads who is currently logged in — account name, terminal, the source network address of the remote session and login time — and counts rejected SSH authentication attempts.

3. What reaches the dashboard

Every push — by default one every five minutes — sends the measurements above, including the account names of the owners of top processes, plus the machine's name, hostname, operating system, agent version, the alert rules currently firing, and the last throughput test. After trying to send a notification it also reports the channel, destination, subject, result and any error.

Not sent: file contents, directory listings, command arguments, environment variables, keystrokes, log or journal line text, database or application data, or the source addresses of logged-in sessions.

Note the asymmetry: session account names and source addresses doappear in the body of alert and report messages delivered to your own channels — your inbox, your push topic — because that is where they are useful. They are not stored in the dashboard's database.

4. What the dashboard stores about you

• Your email address, and your name if you give one.
• A session cookie so you stay signed in. Strictly necessary. No advertising, profiling or third-party tracking cookies are set.
• For each machine: name, hostname, operating system, agent version, when it paired, when it last reported, its status and its settings.
• Notification channels: type, destination, and — only if you choose to store it centrally — the provider API key or password. See section 5.
• Every notification attempt, with its result and failure reason.
• The telemetry in section 3.
• If an administrator pauses, suspends or revokes your machine or account, that action with its reason, time and the administrator's identity.

Pairing codes are stored only as a hash and are deleted after they expire.

Who can see it

You, for your own machines — enforced in the database itself, not just in the interface. Administrators of this deployment can see every client's machines, telemetry and notification history, and can pause, suspend or revoke any of them. If you did not deploy this yourself, assume its operator can see your telemetry. Beyond that: the processors in section 7, and nobody else. Your data is not sold, shared for advertising, or used to train models.

5. Where credentials live — your choice

Notification provider credentials can be stored in the dashboard, which is convenient because every server picks up a change, at the cost of the credential being in the database. It is protected by being write-only from any browser session — the dashboard can replace a key but can never display one — and is released only to a server presenting its own token.

Or store it on the machine in /etc/hyn-view/secrets, mode 0600, root only. A credential there overrides the dashboard, so central storage is entirely optional.

Machine tokens and pairing codes are stored only as SHA-256 hashes. Tokens never appear in command-line arguments, so other local users cannot read them from the process list. No agent is ever given a key that would bypass database access controls.

6. Reducing what is collected

7. Processors and third-party services

Running the dashboard involves Supabase (database and authentication) and [HOSTING PROVIDER]. State the region your project runs in: [REGION], and, if data leaves your users' jurisdiction, the transfer mechanism you rely on.

Only if you enable them: Google (sign-in), your email provider (Resend, Brevo or SMTP), ntfy or Telegram, a Slack or Discord webhook, and an external dead-man's-switch service.

Contacted by the agent

Each is an ordinary network request, so the operator of that endpoint sees your machine's IP address. None of them receive your telemetry. We do not control third-party services and are not responsible for them.

8. How long it is kept

9. Legal bases, if UK/EU GDPR applies

[DECIDE which apply and delete the rest] Contract — to provide the dashboard you asked for. Legitimate interests — keeping the service secure, preventing abuse, and the administrative oversight in section 4. Consent — where you choose to store a provider credential centrally or to sign in with Google, withdrawable at any time.

Where telemetry identifies your colleagues rather than you — an account name in a process list — you are the controller for that data and are responsible for informing them.

10. Your rights, and doing it yourself

You may request access, correction, deletion, a portable copy, restriction, or object to processing. Write to [CONTACT EMAIL]; we aim to reply within 30 days. Most of it you can do immediately:

• Stop collection now — sudo hyn unlink on the machine.
• Cut a machine off permanently — revoke it in the dashboard.
• Delete a machine and all its telemetry — delete the node; its metrics, speed tests and alerts go with it.
• Delete demo data — one click wherever it appears.
• Delete your account — [DESCRIBE THE PROCESS].

In the EEA or UK you may complain to your supervisory authority; in the UK that is the ICO.

11. Security

Access is restricted per account in the database, not only in the interface. Credentials are hashed or held in a column no browser session can read. Secrets on the machine are 0600 and root-only. Message bodies pass through restricted temporary files rather than command-line arguments. Text from system journals is escaped before being placed in JSON, because it is attacker-influenced input. No system is perfectly secure and no guarantee is given. Report vulnerabilities to [SECURITY CONTACT] rather than publicly.

12. Children, automated decisions, and changes

This is server tooling, not directed at children, and not knowingly offered to anyone under [16 / 13]. Alert rules compare readings against thresholds you set; there is no profiling or automated decision-making with legal effects. Material changes to this policy will be announced by [HOW] before taking effect.