I read through the white paper and I have further concerns even for any readers who are comfortable fucking over blind people (for the record: fuck you if you're reading this). It looks like this works off of the same kind of technique that allows fonts to render digraphs, positional forms, and emoji, leveraging the font rendering to allow it to jumble up the actual HTML that machines interact with. It's clever, but the fucking with screen readers, form autofill, and basically anything other than direct text rendering is really obvious.

I'm also not sure when it runs to generate the dictionary of mappings. The6biggest harm of the content scrapers isn't that it's ingesting the content it's that the repeated requests spam servers and basically DOS smaller sites out of existence. This is why iocaine is so brilliant and imo remains the gold standard. If the dictionary is generated when the files ar uploaded to the server or set to be displayed then this merely fails to address the real problem, but if the expectation is that this mapping gets created and distributed at request time then that just makes scraping even more expensive for hosts. Given that it works on dynamic text in their example it looks like at least part of the mapping runs on the client, so it's increasing the size of the package if nothing else. Bandwidth may be pretty cheap these days, but that's no reason to be wasteful.