Protect your credentials
Keep server private keys and client credentials out of shared configs, logs and public reports. Restrict access to the files that hold them.
Security & responsibility
Trust starts with clarity.
Running your own transport gives you control of both endpoints. It also means protecting credentials, restricting access and understanding what cover cannot hide.
Keep local access local
The local SOCKS5 listener has no authentication. Bind it to loopback; exposing it to other devices requires separate access controls.
Keep HTTPS end to end
Use application HTTPS even when traffic travels through Umbra. Vision only removes eligible redundant outer encryption; it does not replace the application’s TLS protection.
Know the limits of cover
Unauthenticated requests go to the real destination, not a proxy-specific rejection. This does not make all traffic indistinguishable or rule out detection by an observer.
- Umbra is alpha software; this page is not a claim of an independent security audit.
- Keep application HTTPS enabled. A privacy transport does not make endpoints, browsers or destination services trustworthy.
- The local SOCKS5 listener has no authentication. Keep it bound to loopback unless you deliberately secure access elsewhere.
- Full Chrome fingerprint equivalence is not established. Network conditions and observer capabilities can affect detectability.
- Protect server private keys and client credentials. Deployment choices, software updates and endpoint security remain your responsibility.
Report issues without exposing secrets.
The source and security model are public. Review the repository’s current reporting guidance before sharing a vulnerability; do not publish credentials or sensitive deployment details.
Open the repository