Privacy Friendly Frontends With Tailscale
Privacy Friendly Frontends with Tailscale in Docker Compose.
List of frontends
Frontends are exposed via Tailscale and only available to devices authorized on a Tailnet.
All frontends are secured over https with Caddy.
- Tailscale Account
- Docker (or any OCI container runtime)
- Docker Compose (or any
docker-composecompatible tool)
- Update
TS_AUTHKEY,TAILNET, andHMAC_KEYvariables in.env - Run
start.sh
Tailscale Configuration
Privacy Stack Configuration
- Copy
.env.exampleto.env - Update
TS_AUTHKEY,TAILNETvariables in.env - Generate random key for
HMAC_KEYin.env
Run with the start.sh script.
This script will update TS_CHANGEME and HMACKEY_CHANGEME in various configurations from the variables in .env.
Example output of start.sh,
~/privacy-stack$ ./start.sh
Updating caddy configuration
Updating nitter configuration
Updating redirector configuration
Starting privacy-stack
Verify the frontends come up by checking your Tailnet machines and six new names will appear (nitter, imgin, scribe, teddit, searxng, invidious).
If they do not appear, check the docker compose logs for errors.
With the stack running, access the services at the name.tailnet.
For example, with a Tailnet name of tailfe8c.ts.net, the frontends are at these addresses,
- https://nitter.tailfe8c.ts.net
- https://teddit.tailfe8c.ts.net
- https://imgin.tailfe8c.ts.net
- https://scribe.tailfe8c.ts.net
- https://teddit.tailfe8c.ts.net
- https://searxng.tailfe8c.ts.net
- https://invidious.tailfe8c.ts.net
tailscale-router is configured as an Exit Node that a Tailscale client can send all traffic through. This can also act as a subnet router if --advertise-routes= is passed in TS_EXTRA_ARGS environment variable.
The Redirector Plugin can modify a link to the upstream site to the appropriate privacy frontend, including all relevant URL information. This makes using a privacy frontend seamless and the default.
For example any links that go to twitter.com will automatically redirect to https://nitter.tailfe8c.ts.net, passing along the rest of the URL so any links transparency show up in the target privacy frontend.
The redirector directory contains an example Redirector configuration file to use.
Q: Why?
A: See Privacy Guide to Frontends and Privacy Frontends
Q: Why not use publicly available frontends?
A: Self-hosting your own frontends can improve performance and gives more control over frontend setup and configuration.
Q: Doesn't running these yourself make you more visible?
A: This stack can run on a small VPS (tested on a t3.medium) instance to provide an added layer of anonymonity. Layering in a VPN can also help mix traffic.
Q: Why are there so many containers?
A: Tailscale Magic DNS does not currently support wildcard domains, and therefore each frontend needs it's own Tailscale machine so it's hbstname resolves the Tailnet. An alternative is a single hostname to proxy all frontends, but this becomes complicated as almost all frontends assume they are running in their own domain and do not handle relative URL changes easily.
Q: Why are there so many volumes?
A: The varlib volumes allow re-using of an existing Tailscale machine record between container start/stops. Without persisting outside of the container a new Tailscale machine is created every time with an number appended to it, eg nitter-1. The varrun volume shares the Tailscale socket with Caddy so Caddy can manage Tailscale HTTPS certificates. Instead of volumes, bind mounts could also be used.
Q: Configuration X makes this insecure, and X should be done instead.
A: Probably. This stack is focused on privacy and not security.
WIP