The vote to stay blind

Cinder does one thing. You give it a file, it locks the file in your own browser before anything leaves your computer, and it hands you a link. The first person to open that link gets the file, and Cinder erases its copy in the same breath. Cinder never holds the key, so it could not read your file even if someone made it try.

Someone asked a fair question: what happens if a stranger floods it with traffic? That costs money, and it can knock the service offline.

The normal way to stop that is to have the service watch where every request is coming from and turn away anyone asking too often. It is what nearly every website does. It is cheap and it works.

But watching where requests come from means keeping a note of who is asking. For a tool whose entire purpose is not knowing who you are, that is not a small thing. It is the thing.

So we measured instead of assuming, and found two facts that settled it.

The first: the defense would not have worked here anyway. Someone determined could take Cinder offline from a single laptop, and spreading the same traffic across twenty connections slips under any limit gentle enough not to hurt real people.

The second: that kind of limit hurts real people first. It works by address, and enormous numbers of people share one — everyone on a phone network, everyone at a school or a library, everyone using a VPN. Many of them use a VPN precisely because they need privacy. A privacy tool that shuts out the people who most need privacy has protected no one.

So Cinder chose to stay blind. Under a flood it slows down and turns people away, and it does that by simply running out of room rather than by recognizing anybody. Nothing is lost when this happens: a request that gets turned away never reaches the part that erases your file, so your link still works once the flood passes. The honest cost is that Cinder can be pushed offline. We decided we would rather be knocked down than start keeping track of people.

The PDF of this note was sent through Cinder before it was published. Not a stand-in, not a test file: this exact document, through the live product, the same way a stranger would.

That practice has a name — dogfooding, using your own product for real work instead of only testing it. It matters because of something that happened here.

Cinder's tests compared files before and after and confirmed they matched perfectly. Every one passed. But the files those tests used were made up — long runs of predictable filler, named to look like documents. A file like that can survive a round trip flawlessly and prove almost nothing, because it was never a real document to begin with. It has no structure to break.

The gap showed up the moment a real one was tried. A file arrived that would not open, and it looked like Cinder had corrupted it. It had not: the file had been empty filler all along, and Cinder returned it exactly as received, faithfully preserving something that was already broken. The tests were right and useless at the same time.

Matching before and after is not the same as working. A test that only asks whether the bytes survived can pass forever while the product fails the person holding the file. The only reliable check is to send the real thing and then open it.

40 concurrent claims   → exactly 10 × 200, 30 × 503
warm service time      ≈ 165 ms
10 slots ÷ 0.165 s     ≈ 61 req/s sustains total denial, from one machine
request cost           < 200 bytes

during the flood       Throttles 286 · Invocations 27 · Errors 0
                       ConcurrentExecutions Maximum = 10.0 exactly