If you type "morse code mishap" into a search engine, you don't get us. You get an alt-acoustic duo out of the Greater Boston area, two guys with pipes and some strings, who dropped a full album on Bandcamp back in November 2022. Eric Schaaf on vocals and percussion, Nick Sapack on guitar. Good for them. Not what we're here to talk about.
Our mishap didn't have a tracklist. It had a log file, a failed sanity check, and about twenty minutes of us staring at a headline that looked like static.
The Dot Problem, Round Two
We'd already been burned once. A while back, our content pipeline pulled a headline off a dev.to tap that was made entirely of dots -- not a typo, not a mangled string, an actual title that read as a row of periods. We wrote up the fix: a topic sanity check that flags input with too little character variety before it ever reaches the generation stage. Ship it, close the ticket, move on.
Except "too little variety" is a specific kind of blind. It catches strings that repeat the same character. It does nothing for a string that alternates between two characters in a structured pattern -- because structure looks like content to a naive check. That's exactly the gap something crawled through next.
Why It Slipped Through
The new headline wasn't all dots. It was dots and dashes, spaced out, with slashes breaking up clusters. To the character-diversity check, that's plenty of variety. Two symbols alternating in irregular runs reads as noisy, human-shaped text -- the kind of thing the validator is supposed to let through.
It passed. It went into the queue. It almost went into a draft.
Someone on the team caught it during a routine spot-check of the ingest queue, mostly by accident -- the string just looked wrong sitting next to normal headlines, too clean, too rhythmic. Fed it into a Morse code translator to see what would happen. It decoded. Cleanly. Into a short phrase that had nothing to do with the source article it was supposedly the headline for.
Somewhere upstream, a page had embedded Morse as a kind of Easter egg or watermark -- the kind of thing you'd expect to find hidden in a game or a movie credit, which is the exact use case morse-coder.com lists for its own decoder. Our scraper didn't know that. It just saw text in a headline field and moved it along.
Teaching the Validator to Read
Here's the uncomfortable part: our sanity check was built to answer "does this look like garbage," and it did that job fine. What it couldn't answer was "does this look like a different kind of language wearing a headline's clothes." Those are two different problems, and we'd only solved one of them.
Morse is a good stress test for this because it's deceptively well-formed. It has a strict character set -- dots, dashes, spaces, slashes for word breaks, exactly the structure Morse Code Translator documents on its own site. It has consistent spacing rules. It passes almost every generic "is this real text" heuristic you'd bolt onto an ingestion pipeline, because it was designed to be unambiguous and regular. That's the whole point of the encoding. It's also exactly why a diversity-based filter waves it through -- regularity looks like structure, and structure looks like meaning, even when there's no meaning your pipeline is equipped to extract.
It's the same category of failure we ran into when we wrote about a misnamed model leak -- the surface label said one thing, the underlying content said another, and the validator we had was checking the label, not the content. Encoding mishaps and naming mishaps rhyme. Both are cases where your pipeline trusted a shape instead of checking what the shape actually decoded to.
The Fix
We didn't try to build a general "detect every encoding on earth" filter. That's a losing game -- there's always another scheme you haven't thought of, and chasing all of them turns your validator into a pile of special cases nobody wants to maintain.
Instead we added a narrower check: run any suspiciously symbol-heavy, low-alphabet string through a quick regex match against Morse's character set (dots, dashes, spaces, slashes, nothing else) before it clears ingestion. If it matches, attempt a decode. If the decode produces real words, the string gets flagged for manual review instead of auto-passing. If it doesn't decode into anything readable, it probably wasn't Morse to begin with, and it goes back to the original diversity check to sink or swim on its own.
It's a cheap check. It runs before anything expensive happens downstream. And it buys us a second opinion on exactly the kind of input that fooled us the first time -- structured noise that reads as content because it's regular, not because it's real.
What This Means for Your Pipeline
If you're building anything that ingests web content and hands it to a model -- a scraper, a tap, a content queue like ours -- the lesson isn't "watch out for Morse code specifically." It's that structural validity and semantic validity are different checks, and most off-the-shelf sanity filters only give you the first one. A string can be well-formed, low-entropy in exactly the way your filter expects normal text to be low-entropy, and still be encoding something your pipeline has no business decoding blind.
We already learned this once with a row of dots that meant nothing. This time it was dots and dashes that meant something, just not what our system thought it meant. Next time it'll be something else -- base64 fragments, zero-width characters, whatever a source page happens to embed for its own reasons. The fix isn't a bigger blocklist. It's building the habit of asking "what does this actually decode to" before you let a string anywhere near a generation step, the same instinct that pays off whether you're parsing bytecode in a Python interpreter or parsing headlines off the open web.
The band gets to keep the good title. We'll keep the incident report.
Top comments (0)