aragoss

199 green and you were stunned, did you check whether those tests would actually catch it if the fix had been subtly wrong, or was seeing green enough?

how are you actually handling that separation in practice right now, different agent for the tests, or still mostly manual?

have you actually tried breaking something on purpose and seeing if claude's own tests catch it, or is it more that they've just run fine so far?

Hey HN,

About 3 months ago I posted here the first version of Pii-shield, the tool that sanitizes logs to hide api-keys using Shannon entropy, Luhn algorithm for credit cards, and regex for custom pii data.

The tool itself worked well, but manual injecting sidecars to huge clusters was too complicated, that's why I wanted to rewrite the delivery mechanism, and turn the project into a Kubernetes Operator (Mutating Webhook).

In that process I resolved following issues: 1. Replaced the old tail -f | pii-shield pipe with native Go mechanism, which waits for logs files creation to avoid CrashLoopBackOff.

2. If a main container finish it's work, the sidecar continues working and trying to read the logs files. To fix it the Operator injects the agent into the initContainers array with RestartPolicy: Always, so now Kubernetes will know how to behave and kill the sidecar gracefully.

3. If a main container works under root with umask 0077, the nonroot sidecar can't read the the file because of Permission Denied error. Instead of changing user's manifests, the webhook does it automatically, it checks the SecurityContext of a pod, and injects fsGroup: 65532.

Now everything is packed into one helm chart. You just describe one simple label pii-shield.io/inject: "true", and the Operator will do the rest of the work, with no code changing.

Would be happy to hear you thoughts about it.

Thank you! Appreciate the kind words.

Thank you! Hearing that it's being shared is the best kind of validation.

If your team ends up trying it out and has any feature requests (or catches any edge cases), I’d love to hear them!

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.

Yes, absolutely.

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.

Thanks!

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 :)

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!