The interesting part is never the exploit

The exploit is never the interesting part. What matters is whether the thing was built so the exploit had somewhere to go. That's a design question, and it gets decided long before anyone attacks you.

1. The guard has to be architectural, not textual. "Don't reveal X" in a prompt fails the first time someone is clever or insistent. The only defense that holds is an agent that doesn't possess the thing. Send it an injection and watch it have nothing to give up. try to break it →
2. A backup that has never been restored is a hope, not a backup. Same for isolation. Kill the tunnel and the workloads lose the internet rather than quietly falling back to the LAN, because the fallback route does not exist. watch it fail closed →
3. Prevention beats detection, and it is not close. A control that evaluates at creation has no exposure window to measure. Detection's best case still costs you the lag plus however long a human takes. run the timeline →
4. Measure before you optimise, or you will spend the night on the wrong thing. I instrumented my voice assistant expecting text-to-speech to be the bottleneck. It was the fastest stage in the pipeline. build the pipeline →
5. Run what you build. I ship my own images of the recipe app my household actually eats from, so every regression I write lands on the machine I use at dinner. It is the fastest feedback loop I have. see the bug →
6. Own the code, and "I wish it had X" becomes a thing you just do. Eleven releases of a manga reader later, that has been true every time. drive the reader →

Download résumé (PDF)

Web version: no phone number, no street address.

PADI certified diver. I read a lot of manga, which is how the Makimono fork started: an itch to fix the reader I use every day.

justice.ethan04@gmail.com  ·  LinkedIn  ·  GitHub