170 Hacker News points for a blog post that says: stop trying to DRM your paragraphs.
On August 12, 2026, developer Andrew Yaros published Anti-AI fonts are useless and harmful — a critique of obfuscation typefaces marketed to block LLM scrapers. By August 21, the piece had ~170 points and 128 comments on HN, with the thread splitting along a familiar line: creators who want to raise the cost of ingestion versus engineers who say the cost gets exported to screen readers, search engines, and copy/paste — permanently for humans, temporarily for bots.
explainx.ai's read: Yaros is directionally right about accessibility and the plaintext web, even if the tone on HN occasionally swung fatalistic. Anti-AI fonts are security theater with a11y collateral damage — closer to Macrovision for blog posts than to encryption. The constructive half of the debate is what actually changes incentives: provenance and watermarking, law, paywalls, and hosting economics — not fonts that make your own site harder to read.
TL;DR — what people are asking
| Question | Answer |
|---|---|
| What triggered this? | Yaros critiquing Decoy, Shield, and Ghost-style anti-AI fonts |
| Core claim | You cannot obfuscate for bots without breaking assistive tech or posting the decode key |
| ShieldFont counter | Real words hidden from scrapers; aria-hidden decoys; "uncover" puzzle for a11y |
| HN pushback on Shield | Uncover button = key shipped with cipher; search indexes decoy text → SEO black hole |
| Do fonts block AI today? | Briefly at best — Unicode tricks, OCR, and multimodal models bypass most demos |
| Yaros baseline | Public information will be parsed by anything allowed to access it — plan accordingly |
| Better alternatives? | Legal/remedy paths, rate limits, paywalls, C2PA/watermarks — not glyph DRM |
What anti-AI fonts try to do
The August 2026 wave includes several demos Yaros names explicitly:
| Project | Mechanism (as described publicly) |
|---|---|
| Decoy font | Display text that misleads automated readers |
| Shield font (shieldfont.org) | Decoy passage for scrapers; real words sealed until client-side "uncover" |
| Ghost font | Obfuscated rendering intended to hide plaintext from parsers |
Related experiments go further — Tritium Legal's NoRoboto (cited on HN) uses on-the-fly rendered fonts with fake Unicode mappings; others use custom ligatures so copy/paste returns garbage while the screen looks fine.
The stated goal is rarely "stop all AI forever." Most proponents want to raise scraping cost — force headless Chrome, OCR, or per-site reverse engineering — so bulk training runs become uneconomic. HN commenter palmotea made that case explicitly: not encryption, but tax.
Yaros's response: a tax on scrapers is still a tax on the open web, and the people who pay first are not the frontier labs.
Yaros's accessibility argument (the strong part)
Yaros's opening is blunt:
Making "anti-ai" fonts that obfuscate or scramble text is a fool's errand. For fonts that scramble text, it's an accessibility problem, since the scrambled text is what screen readers and other accessibility tools will parse.
That matches how the DOM actually works. Assistive technologies consume structured text — not your aesthetic intent. If the accessible tree contains decoys, NVDA/VoiceOver read the decoys. If real words live behind a JavaScript puzzle, Reader Mode, translators, and copy/paste break until someone solves it.
Yaros goes one step further into policy: any scheme that restores accessibility via selective metadata drifts toward identity verification — "prove you're disabled to get the real document" — which he rejects as a road nobody should build.
HN's danudey sharpened the trade:
You are removing accessibility for humans permanently in exchange for removing accessibility for scrapers temporarily.
The Spore DRM analogy recurred: legitimate players locked out; pirates unaffected. Here, humans using assistive tech are the legitimate players.
ShieldFont's rebuttal — and why HN remained skeptical
ShieldFont is the most developed counter-example in the thread. Their public copy claims:
- Screen readers are not fed scrambled decoys by default — decoys sit behind
aria-hidden="true" - Real words stay in-page; an "uncover" control (default on) runs a compute-heavy client puzzle before plaintext is exposed to assistive tools
HN commenter evnp asked Yaros to engage with that design. kstenerud answered the technical objection:
As soon as you need to put a "decode" button for accessibility functions to work, you're effectively posting the key along with the cipher.
SideQuark compressed it further: "Claude: make the scraper mimic a screen reader."
Other practical hits on ShieldFont's demo:
- Live demo warns screen-reader users to uncover text first — an extra step other visitors don't need
- Search engines index decoy text → organic discovery collapses unless you already live on social traffic only
- Copy is blocked until uncover — friction for researchers, journalists, and your own future self
ShieldFont may be more thoughtful than a TikTok demo, but it still lives in the same category: conditional access to plaintext on a medium that won because plaintext was unconditional.
Why the cat-and-mouse framing isn't fatalism — but fonts still lose
Yaros warns that every public obfuscation demo becomes a free benchmark for multimodal training — the same dynamic that killed text CAPTCHAs and made Nightshade-style image perturbations controversial among researchers.
Counter-arguments on HN:
- Cybersecurity is permanently adversarial — raising cost still matters even without a permanent win
- Per-site font generation could explode circumvention catalogs
Both can be true and Yaros can still be right about fonts specifically:
- Humans-readable ⇒ machine-parseable if you spend enough compute — OCR from screenshots is already trivial to route through an LLM
- HTML text obfuscation is weaker still — scrapers read codepoints, not glyphs
- Accessibility unlock paths become the scraper's favorite entry point
Compare to AI watermarking: also imperfect, also adversarial — but aimed at attribution and detection, not making your article illegible to a blind reader. Watermarks don't require a sighted human to perform a puzzle before quoting you.
Who wants these fonts — and why the anger is real
Dismiss the category as performance art and you miss the fuel. HN repeatedly named fanfiction writers, indie artists, and small publishers who see uncompensated ingestion as an existential threat — the "largest IP infringement in history" thread kokanee referenced.
That grievance is legitimate policy terrain. Yaros isn't denying it; he's denying this tool class:
Like it or not, all publicly available information will inevitably become accessible to anyone and anything that has permission to access it. This is the baseline scenario people need to plan around.
If your content must not train models, the honest options are not public — paywalls, contracts, private communities — or legal/remedy frameworks, not typography that punishes readers.
What to do instead (builder-facing)
- Decide publication tier. Public HTML is a training candidate. Sensitive drafts belong off the public web, not behind a clever font.
- Use robots.txt and rate limits knowing they are polite requests, not security — still worth doing for well-behaved crawlers.
- Invest in provenance, not obfuscation. If you care about attribution, track C2PA and watermark debates — a separate problem from blocking ingestion.
- Never ship readability DRM on primary content. If you experiment, provide a parallel accessible plaintext route — not "email us to prove you're disabled."
- Pressure policy, not pixels. Scraping at scale is increasingly legal and platform politics — EU AI Act, publisher deals, opt-out registries — where marginal returns beat font ligature arms races.
- Detect slop downstream. Readers already adapt by trusting named sources — the same dynamic as AI-generated text tells and Claudish fatigue in tooling threads.
The irony HN couldn't ignore
Yaros's site uses a deliberately retro terminal aesthetic — low-contrast monospace, CRT flicker — which commenters flagged as its own readability tax. Yaros (and fans) treat that as stylistic choice, not anti-bot security.
The distinction matters: aesthetic friction vs security theater that blocks assistive tech. One annoys sighted developers who chose to visit; the other structurally excludes people who rely on screen readers because you wanted to confuse a bot.
Summary
Andrew Yaros's anti-AI font critique landed on HN because it names the Spore DRM shape of the category: humans pay forever, scrapers pay until the next model update. Projects like ShieldFont try to route around that with aria-hidden decoys and uncover puzzles, but the thread's best technical replies still reduce to "simulate a screen reader" and index the wrong text.
For explainx.ai readers building in public: treat obfuscation fonts as benchmark fodder, not infrastructure. Plan for public text being ingested, push provenance and law where you need leverage, and keep the plaintext, accessible web as the default — not because bots deserve your words, but because humans still do.
Related on explainx.ai
- How AI text watermarking works
- The case for AI watermarks (provenance, not obfuscation)
- Anthropic Claude invisible watermarks and C2PA
- Is removing an AI watermark illegal?
- Top 10 signs of AI-generated text
- Vomit — when Claude output is unreadable, rewrite locally
Sources: Andrew Yaros — Anti-AI fonts are useless and harmful · ShieldFont · Tritium Legal — NoRoboto
Point counts, project descriptions, and ShieldFont behavior reflect public posts and the HN thread as of August 21, 2026. Verify current demos before adopting any anti-scraping typography on production sites.