mhr-cfw-go: go.mod declares the original Python author's module path, config.json is committed, and the relay hop goes through someone else's Apps Script account

go.mod declares github.com/denuitt1/mhr-cfw, not this repository

The module line at the top of `go.mod` reads:

module github.com/denuitt1/mhr-cfw

The repository is `ThisIsDara/mhr-cfw-go`. The path in the module declaration names a different owner and drops the language suffix, so three identifiers disagree: the hosting account, the directory name, and the module path. The consequences are practical rather than cosmetic. `go get github.com/ThisIsDara/mhr-cfw-go` resolves to nothing, because no module is published at that path. `go get github.com/denuitt1/mhr-cfw` resolves to the original Python project, which is not this code. And every internal import in the source tree necessarily resolves through `github.com/denuitt1/mhr-cfw/...`, so the Go code addresses itself by a prefix it does not own. Nothing catches this: `go.sum` pins the integrity of dependencies, not the module's own path. The build still succeeds, because a module is allowed to claim whatever path it likes and the compiler will follow the imports it finds on disk. The failure surfaces later, for whoever tries to depend on this code rather than merely compile it, which is the audience a module path exists to serve.

The configuration file that holds the shared key is committed

The root of the repository contains `config.json`, and the configuration section says to edit it:

{
  "auth_key": "your-secret-password-here",
  "script_id": "YOUR_DEPLOYMENT_ID"
}

Two fields, and both are consequential. `auth_key` is described as a secret password, which means it gates access to the local proxy. `script_id` identifies the Apps Script deployment that performs the actual fetch. A file named `config.json` appears in the tracked file list, so whatever is in it is in git history, including any value a user committed before rotating it. A `.gitignore` is present in the same directory, but the presence of `config.json` in the tree shows it is not covered. Note also what is *not* in the file: no host, no port, no SOCKS5 setting. Those exist only as command line flags, so the secrets and the runtime configuration are split across two places with different exposure properties.

Nothing authenticates the proxy to the Apps Script that fetches for you

The trust chain has three parties and only two links are described. Your browser trusts a local certificate authority, so the proxy terminates TLS with a key pair it generated, described as RSA 4096-bit, upgraded from 2048. The proxy then relays the decrypted request to a Google Apps Script deployment, which is where the real request to the target site happens. Between the proxy and that deployment, the visible configuration is a `script_id`, and nothing in the documentation describes a shared secret, a signature, or a token on that hop. So the entity that fetches every URL you visit is an Apps Script account, and if that account belongs to someone other than you, its owner can observe both the requests and the responses. The `auth_key` protects the local proxy from unauthorised local users; it does not authenticate you to the relay.

A system-wide certificate authority is not a tunnel

Compare this to a VPN or a SOCKS tunnel. A tunnel encrypts traffic to a remote endpoint and the local machine never holds a key that can decrypt it. This tool does the opposite: it installs a certificate authority into the operating system trust store, and one of the menu entries and one of the command line flags exist to do it and to remove it again. Once trusted, that authority can issue certificates for any host, which means traffic from any application on the machine that honours the system store can be intercepted, not only traffic from a browser you chose to configure. The tool also self-signs its interception key rather than deferring to a platform keystore, which means the private key lives wherever the application stores its configuration. The README presents the certificate step as a checkbox for HTTPS interception rather than as a decision about the whole machine. It also offers certificate installation and removal as one-shot command line flags alongside `--setup` and `--scan`, and a `--no-menu` flag for running without the interactive prompt, which is what you would use as a service. A background service that holds a trusted interception key and runs unprompted is the configuration with the least human oversight, and it is the one the flags make easiest to reach.

No external dependencies, against three required modules and two brotli decoders

The code quality section lists Go rewrite, static typing, better memory management, and then:

- No external dependencies, uses the standard library where possible

