Mordikan

No, installing Tailscale on all machines is not actually required. You can setup a funnel that exposes a service to the internet for all to see. This also removes the requirement for them to access via Wireguard if desired. https://tailscale.com/kb/1223/funnel

I think the idea of an IP address (IPv6 or not) providing anyone a semblance of privacy is wishful thinking in this age. Google ad revenue in the EU is estimated to be lower because the power in GPDR areas isn’t in PII obfuscation, its in the consent model. Positive opt-in to Legitimate Vendor Interest makes tracking difficult, not whether your IP is generic. You have to remember companies like Google are still able to monetize off of users in mobile CG-NAT environments in the US/EU. Given the roughly 150 other metrics Google (or any publisher/SSP would have access to), removing one doesn’t really stem the tide.

What’s also interesting is how IPs become anonymized. For IPv4, the industry standard I kid you not is to take the 4th octet and mark it zero. That’s it. It just assumes carriers use /24 CIDRs like someone’s home network might. The funny part is what if that was 50.50.0.0/22? A publisher could in practice replace one user’s IP with another user’s IP which means that they still would be passing PII unanonymized which could violate GDPR.

IPv6 uses the same basic system. 2001:db8:85a3:8d3:1319:8a2e:370:7348 becomes 2001:db8:85a3::. You just truncate at the 64th bit. Rolling through available host bits doesn’t really matter then. IPv6/IPv4 really aren’t ever used for Google user syncing.

I’ve mentioned this elsewhere, but to fair, even without you providing Google an IPv6 address, they still know exactly which computer contacted them from inside your LAN. Even in GDPR territory they can do that.

Yes, that is correct. As I said, there is probably already a docker image out there for the provider you go with.

I think its easier and shorter to say what is the same between the two than different, but some things that are different:

1. Filesystem (ex. Linux treats everything as a file, more flexibility in organization, more compatibility for differing systems, etc)
2. Security Model (NTFS vs UNIX, selinux, ACLs, etc)
3. File Execution (File extensions don’t really matter in Linux - based on file permission not extension, ELF vs PE, etc)
4. Kernel (Monolithic vs Hybrid kernel systems - Windows hands off to HAL vs the Linux kernel doing core functions)
5. System Calls (Windows use Win32/NT APIs, Linux uses POSIX-compliant)

Performance is dependent on use case, but in general:

1. Linux uses fewer system resources
2. Linux has faster boot time
3. Linux has better CPU/disk throughput
4. Windows has better gaming driver support
5. Linux has higher stability/control (hence why its the defacto server OS)

If we stripped all ms’s junk out and made windows open source, would we still prefer linux?

In what context? For gaming maybe, but that’s one single use. There is more to computers than video games, at least for the majority of Linux users. I wouldn’t trust Windows on any server I run.

Pretty sure that is just a discrepancy between when a site has last checked client announcements from the tracker and when what the tracker currently shows. As of 2025, TPB for example links to 3.2 million torrents. Assuming client announcements were set to an average 1hr interval, that would require TPB to make 76.8 million checks every day for announcement updates.

So, I could see sites not maintaining accurate seeder/leecher data.

The only real constraint here is VPN port forwarding. You would need a VPN provider that supports that in order to hit DHT swarms. So, just make sure the provider has that.

As for kill switching, run the VPN and torrent client through docker. There is probably already a docker image out there that does that depending on what provider you go with. Essentially what you’d be doing is sandboxing your torrent client and then only passing in the VPN interface via docker network to that client. If the VPN tunnel goes down there is no other egress point off the network segment and zero chance for traffic using a different interface.

One correction to this:

The Arch package manager is Pacman, not AUR. AUR is the Arch User Repository and is definitely not stable :)

I would only expose a port to the Internet if users other than myself would be needing access to it. Otherwise, I just keep everything inside a tailscale network so I can access remotely. Usually I believe people put a reverse proxy in front of the Jellyfin server and configure your certificates from there. So Jellyfin to proxy is insecure and then proxy to internet is secure. Lets Encrypt is an easy way to do that. And if you are going to expose a port you definitely want fail2ban monitoring that port.

If using tailscale funnels, you can technically skip the certificate part as that’s done for you, but that would take away from the learning experience of setting up a proxy.

Yeah, GPG keys expire, but that happens with all package management systems if left alone long enough. I mean you’d have to maintain like 3 packages (linux, wireguard-tools, archlinux-keyring). In Debian you’d have to maintain the kernel, debian-archive-keyring, and wireguard-tools. Its the same.

If its solely for setting up a wireguard server, it doesn’t need to be rolling release. Nothing should really need changing.

1. Alpine Linux due to it being lightweight and hardened
2. Arch Linux due to it being lightweight and fast
3. Rocky 9 due to HAProxy in case you decide to turn this into a DIY datacenter :)

Adtech relies on the OpenRTB 2.5/2.6 spec for tracking, you would have removed 1 identifier out of a hundred (one that isn’t really used anyway given SSAI is so popular). In addition to that, cookie expiry timers are typically set to 365 days meaning you’re VPN would need to enabled at all times to not invalidate multi-hop. WebStorage API based trackers tend to be indefinite.

ORTB spec: https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf

EDIT: If anyone is looking for more specifics about WHY IP addresses and multi-hop don’t matter, the spec includes a mention:

BEST PRACTICE: Proper device IP detection in mobile is not straightforward. Typically it involves starting at the left of the x-forwarded-for header, skipping private carrier networks (e.g., 10.x.x.x or 192.x.x.x), and possibly scanning for known carrier IP ranges. Exchanges are urged to research and implement this feature carefully when presenting device IP values to bidders.

The issue is that mobile is so prevalent and mobile networks rely so extensively on CG-NAT that even with XFF headers, there’s no good way to tell if you are going to get an IP address that actually matters. You could potentially put in a lot of auction time trying to figure that out and still just end up with a private address that’s unusable. So, aside from the devicetype and the geo object which is used for geo targets and fencing, the device object isn’t useful in tracking. Instead adtech uses the user object. This object should contain all your GDPR specifics, any EIDs, 1st party cookie IDs, etc. Even if those change, there usually exists backend mapping that allows for vendors to correlate different user IDs as being the same user ultimately.

That is not true, the sites do still track you. VPNs don’t prevent tracking, they just make sure the tracking is done through a secure tunnel.