UUIDs: By default—no. Since UUIDs are Hex (limited charset 0-f), they have lower entropy than Base64 secrets. The threshold is tuned to sit safely above UUIDs but below API keys.
Naming: You are totally right. Currently, it focuses on "high-entropy PII" (passwords, auth tokens, session IDs) rather than names or SSNs. "Secrets Shield" might have been more precise, but naming is hard :)
You can fine-tune the sensitivity via the PII_ENTROPY_THRESHOLD environment variable.
If you consider UUIDs to be sensitive in your context (or if you are getting false positives), you can adjust the threshold. For example, standard UUIDs have lower entropy density than API keys, so slightly tuning the value (e.g. from 3.8 to 3.2 or vice-versa) allows you to draw the line where you need it.
Is there a way to tell it to just recognize UUIDs and redact those without adjusting the threshold? In our case, UUIDs is just an exception. I think all the other stuff you're doing is correct for our situation.
Currently, no — the scanner focuses on entropy and specific Key Names, not value patterns (Regex).
However, if your UUIDs live in consistent fields (e.g., request_id, trace_token, uuid), you can add those field names to the Sensitive Keys list. This forces redaction for those specific fields regardless of their entropy score, while keeping the global threshold high for everything else.
That said, "Redact by Value Regex" (to catch UUIDs anywhere) is a great idea. I'll add it to the backlog.
Update: Seeing some folks pulling the Docker image. Just a heads up — the default entropy threshold is 3.8, which is tuned for API keys. If you are testing with simple words like 'test', it might not catch them (by design). Check the README for tweaking PII_ENTROPY_THRESHOLD.
Hi HN, I'm a QA engineer and the creator of Chaos Proxy. I built this because...
I built this because debugging HTTP traffic with local proxies (like Charles or Proxyman) has become a bottleneck for me. Getting a GUI app running in CI is painful, and sharing a specific failing request with a colleague usually means sending screenshots or huge export files.
Chaos Proxy is a managed MITM proxy running in the cloud. It solves the "it works on my machine" problem by giving you a shareable URL for your traffic logs.
How it works:
1. You get a dedicated proxy endpoint (e.g., `chaos-proxy.debuggo.app:8080`).
2. Configure your device/simulator to point there and install the CA cert.
3. Traffic flows through an isolated Docker container (running mitmproxy) where I apply chaos rules (latency, 500 errors) or simply inspect JSON.
The Stack:
- Core: Python & mitmproxy scripting API. Custom addons handle the chaos logic (bandwidth throttling, status code injection).
- Orchestration: Next.js 16 (App Router) interacts with Docker Engine to spin up a fresh container for every project.
- Sync: Redis acts as the bridge. Changing a delay rule in the UI applies it instantly to the running proxy process.
- Storage: Supabase (Postgres) for metadata.
Note on Sign-up: Since each session spins up a real, isolated Docker container, I require a sign-up to prevent abuse. However, no email verification or credit card is required — you can jump straight into the dashboard in 10 seconds.
Privacy: Logs are ephemeral (TTL 24h) and bodies are not stored permanently. This is designed strictly for dev/staging, not production traffic.
Happy to answer questions about the orchestration logic or how I handle the mitmproxy addons!
If your team ends up trying it out and has any feature requests (or catches any edge cases), I’d love to hear them!
reply