# Private-room relay: privacy and security boundary

The Android and Apple clients use the public endpoint
`wss://sportaktivfitness.de/tiberian-dawn-relay` for private Internet rooms.
Publishing that hostname is required for interoperability and does not reveal
a credential. It can also be recovered from any distributed client.

## What is not in the repository

- TLS private keys or certificates
- SSH/server login details
- API keys, passwords, database credentials, or deployment tokens
- production logs
- original game data or save files

The checked-in Apache and systemd examples disclose ordinary service paths,
the localhost port, and security limits. Those are not authentication factors;
the deployment must remain safe even when its implementation is public.

## Connection and room behavior

- Each client validates the normal platform TLS certificate and hostname.
- A room code is eight random `A-Z0-9` characters (about 41 bits of space).
- A socket receives one join attempt; invalid, expired, incompatible, or full
  joins are rejected and closed.
- Rooms exist only in memory, accept at most six peers, and expire after six
  hours of inactivity.
- Control messages and binary frames have strict size limits. Connection,
  queue, and token-bucket limits bound ordinary abuse.
- No account, advertising identifier, analytics SDK, or player profile is used.

## Data visible to the relay

WSS encrypts traffic between each device and the server and prevents passive
network observers from reading it. It is not player-to-player end-to-end
encryption: the relay terminates TLS and can observe source IP addresses,
connection times, room membership, packet timing/sizes, and the forwarded
binary game packets. The relay does not need original ISO files, extracted game
assets, saves, player names, or account information.

## Remaining operator risk

A public endpoint can receive unwanted connections or denial-of-service
traffic whether or not its source is published. Application limits reduce
protocol-level abuse but cannot stop a sufficiently large volumetric attack or
eliminate hosting/bandwidth cost. The operator should keep OS/proxy packages
updated, run the service unprivileged, bind it to localhost behind TLS, monitor
resource use and errors, and apply provider/firewall rate limiting when needed.

Security reports should use GitHub's private vulnerability reporting rather
than a public issue.