Repository navigation
privacy
Last updated: 2026-09-25
LightSpeed is privacy-first by design. The tunnel is unencrypted to remain compatible with anti-cheat systems: game servers always see your real IP address. Telemetry is on by default and can be turned off at any time; it is limited to anonymized aggregate metrics.
LightSpeed does not collect accounts, identities, game account data, or packet payloads. It does process IP addresses transiently for routing and country derivation, and relay logs can contain client IPs (see Proxy Logs). The precise split between what is processed, what is aggregated, and what is never collected is documented in the Data Dictionary.
- ❌ Stored IP addresses (yours or game servers'). IPs are processed transiently for routing and country derivation, then discarded. Relay logs can contain client IPs; see Proxy Logs. See also What LightSpeed Sees (and Doesn't Store).
- ❌ User identities or account information
- ❌ Game account data or player names
- ❌ Packet payloads (game data is encrypted by the game's own protocol)
- ❌ Browsing history or other non-game traffic
During operation, the client and proxy process UDP packet headers:
- Source/destination IP addresses (for routing, and for transient country derivation)
- Source/destination ports (for game detection)
- Packet sizes (for bandwidth accounting)
- Session tokens (for authentication)
This information is held in memory only and is never written to disk beyond debug logs (which you control via the RUST_LOG environment variable). Debug logging is off by default. Relay access logs are the exception: they can contain client IPs, as described in Proxy Logs.
To decide where relays are most useful, the proxy derives the country of an IP address from a locally stored DB-IP Lite database. This happens in memory, transiently, at session creation, for both the client source address and the game-server destination address. The country lookup is the only thing derived from the address; the address itself is not retained.
What is kept is a counter of sessions per (source_country, destination_country) pair. These counters are never per-user and never include raw IP addresses. A cell is suppressed until it has at least 3 sessions before it is exported: any (source_country, destination_country) cell with fewer than 3 sessions is suppressed and never leaves the proxy.
The counters are exposed on the relay's /metrics endpoint as country-code labels, and persisted into the public stats history as coarsened region-pair counts only (for example mena-eu). The counters contain no raw IP, and no raw IP is exported by the placement pipeline (operational logs are covered in Proxy Logs below). There is no change to what the client sends.
IP geolocation data by DB-IP (https://db-ip.com), licensed under CC BY 4.0.
Telemetry is on by default. It sends anonymous aggregate metrics to the
/telemetry endpoint of the relay you are connected to (a community or sponsor
relay, or your own if you self-host). There is no central LightSpeed telemetry
server. A client telemetry cell is suppressed until it has been seen from at
least 3 distinct source IP addresses (MIN_TELEMETRY_CELL_SOURCE_IPS = 3,
enforced in proxy/src/metrics.rs:1358). This floor counts distinct sources,
not reports: a single client flushing every 15 minutes cannot reach it alone,
because repeated reports from one address do not add a distinct source. The
relay keeps a bounded set of at most 3 source addresses per cell, uses it only
to make this export decision, and never exports or logs the addresses
themselves. It limits how small a cell can be before it is exported; it does not
prove that a cell is backed by a population of 3, only that at least 3 distinct
source addresses contributed.
The per-route-leg aggregator floors the same way, on distinct source IPs
(MIN_TELEMETRY_CELL_SOURCE_IPS = 3, enforced in proxy/src/metrics.rs:1516).
One aggregator has no source address to key on: the session-geo aggregator
withholds a cell until it holds at least 3 observations
(MIN_TELEMETRY_CELL_REPORTS = 3, enforced in proxy/src/metrics.rs:1621). For
that one, the floor counts observations, not distinct people. The client
telemetry and per-route-leg cells are the ones that carry the distinct-source
guarantee.
- Reports are POSTed over plaintext HTTP to
<relay>:8080/telemetry. The body is not encrypted in transit. This is a known limitation and the plan is to move telemetry onto the QUIC control plane. - The
/telemetryendpoint is unauthenticated: the relay accepts a report from any source that can reach port 8080. It validates the JSON body shape, but it does not verify who sent it.
Anonymous reporting is opt-in, and it is separate from the measurement the client does to optimize your connection. While a tunnel or interceptor is active, the client measures the paths it is choosing between, whether or not reporting is on:
- ICMP-probes the game server to measure the direct (un-relayed) path.
- Re-injects a small sample of the game's own packets on the direct path (the "shadow direct" sampler). The packet is the game's own packet, sent unchanged, so the client can compare like-for-like direct and relayed RTT. No synthetic packet is generated. It is rate-limited to at most one packet per game server per 30 seconds and runs only while the interceptor is active.
These probes go to the game server, never to the relay. The numbers stay on
your machine unless anonymous reporting is enabled. With --no-telemetry, no
report is built or sent, and the relay receives nothing.
Turning telemetry on is what sends the aggregate report described below.
The client measures both the direct RTT to the game server and the tunnelled round trip, and the relay aggregates the difference. That difference is the "RTT saved by LightSpeed" figure shown on the website. It compares two different instruments (a direct probe against the game traffic's own round trip), so it is an estimate, not a measurement of in-game ping. It is a per-cell aggregate, never a per-client value.
| Metric | Example | PII? |
|---|---|---|
| RTT percentiles | p50: 31ms, p95: 45ms, p99: 52ms | No |
| Jitter | 2.3ms (mean of absolute consecutive RTT deltas) | No |
| FEC recovery rate | 12 packets recovered / 1000 | No |
| Direct vs relayed RTT | direct p50: 61ms, relayed p50: 31ms | No |
| RTT saved | 30ms (direct p50 minus relayed p50) | No |
| Paired app samples |
saved_app_pairs: 4 (count of paired direct-app/relayed observations behind the report) |
No |
| Game name | "rust" | No |
| LightSpeed version | "1.6.5" | No |
saved_app_pairs is a plain count of local paired observations, like
sample_count: it says how many paired direct-application and relayed samples
sit behind the reported medians. It is aggregate and non-identifying, and it
weights the relay's saved-app sample counter so a report covering several pairs
counts as several samples rather than one. Legacy reports that predate the field
default to one pair, so an upgraded client's contribution is unchanged.
saved_app_pairs does not change the k-anonymity floor. The floor is
enforced in the relay (proxy/src/metrics.rs) on distinct source IPs, and a
pair count is a number inside one report from one source, so it cannot
manufacture a distinct source. The field only affects the scale of the
recommender's advisory min_measured_samples quality gate, which is calibrated
to 20 pair-weighted samples for that reason. It is not collected as an identity
and it is not a wire field the relay stores beyond the aggregate counter.
client_version is collected but is not aggregated or used by the relay; it is
being coarsened. The full field list, types, and aggregation keys are in the
Data Dictionary.
Explicitly NOT collected: IP addresses, user identities, game account data, packet payloads, game-server IP, session or user IDs, exact coordinates, and raw timestamps.
# Disable for this session (overrides the config and the default)
lightspeed --no-telemetry --start-interceptor --game rust --proxy YOUR_PROXY:4434
# Disable permanently in lightspeed.toml
# [general]
# telemetry = false--telemetry forces telemetry on for one session; --no-telemetry always wins.
The GUI exposes the same switch as the "Share anonymous latency stats"
checkbox.
The relay that serves your session writes access logs to stdout (configurable via RUST_LOG). These are operational logs, not analytics. They can contain:
- Client IP addresses (for rate limiting and abuse detection)
- Session start/end times
- Packets/bytes relayed per session
Client IPs appear in these logs only because the proxy needs them for rate limiting and abuse detection. They are not exported, not used for country derivation, and not joined to the placement counters described above. These logs are stored on the relay that served the session. If you use a community or sponsor relay, that operator holds the logs; if you self-host, they are on your server. LightSpeed does not have access to logs on relays it does not operate. Configure log rotation and retention according to your own policies; retention is limited by the logging configuration of the relay that wrote them.
- Client: No data is persisted beyond the current session (in-memory only).
- Relay: Logs are written to stdout. Retention is controlled by the relay's logging configuration; if you use a community or sponsor relay, that operator controls it. Placement counters are aggregate only, with a floor of 3 sessions per cell, and carry no raw IPs. Client telemetry cells are aggregate only, withheld until seen from 3 distinct source IPs, and the source addresses are never exported or retained beyond that bounded set.
-
Telemetry: Data is sent to the relay's
/telemetryendpoint. The relay operator controls retention.
LightSpeed does not integrate with any third-party analytics, advertising, or tracking services. The only network connections are:
- Your PC → the relay (UDP tunnel + optional QUIC control plane, plus plaintext HTTP telemetry to port 8080 when telemetry is on)
- The relay → game servers (forwarded UDP packets)
- Your PC → the signed relay registry over HTTPS (discovery only, no identifiers sent)
Open a GitHub issue or discussion.