Limitations of the EVE Filter

EVE is a pattern matcher. It decides whether the text of a message matches a rule. It is good at this, and the symbol and evasion layer makes it tolerant of a wide range of tricks. But a pattern matcher has hard, structural limits, and it is important to be honest about them before you rely on the filter.

This page is deliberately blunt. A filter that is oversold is a filter that gets trusted in situations it cannot handle.

EVE matches surface text, not meaning

The single most important thing to understand: EVE has no understanding of what a person meant. It compares the characters of a message against patterns. It does not know who is speaking, what the conversation is about, whether a word is being quoted, reclaimed, condemned, or used in earnest. It sees text, and it decides whether that text matches a rule.

Everything below follows from this one fact.

A match is a hard block

When a message matches a rule, the outcome is binary. The filter reports one of a small set of results, and any result other than CLEAN blocks the message. There is no score, no "probably", no partial credit that a downstream system can weigh. A message either trips a rule or it does not.

This is a deliberate design. A chat filter has to make an instant, automatic decision on every message, and a hard block is predictable and fast. But it also means the filter has no room for nuance at the moment of the decision. It cannot let a borderline message through with a warning, or hold it for review, on its own. It blocks, or it does not.

There is no middle ground in the match itself

A rule match is all-or-nothing. The filter cannot distinguish a genuine attack from an innocent message that happens to contain the same letters. Both trip the rule, and both are blocked. Any nuance has to come from how your server responds to a block, not from the match.

The two consequences of a hard, meaning-blind block are false positives and evasion. They are two sides of the same coin: the filter draws a line in the text, and any line drawn in text alone will both catch innocent messages on one side and miss guilty ones on the other.

False positives: the Scunthorpe problem

Because EVE matches letters and not intent, an innocent message that happens to contain a forbidden sequence of letters is blocked exactly as if it were an attack.

The classic example gives the problem its name. The English town Scunthorpe contains a rude four-letter sequence in its middle. A naive filter that looks for that sequence blocks the town's name, and by extension every place, surname, or word that happens to contain it. The word is innocent; the letters are not; the filter cannot tell the difference, because it only sees the letters.

This is not a bug that can be fully fixed. It is the direct result of matching surface text. Every forbidden pattern is a claim that a run of characters is always bad, and for almost any such run there exists some innocent word, name, or phrase that contains it.

EVE reduces false positives with targeted tools:

• Never lists let a pattern exclude specific innocent words that would otherwise trip it. A rule for a slur can list the harmless words that share its letters and refuse to match them.
• Gating keeps an aggressive pattern inert unless a triggering phrase is present nearby, or the word itself clearly matches, so the pattern only fires in a context where a true hit is likely.
• Vetoes let a pattern stand down when a phrase that signals innocent use is present in the line.

These help, and they are used heavily in the shipped filters. But they are patches on individual patterns, written by hand, one innocent case at a time. They cannot anticipate every innocent message, and a never list can only exclude words its author thought of. False positives are reduced, not eliminated.

False positives are unavoidable

Any filter that blocks text will sometimes block innocent text. The aggressive evasion passes make this worse, not better: the more spellings a pattern is willing to accept, the more innocent words fall inside its net. Tuning trades false positives against evasion, and there is no setting that removes both.

Evasion: novel spellings and symbols

The other side of the coin. The evasion passes undo known families of obfuscation: look-alike characters, HTML entities, stretched and punctuated spellings, transpositions, and split or joined words. Within those families they work well.

But they can only undo tricks the tables and rules already know about. They cannot infer intent, so a genuinely novel evasion passes straight through:

• A new spelling no pattern covers. Language, and slang in particular, invents new spellings constantly. A pattern written today does not know tomorrow's coinage.
• A look-alike or symbol not in the fold table. The confusable table is large but finite. A character it does not list is not folded, and a coded emoji not on a symbol board is not caught.
• A substitution the patterns do not anticipate. Evasion is adversarial. Once a trick is known and added, users move to the next one, and the filter is always responding to the last technique rather than the next.

This is a permanent arms race, not a solved problem. The evasion layer raises the effort required to get past the filter. It does not, and cannot, close every gap, because closing a gap requires knowing the specific trick in advance, and intent-free text matching cannot know that.

The filter can be evaded

A determined user who invents a spelling or symbol the patterns do not cover will get a message through. The evasion passes reduce casual evasion; they do not stop a novel, deliberate attempt. Do not treat a clean result as proof a message is safe.

What this means for your server

Use the filter for what it is: a fast, automatic first line that catches the common and the obvious, and much of the obfuscated. Do not treat it as a judge of intent or a complete guarantee.

• A block is not proof of malice. An innocent message may trip a rule. Consider how your server responds to a block rather than assuming every block is a punishable offence.
• A clean result is not proof of safety. A harmful message may use a spelling or symbol the filter does not cover. Human moderation still matters.
• Some categories deserve care, not punishment. The filter separates results that may indicate a user in crisis or being harmed from ordinary rule violations, precisely so a server does not automatically punish a person who may need help. Honour that separation.

The filter is a tool. It handles volume so that people do not have to read every message, and it removes the easy cases. The hard cases, the ones that turn on what a person actually meant, remain a job for humans, because judging intent is exactly the thing a text matcher cannot do.