- cross-posted to:
- technology@beehaw.org
- cross-posted to:
- technology@beehaw.org
Surely these types of tools are unneeded since all the big tech companies all definitely follow the law!
You must log in or register to comment.
Unfortunately this destroys accessibility and should not be used
It does work with screen readers but their solution seems far from ideal. Also, that relies on the fact that the scrappers don’t typically run JavaScript.
Screen readers (used, for example, by people with visual impairment) work from the source code, where your words are already swapped. The font only fixes things on screen, so a shielded block would be read aloud as fluent, wrong English. Shielded sections in our React tier carry aria-hidden to stop that. In its place, an opt-in beta ships the correct text encrypted in the page. A button only screen readers reach asks the reader’s browser to solve for the key: a chain of steps where each one needs the answer to the last. It also needs JavaScript, which most scrapers never run. The cost currently lands on the reader: up to twenty seconds on a slow device. That is friction, and it is the part we most want help fixing.
Go further down the rabbit hole.
Next step: after analyzing the bundle a scraper then runs as a narrator, capturing the audio and transcribing it for ingestion.
If this were ever to become widespread, I imagine the scrapers would just start pulling the css file to decrypt the text.
Pretty much, yeah. Unless each site owner creates a custom mapping.
The font must be sent to the browser so it can display the original words. Anyone who downloads it can therefore inspect it and work out the substitutions. That is unavoidable. But our goal is not to stop someone who deliberately targets a specific site. Instead, it is designed to disrupt large-scale automated scraping, which processes many sites without examining each one individually (because that costs money). ShieldFont currently ships with three different word mappings and gives publishers the tools to create their own, so decoding one mapping does not automatically reveal the others.
Here’s the project page
Excuse me but I don’t get how or why this works.
Can someone explain to me how does this work?
It’s explained in the article, with examples. Which specific aspect(s) of this explanation do you need help with?
Mostly about the glyph substitution.
I get that it takes some combination to replace them to words and make the text incoherent, but I don’t get how it’s configured or how the AI can’t get a coherent text. I would get it if it was OCR, but scrapping?
Apparently, and I hope someone will correct me if I’m wrong, the AI scrapers gather their data from the page source rather than from what we users see on the screen. The text in the page source when using this font will appear to be gibberish. When the font is applied, the glyph substitution occurring between the source and the browser, the text is transformed into the author’s intended verbiage for the user to read.
But more simple than that. If I’m not mistaken this is simply a font where A is mapped to P and B to V and so on. The fonts we use all are saved by the comp as character codes. Fonts are just a map of glyphs.
Wingdings is the mist famous and oldest case of a font where any letter typed comes out as something completely different.
So they have mapped a font where the letters are jumbled, and used the map with a script to encode the pages content to the same cypher. Loading the page with anything but the font that draws the intended letter instead of the letter that is verbatim on the page results in garbage.
Imagine if you converted a p to an l and a c, but used styling to make those two letters look like a p
Same idea… The actual letters on the page are wrong, but when they’re rendered back into pixels through the browser they look correct. OCR and humans would be able to read this fine, but AI tools usually fetch the raw page and strip out the unimportant bits to save tokens
