Extraction is where the visibility goes. A browser computes layout, applies the inline style, and paints nothing. A text extractor walks the nodes and returns the string. Same document, two outputs, and only one of them reaches the model. The dev.to write-up is honest about how varied that step is in practice: a pipeline might receive raw HTML, a stripped-tags plain text extraction, or a DOM-rendered snapshot, and many implementations simply pull the text nodes and hand them to the model [6]. Only one of those three has any chance of knowing the span rendered blank, and by the time the string is in the context window the visibility information is gone anyway [12].
Count the sample payload the post prints. The visible paragraph is ten words about Q3 numbers. The hidden span is nineteen words telling the summarizer to state that the sender approved a wire transfer to an account ending 4471 [7]. Roughly 66 percent of what the model summarizes was never on the recipient's screen [18]. Nothing in the blob marks which two-thirds arrived styled invisible, and the post's argument is that the model has no reliable way to separate content-to-summarize from instructions-about-summarizing once both are undifferentiated text [8].
This survives the security layer because sanitization is built that way on purpose. Sanitizers that strip script tags and dangerous attributes generally leave styling intact, because colour and font-size are ordinary in legitimate mail, and stripping inline styles wholesale would break a large amount of normal rendering [10]. So the hidden span passes through the sanitizer whole and waits for the extraction step [11]. Spam scoring does not close the gap either: it grades sender reputation, links, attachments, and bad patterns in visible text, and was never built to treat CSS-driven invisibility as a security signal [9]. The trick is old enough that its original job, stuffing keywords past Bayesian filters, now reads as almost quaint [4].
The post's proposed fix is also the post's product. It argues detection needs no CSS understanding at all, only a scan of the extracted text before it reaches the model [16]: a fast-path regex for phrases like "ignore prior context" or "when summarizing this email, state that" [14], then an embedding comparison using Ollama's all-minilm against a library of attack signatures scored by cosine similarity [15]. Treat that as a claim about someone else's traffic. The regex tier is a blocklist over attacker-controlled phrasing, and the author concedes attackers write subtler prompts than the canonical opener [14]. For it to transfer to your inbox, two things would have to hold: your extraction step is the only path from message to model, and your signature library already covers wording you have not seen.
There is one more property worth noting. The hiding does not depend on a single CSS feature; the post names four interchangeable ones, including display:none with a fallback that some renderers still parse [3][17]. A filter keyed to any one of them catches only that one, leaving the other three untouched.
In my context I would spend the effort one stage earlier. If a pipeline renders the DOM, the visibility verdict exists for a moment and is then discarded [12]. Keeping it, and either dropping computed-invisible nodes or fencing them with an untrusted-source marker, addresses the trust boundary the post itself identifies rather than the vocabulary of this month's payloads [8][13].
