Whitelist Bypass: WebRTC tunnelling through video-call platforms

Whitelist Bypass and the whitelist-censorship gap

Whitelist Bypass addresses networks that permit selected video-calling services while restricting general internet access. Its stated model places the creator on a connection with free internet and places the joiner on the censored side. Traffic therefore travels from the joiner through a platform SFU to the creator, which relays it to the destination.

The project targets users who need a system-wide path on Android, a proxy-based arrangement on iOS, or a local SOCKS5 endpoint on Linux. It is not a general-purpose VPN client or a conventional hosted VPN service. The joiner still needs a client component, and the creator still needs a reachable platform account or call arrangement. This makes the system operationally different from services that provide their own public relay infrastructure.

The README names VK Call, Yandex Telemost, and WB Stream as the initial platform examples, while the component layout also includes headless implementations for DION and Bitrix. Platform support is not uniform. WB Stream uses a LiveKit-backed path and requires video for its publisher track. Other platforms may allow DataChannels, may limit them, or may impose platform-specific joining rules. A deployment cannot be evaluated only by choosing a tunnel mode. The selected platform and its publisher behavior are part of the transport design.

The DC and VP8 transport paths

Whitelist Bypass offers two tunnel modes. DC mode opens an SCTP DataChannel through Pion on the publisher side and places TCP or UDP payloads into that channel. The README describes the frames as DataChannel traffic passing through the platform SFU, which makes this path closer to an ordinary WebRTC data flow.

Video mode keeps the same framing and multiplexing layers but carries the tunnel on a published VP8 video track. The project positions this option for cases where an SFU rate-limits DataChannels while permitting RTP traffic, and where a platform requires video publishing. The trade-off is not merely a different API. Video mode adds an encoding and pacing layer, and the project exposes configurable VP8 pacing. The documentation states that ChaCha20 obfuscation and configurable VP8 pacing are available in headless operation.

The system also includes a ChaCha20 obfuscator. The README does not document the exact wire format, key exchange, configuration file, or failure behavior for that component. That omission matters because the transport resembles a video call only at the platform boundary. Operators should not treat the project description as a substitute for inspecting the relevant relay and creator code before relying on a specific mode.

Headless Pion architecture and relay flow

The recommended architecture is headless on both ends. According to the README, pure Go code using Pion communicates directly with the platform SFU, without a browser. This removes the JavaScript hook path from the recommended deployment, but it does not remove the platform dependency. The headless creators still call platform HTTP APIs or guest mechanisms, and the SFU remains the intermediary.

In the documented DC diagram, traffic begins in applications on the censored device. Android uses VpnService to capture traffic, then tun2socks converts the IP flow into TCP. The Go relay exposes SOCKS5, and the headless joiner passes the resulting stream through Pion to the headless creator. The creator connects to a relay bridge, which provides the route toward the internet. The precise bridge deployment is not described beyond that diagram, so its networking, authentication, and availability requirements remain implementation questions.

The repository separates this logic into `relay/`, platform-specific creators under `headless/`, joiners, mobile applications, and the Electron creator application. The `headless/tests/` directory contains live end-to-end tests that use a creator and joiners over a real SFU. The README documents same-host and Dockerized network namespace execution through `headless/tests/README.md`, but it does not claim that those tests are suitable for production monitoring.

Download and first use on creator and joiner devices

The README says prebuilt binaries are available through GitHub Releases. For the creator side, it gives a desktop workflow rather than a source build command: open the Electron app, select DC or Video, click VK or Telemost, log in, create a new call from the app, and send the join link. The README specifically warns that joining an existing call from the app will not work because the JavaScript hooks must be present from the moment the call starts. That warning applies to the legacy browser flow described there, while the recommended headless deployment uses Go binaries and Pion instead.

For Android, download `whitelist-bypass.apk` from Releases, allow the VPN prompt on first launch, paste the join link, and tap GO. For iOS, install `whitelist-bypass-proxy.ipa` through a sideloading route such as AltStore, Sideloadly, or a developer account. The iOS application exposes a local SOCKS5 proxy only. A user who wants whole-device traffic must configure a SOCKS5-capable VPN application or configure supported applications individually.

Linux users can use a documented joiner command and expose a proxy on port 1080. For example:

headless-wbstream-joiner --room <link> --socks-port 1080 [--socks-user u --socks-pass p]

This command starts the WB Stream joiner with a room link and local SOCKS5 port. Authentication flags are optional according to the README. The Telemost, DION, and Bitrix joiners use their respective documented flags, so copying the WB Stream command and changing only the binary name will not be sufficient.

Source builds, mobile toolchains, and upgrade scope

Source builds require Go 1.26+, gomobile, gobind, the Android SDK and NDK 29, Java 11+, and Node.js 18+. The repository exposes separate scripts for Go artifacts, Android packaging, headless binaries, command-line archives, the Electron creator, and iOS packages. The documented full release command is:

./make-release.sh

The README describes that command as producing the Android APK, Creator app, headless creators, Linux joiners, VK bot, and iOS IPA on macOS. Individual builds are available through `./build-go.sh`, `./build-app.sh`, `./build-headless.sh`, `./build-cli.sh`, `./build-creator.sh`, and `./build-ios.sh`. The iOS build requires Xcode and macOS, and the script takes `proxy` or another documented argument.

The project is licensed under MIT. That permits use and modification under the license terms, but the repository information does not replace review of third-party licenses bundled into mobile artifacts or distributions. The repository is not archived. Its last push was on 2026-10-12, and recent releases include v0.4.4, v0.4.3, and v0.4.2. The release cadence suggests active repository change, but it does not establish compatibility between every platform artifact and every release.

Upgrade cost is higher than a single Go binary for teams using mobile or Electron components. A release can involve Go dependencies, Pion libraries, Android tooling, JavaScript hooks, platform APIs, and SFU behavior. The README does not document a rollback procedure or a formal compatibility matrix, so those checks belong in release qualification.

Limits, failure modes, and a different category of tool

The main limitation is dependence on third-party calling platforms. A change to API authentication, guest-token handling, SFU behavior, publisher requirements, or rate limits can break a path without changing the local Go code. Video mode can help when DataChannels are limited, but it depends on VP8 publishing and pacing behavior that the platform controls. WB Stream makes that dependency explicit because its publisher track is always video.

The system is also exposed to the creator link and relay arrangement. The README does not document how the creator side is secured beyond the SOCKS5 username and password options documented for Linux joiners. It does not define certificate handling, relay authentication, logging policy, or recovery after the creator restarts. Those omissions limit its suitability as the sole basis for a production network without an independent security and operations review.

Whitelist Bypass instead reuses web-calling infrastructure and Pion to fit traffic into services expected to be available on a whitelist-filtered network. The latter can be more appropriate where allowed endpoints are limited, but it trades platform compatibility and operational predictability for that reachability. The project is not a drop-in replacement for a standard VPN with centralized ingress.

Editorial conclusion

Whitelist Bypass fits operators who have access to a creator-side machine with unfiltered internet and clients that can expose traffic through Android VPN, iOS SOCKS5, or Linux SOCKS5. It is a poor fit for a conventional server deployment that needs documented ingress credentials, predictable public administration, or a stable service-level contract. Verify first whether the selected platform permits the required publisher behavior, whether the SFU accepts the chosen DC or VP8 path, and whether the joiner can capture or route the applications that need connectivity.

Frequently asked questions

Official sources

1. kulikov0/whitelist-bypass on GitHub
2. License: MIT
3. Project website
4. README
5. Releases