`go.mod` requires three modules directly, `github.com/andybalholm/brotli` at `v1.1.0`, `github.com/klauspost/compress` at `v1.17.9`, and `golang.org/x/net` at `v0.33.0`, with `golang.org/x/text` arriving indirectly. The qualifier *where possible* is doing real work, but the bullet reads as a property of the project rather than of one line of it. The dependency list also holds two brotli implementations, since the general purpose compression library ships its own, which is worth checking against the YouTube fix it is credited with: better decoding for brotli and gzip responses. Adding a second decoder for the same format is a reasonable fix, but it is a fix that costs a second library rather than a configuration change.

Building from source hardcodes a .exe name with no GOOS set

Two build paths are given. The quick start uses `build.bat` on Windows and `chmod +x build.sh` followed by `./build.sh` on Linux and macOS, and a Termux section repeats the shell script. A Linux and macOS section also offers a manual form with the target set explicitly:

GOOS=linux go build -ldflags "-s -w" -o mhr-cfw-go ./cmd/mhr-cfw
./mhr-cfw-go

The Building from Source section then gives a third form, and it names a Windows executable while setting no target at all:

go build -ldflags "-s -w" -o mhr-cfw-go.exe ./cmd/mhr-cfw

Run on Linux or macOS, that produces a native binary called `mhr-cfw-go.exe`. The strip flags are consistent across all three, and the Go 1.22 requirement matches the module directive, so the inconsistency is confined to the output name and the missing target variable in one of the three copies. The same duplication shows up in the clone step, which appears three times in full, once in the quick start and again in both the desktop and the Termux guides. A reader following the page top to bottom runs the same clone more than once, which is harmless but is a sign that the sections were written independently rather than maintained as one.

A Linux directory, an icon, and four build-related files with no explanation

The root entries are `.github/`, `.gitignore`, `LICENSE`, `Linux/`, `README.md`, `README_FA.md`, `build.bat`, `build.sh`, `ca/`, `cmd/`, `config.json`, `go.mod`, `go.sum`, `internal/`, and `ivk.ico`. Five of them are never mentioned in the instructions. `Linux/` is a capitalised directory name in a project whose own instructions are all platform-neutral, which usually means committed prebuilt binaries or platform assets rather than source. `ca/` presumably holds the certificate authority material, which given the previous section is the most security-relevant directory in the repository and the one a reader would most want described. `ivk.ico` is a Windows icon file whose name is an unexplained abbreviation. The two README files are the English and Persian versions, and the Persian one is linked at the top of the page.

The disclaimer covers your Google account and not the relay operator

There is exactly one disclaimer on the page, and it is about Google services compliance: if you use Apps Script or other Google services, you are responsible for complying with Google's terms, acceptable use rules, quotas and platform policies, and misuse may lead to suspension or termination of your Google account or deployments. Every clause points outward at Google and at the user. Nothing in it addresses the other party in the arrangement, which is the owner of the Apps Script deployment that performs the fetch and can therefore read your traffic, and nothing records whether that deployment is expected to be yours or someone else's. The setup steps for obtaining a deployment ID are delegated to the original Python project's README, steps one to three, which means the ownership question is answered in a different repository that this page does not characterise.

Editorial conclusion

Read the architecture before you decide, and decide with the two structural facts in hand. First, a local certificate authority trusted by the operating system is not a tunnel: it can terminate TLS for any application on the machine, not only for the browser you meant to route, and the tool generates that key pair with its own RSA 4096 key rather than delegating to the system store. Second, the fetch happens inside an Apps Script deployment owned by whoever created it, and the repository documents no authentication between your proxy and that deployment, so that account's owner can see the full URL and the response of everything you browse. If your situation is one where a third party reading your traffic is worse than the filtering you are avoiding, stop here. If you proceed, use a deployment you own, treat the shared key as a credential that belongs in gitignore rather than in the tree, and fix the module path before you depend on the import path.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. ThisIsDara/mhr-cfw-go on GitHub