Writing
What I am building, what broke, and what the numbers actually said. I am a developer, not an incident responder, so what you will find here is engineering and measurement rather than case work or advice about how to run an investigation.
A .docx looks like a format you need a dependency for. It is a ZIP of four XML files, and 219 lines of plain JavaScript is enough to build one Word will open. The parts you actually need, the CRC32, the store-only ZIP layout, and the gotcha that silently merges two tables into one.
Read itEvery privacy page says it does not sell your data, and you have no way to verify it. Mine has a test: a script that reads the server code, the schema and every page, and fails when a published claim stops being true. Including the one it made me admit.
Read itBlanking every hostname makes a set of notes unreadable, which is why nobody does it and why nobody shares their notes. Stable pseudonyms keep the timeline followable. Here is the design, the three things the tool refuses to touch, and a leak its own tests caught before anybody else could.
Read itThere is a study running on how incident reports actually get written. When it has enough responses to say something, the findings get posted here, including the ones that are inconvenient for the thing I am building.
Two commitments come with that, and they are the reason some of the most interesting material on my desk is not on this page. Results are published in aggregate, with no firm names, no client names and no case details. And nothing anyone tells me is attributed to them without their written permission first, asked for afterwards with the exact quote in front of them. Several practitioners have sent me things worth a post each. None of it goes out until they have said yes to the specific words.
If you would rather be told when something lands than check back, the beta list is the only mailing list there is, and it is low volume because there is not much to say yet.