Security

This page describes how FoxTether is built and run today, in plain terms, so you can judge it before you connect anything. It says what is in place and what is not yet.

What the service is

FoxTether moves live data from devices on your network (cameras, sensors, industrial equipment) to the places you point it at, and shows you the health of that fleet. A small gateway program runs on your side. Our cloud receives what it sends and routes it onward. We route data. We do not store it. Device payloads are forwarded to your destinations (webhooks and live viewers) and are not written to disk on our side. What we keep is metadata: your fleet inventory, health and counters, alert state, and the event history you see in the product.

Encryption in transit

Every connection is encrypted. Gateways speak to our hub over QUIC, which mandates TLS 1.3, and the hub authenticates itself to the gateway with its certificate before any data flows. Browsers and SDKs that watch a live stream connect over WebTransport, also QUIC and TLS 1.3. The web application is served over HTTPS.

How gateways authenticate

A gateway holds an enrollment token you generate in the product. On start it exchanges that token with our auth service for a short-lived session token, and presents that token on the first stream of its connection. The hub admits nothing until that check passes. Viewers of a live stream get their own short-lived token, scoped to one stream. Tokens can be revoked from the product, and a revoked gateway is disconnected.

How people authenticate

Sign in with an email address and password, or with Google. Passwords are stored only as salted bcrypt hashes. With Google sign-in we receive your email address and name and never see your Google password. Sessions live on our servers. The cookie in your browser carries only an opaque session id. New sign-ups verify their email address and pass a bot check, and a deployment can be set to invite-only.

Workspaces and roles

Every record belongs to a workspace, and every request is checked against the caller's membership on the server, not just in the interface. Two roles exist: Admins manage the team and the workspace itself, Members do the everyday work. Each workspace's dashboards live in their own isolated organization in our monitoring stack. Our services call the data store with a service token they share, and the data store refuses a call without it.

Admins can read their workspace's security log of sign-ins, membership changes, credential changes and other security events, and export it.

Secrets and stored credentials

Credentials you give us for notifications, such as an SMTP password or a webhook secret, are encrypted at rest with AES-256-GCM. TLS private keys and service credentials are held as Kubernetes secrets, not in code or images.

Abuse resistance

The gateway and viewer entry points rate-limit connection attempts per address, cap unauthenticated handshakes and per-workspace connections, and bound the size of anything a gateway can send. On the hosted service, outbound webhook destinations are checked against private and internal networks on every delivery. A Site Server sits on your own network and delivers there by design.

Where it runs

The cloud service runs on Hetzner Cloud in Germany, on Kubernetes. Cloudflare provides DNS and sends our email. Production images are built by our CI from tagged releases, only after the test suite passes, and a production deploy whose services fail to come up is rolled back by our deploy tooling. The full list of providers that handle your data is on the subprocessors page.

Monitoring, retention, and backups

Platform health rules page an operator by email, with an external dead man's switch that fires if the monitoring itself goes quiet. Metrics are retained for 90 days and logs for 30 days. The database is backed up nightly, and the restore procedure has been drilled.

Self-hosted

The same software runs as a Site Server on your own hardware, for sites that keep data on premises. Releases are signed bundles. Updates can be applied from a file, so an air-gapped site never needs to reach the internet.

What we do not have yet

FoxTether is a small company at an early stage. We hold no SOC 2 or ISO 27001 certification, have not commissioned a third-party penetration test, and do not run a bug bounty. We would rather say so here than imply otherwise. This page is updated as that changes.

Reporting a vulnerability

If you believe you have found a security issue in foxtether.com, the cloud service, the gateway, or the Site Server software, please tell us at security at foxtether.com. Include what you found, how to reproduce it, and what you think the impact is. A machine-readable version of this section is at /.well-known/security.txt.

A person will acknowledge your report within 3 business days, keep you informed while we work on it, and tell you when it is fixed. We credit reporters who want credit. We do not pay bounties.

Research in good faith is welcome. Please do not degrade the service for others, do not access, change, or keep data that is not yours beyond what is needed to show the issue, stop and report as soon as you reach another customer's data, and do not use social engineering against our people. We will not pursue legal action against research that follows these rules.