If you discover a security vulnerability in frostbyte, please report it responsibly.

Email: security@frostbyte.tv

Do not open a public issue for security vulnerabilities.

We will acknowledge receipt within 48 hours and provide a timeline for a fix. Once the vulnerability is resolved, we will credit you in the release notes (unless you prefer to remain anonymous).

The following are in scope:

• The Phoenix sync server (Channels, Endpoint, room state, rate limiting)
• The wire protocol (Frostbyte.Protocol) and its parsing/encoding paths
• The browser extension (when shipped): content scripts, background worker, storage
• Room code generation and entropy
• Caddy / TLS configuration on the production deployment
• Anything that could allow a third party to impersonate a controller in a room they don't belong to

• Vulnerabilities in upstream streaming platforms (Netflix, YouTube, Twitch, Disney+, etc.)
• Vulnerabilities in third-party browser APIs or codecs
• Social engineering against contributors or users
• Denial of service against the public sync server beyond what fail2ban and reasonable rate limits cover

frostbyte v1 has no user accounts and no authentication. Rooms are protected by a 6-character random code. This is sufficient for the v1 use case (sharing a room with friends out of band) but is not a security control against a determined attacker. If you find a way to enumerate active rooms, that's in scope. If you find a way to guess a single random code in fewer than the expected 36^6 attempts, that's definitely in scope.

The sync server does not store video, never proxies video, and never sees the user's streaming-platform credentials. The blast radius of a server compromise is limited to room metadata and disrupting active sync sessions.