From 2ade8c807584bff0b60d6b6f278dbde29b13a5ff Mon Sep 17 00:00:00 2001
From: srdusr <99972264+srdusr@users.noreply.github.com>
Date: Mon, 29 Jun 2026 09:58:00 +0200
Subject: Browser-launcher helper: throwaway proxied profile, one flag

Adds -launch-browser=chrome|firefox|auto to the mitmux TUI binary.
Resolves an installed browser (PATH first, then common per-OS install
locations), spins up a brand new throwaway profile, configures it to
proxy through the daemon, and opens straight to http://mitmux.cert/ so
installing the CA in that profile is one click.

This is the answer to "build an in-house browser": a bundled GUI
browser is a different, much larger project and works against this
tool's terminal-native positioning - the actually useful part of that
idea is zero-friction setup (proxy + CA-install page, no profile
pollution), which this delivers by launching the user's own browser
in a disposable profile instead of embedding one.

Chrome takes --proxy-server as a flag; Firefox has none, so its
profile gets a generated user.js instead - the only non-interactive
way to configure it. Verified against this machine's real installed
Chrome and Firefox: binary discovery resolves both, auto prefers
chrome-family when both are present, and the generated Firefox prefs
are well-formed. Deliberately did not spawn a live browser window as
part of verification - that's a visible GUI action on whoever runs
it, left for a user to trigger by hand via the flag.
---
 PLAN.md | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

(limited to 'PLAN.md')

diff --git a/PLAN.md b/PLAN.md
index 073c52e..8cffc0f 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -476,6 +476,34 @@ Quick start (previously this was implied but never actually spelled
 out for a phone/tablet setup, which is a real, common daily workflow
 this tool hadn't explicitly walked through before).
 
+Considered building an actual in-house browser (a GUI) and decided
+against it: a bundled GUI browser is a different, much larger project
+(a Chromium/WebView embed and all the maintenance that implies), works
+against this tool's own positioning as a terminal-native daily driver,
+and duplicates what a real browser already does far better. The useful
+part of "in-house browser" isn't rendering - it's zero-friction setup:
+a browser already pointed at the proxy with the CA one click away,
+without touching the user's real browser profile. `cmd/mitmux/browser.go`
+delivers exactly that instead: `-launch-browser=chrome|firefox|auto`
+finds an installed browser (PATH first, then common per-OS install
+locations for the cases PATH won't have - an unregistered macOS .app
+bundle or a Windows Program Files install), spins up a brand new
+throwaway profile (`os.MkdirTemp`, never reused, never cleaned up
+explicitly - that's what "throwaway" means: a fresh identity every
+launch, not something this code should delete out from under a still-
+open browser), configures it to proxy through the daemon, and opens
+straight to `http://mitmux.cert/`. Chrome takes `--proxy-server` as a
+flag; Firefox has none, so its profile gets a generated `user.js`
+setting `network.proxy.*` prefs instead - the only non-interactive way
+to configure it. Verified against this machine's real, installed Chrome
+and Firefox: binary discovery resolves both correctly, `auto` prefers
+chrome-family when both are present, and the generated Firefox prefs
+file is well-formed (integer port pref unquoted, matching what Firefox
+expects). Actually spawning a visible browser window wasn't done as
+part of automated verification - that's a live GUI popping up on
+whoever's running it, not something to trigger without them asking for
+it in the moment; the `-launch-browser` flag is there to try by hand.
+
 ## Mouse support
 
 Explicitly requested - this is a real terminal app meant to work in any
-- 
cgit v1.2.3