(If this has been done or isn't practical, please feel free to tell me to pound sand.)
Thesis: Everything is becoming a subscription. Everything is hosted in the cloud. We hand over pieces of our digital identity every time we click through a ToS. Convenience is increasingly packaged as “just trust us,” and the practical trade is less ownership, less privacy, and more silent telemetry. I’m proposing a self-hosted, open-source project that pushes back by keeping your telemetry, metadata, and identity local by default, and by interrupting risky data flows before they leave your network.
In one phrase: an at-home, accessible Secure Web Gateway and Data Loss Prevention stack, SWG/DLP, delivered as an easy Docker install.
(If this has been done or isn't practical, please feel free to tell me to pound sand.)
Thesis: Everything is becoming a subscription. Everything is hosted in the cloud. We hand over pieces of our digital identity every time we click through a ToS. Convenience is increasingly packaged as “just trust us,” and the practical trade is less ownership, less privacy, and more silent telemetry. I’m proposing a self-hosted, open-source project that pushes back by keeping your telemetry, metadata, and identity local by default, and by interrupting risky data flows before they leave your network.
In one phrase: an at-home, accessible Secure Web Gateway and Data Loss Prevention stack, SWG/DLP, delivered as an easy Docker install.
In the enterprise world, the basic concept already exists: secure web gateways, TLS inspection, and data loss prevention are standard tools for controlling outbound traffic and preventing sensitive data from leaving a network. At home, there’s nothing comparable that a normal technical user can install in an afternoon. The consumer market tops out at DNS sinkholes, ad blockers, and per-device VPN apps. Useful, but not equivalent. DNS blocking can’t see what’s inside encrypted traffic, and encryption does not prevent metadata leakage or stop an app from transmitting identifiers to its chosen endpoint. Packet inspection is where the real leverage is, and that’s exactly where consumer tools tend to stop because it’s hard, breakable, and messy across devices.
I’m posting this because I want someone more capable to build a practical “personal SWG/DLP” style tool as a simple Docker deploy. Something you run at home that offers real control over telemetry and accidental PII leakage across your devices without requiring constant manual diligence and without requiring everyone to become a network engineer.
Who this would be for: privacy-conscious people, homelabbers, small offices, and families who want a centralized control plane for outbound traffic and who are willing to accept some friction in exchange for better privacy outcomes.
Who this is not for: people who aren’t concerned about metadata and have fully opted into convenience ecosystems where data extraction is the business model. If you’re all-in on always-on assistants, smart speakers, and “free/cheap because the data is the prize” services and you don’t want friction, this will feel like the opposite of what you want. The system is meant to expose that trade and make it actionable, not to normalize it.
Concept: a self-hosted privacy gateway that runs as a Docker-deployed service and sits between your devices and the public internet. Devices opt in by connecting through a locally hosted VPN. Once a device routes through the gateway, outbound traffic can be monitored and controlled consistently, rather than relying on a pile of device permissions and app settings that drift over time. It's a stopgap between you and accepting a terms of service agreement that gives some data broker free access to your stuff. It works even if you're not using good judgment or just not adept at good privacy hygiene. What's more, if someone like Cloudflare offered this, you'd still pay a subscription and not in full control of the process.
The baseline capability should go beyond the current home “DNS-only” ceiling. DNS filtering is a good start, but it does not solve the real problem by itself. Even if you block known trackers, apps can still phone home to first-party endpoints, and encryption makes most payloads opaque. Meanwhile metadata still leaks: destination IPs, TLS SNI, certificate details, timing and volume, QUIC behavior, and other signals that can be used to fingerprint devices and users. A serious consumer privacy gateway needs to operate at multiple layers: DNS, IP and protocol egress, and behavior baselining per device, so it can flag or block new and suspicious outbound patterns rather than only relying on static blocklists.
The differentiator would be an optional, opt-in inspection layer that mimics enterprise DLP behavior. For devices that explicitly trust a local interception certificate, the gateway can decrypt HTTPS via a proxy and inspect outbound requests for sensitive information.
The goal is not blanket surveillance of the user; The goal is to detect and interrupt high-risk transmissions: email addresses, phone numbers, precise location coordinates, account tokens, persistent device identifiers, ad IDs, and other unique identifiers embedded in headers, URLs, or request bodies. When the detector triggers, the gateway applies policy actions like notify, block, allow once, or allow permanently. The key UX is “stop the leak and ask the user” rather than silently allowing an app to exfiltrate identifiers because the user clicked through a vague permission prompt weeks ago.
This has to be designed around a harsh reality: encrypted traffic and certificate pinning will limit content visibility. So the correct approach is “visibility tiering,” not magical thinking. Most devices will operate in metadata-only mode where you still get meaningful protections: destination control, anomaly detection, and baseline drift alerts. Only opt-in devices get decrypted inspection. Pinned apps may break if intercepted, and the gateway should handle that gracefully by falling back to metadata-only policies for those flows rather than trying to be clever. The product should be honest about what it can see and what it cannot.
Another critical requirement is avoiding prompt fatigue. If it constantly interrupts people, it will be uninstalled. The policy engine should be baseline-and-diff: learn normal behavior per device, then notify only on meaningful deltas. It should have modes such as learning (observe only), enforce (block high-confidence leaks and regressions), and lockdown (allowlist-first). Decisions should support allow once (short TTL), allow always (tight scope by device + domain + path pattern), and block with an explanation. The core value is not perfect prevention. It is a measurable reduction in exposure with low noise.
If someone builds this, the deliverable is essentially a personal, self-hosted counterpart to enterprise outbound security controls: VPN in, observe everything, enforce baseline rules, optionally decrypt for deeper inspection, detect and prevent high-risk data disclosures, and present the user with high-signal decisions only when needed. The gap isn’t that the concept is unknown. The gap is that nothing comparable exists in the personal market as an easy, self-hosted Docker install that treats outbound privacy as a first-class problem rather than “block some ads and call it done.”
Sorry for the wall of text - As billionaires start owning more, I am increasingly passionate about privacy but know only enough to be dangerous. I don't have the skills or background to build this myself.
Thanks for reading and thanks for your time. I hope someone can figure out a way to build this.