Something in the app goes wrong, and you want to tell someone. That should be the easy part. It usually isn't — because a bug report that is actually useful to whoever has to fix it is made of precisely the material you would think twice about handing over. What you were doing. What was on screen. The names of things. Often the contents of things.

This is the quiet trade in most software. The report that helps is the report that exposes you, so you either send it and hope, or you don't send it and the bug stays.

Scrubbed before it is stored, not before it is sent

The ordering here is the part worth noticing. When a report is captured it is scrubbed of personal detail at the moment it is parked, not later, on the way out the door. The code that eventually approves a report reads the stored copy and notes, plainly, that it is already scrubbed when parked in outbox.

That is a smaller-sounding decision than it is. If scrubbing happened at send time, then somewhere on your disk there would be a waiting queue of unscrubbed reports — a pile of exactly the sensitive material the scrubber exists to remove, sitting there until you got round to deciding. Scrubbing on the way in means that pile never exists.

While it waits, it is encrypted. So is the list of personal-data findings the scrubber produced — the record of what it caught is treated as just as sensitive as the thing it caught, which is right, because a list of where your personal details appear is itself a map of your personal details.

You read it first

Nothing goes anywhere on its own. There is a preview step whose entire job is to decrypt the parked report and show it to you with the personal-data findings highlighted. Not a summary. Not a checkbox saying diagnostic data may be collected. The actual report, as it would be sent, with the scrubber's findings marked in it.

Then you approve it, or you discard it. Those are the two doors, and both of them are yours.

What happens when it breaks

The more telling behaviour is what the thing does when it cannot do its job.

If the encryption key isn't available, the report doesn't get sent in the clear as a fallback — the operation refuses, and says so: replay encryption not initialized. If decryption fails partway, the failure is caught and logged and the process continues with less information, not more: null content, an "unknown" fingerprint. There is no path where a malfunction results in your raw data going out.

That direction matters. Plenty of systems fail toward completeness, because a degraded-but-full payload looks more helpful than an empty one. This one fails toward silence.

One thing it warns about rather than blocks

Worth being straight about, because it is a real limit. There is a credential that marks a peer as a legitimate recipient of debug reports, and the gate around it is routing-only. It governs where reports get routed automatically; it does not stop you sharing a report by hand with someone who doesn't hold that credential. If you do, the response comes back with a warning attached so the interface can tell you the recipient isn't a credentialed reviewer.

That is a deliberate choice rather than an oversight, and you can disagree with it. The reasoning is that a person deciding to send their own report to a specific someone is exercising a judgement the software shouldn't override — so it tells you what it knows, and lets you decide. Warn, don't block. But it does mean the credential is not a wall, and it would be dishonest to describe it as one.

The point

None of this makes reporting a bug interesting. It makes it legible, which is the thing that was actually missing. You are not asked to trust that a report was cleaned up. You are shown what is in it, told what was found, and asked. And when the machinery underneath fails, it fails by sending less of you, not more.

---

Written by AI agents from real project logs; owned and edited by Mujo.