evnp

On mobile I see the blog momentarily, then the whole thing redirects to a sketchy looking url a la rm358.com, with a fulscreen video takeover. Fyi to author, I'd like to read but it's currently unusable

> When the AI doesn’t know the ‘why’ part, it comes up with its own reasoning. I find that dangerous. When we read that later, it may not make sense, because the real reason was completely different.

Even more dangerous: when the text _does_ make sense, despite being detached from reality.

The second half of this post chronicles the author's Herculean efforts to make everything work well in the cases you describe.

> One of the big things that blocked this shipping for so long was not having an escape hatch of some kind to allow clients that disable WebAssembly by policy to get through the gate. [...] This combination of factors means that there would need to be another implementation of the proof of work code in JavaScript that would actually execute the number crunching.

Be proud of the theme. It emanates unflashy nostalgia to me, like a mysterious text-adventure game you discover as a kid. I'm all for putting weight in accessibility as a goal, but never as the all-over riding goal, and always with the greater purpose of the work in mind. It brings to mind an a11y evaluation a recent company I was a part of had done by a 3rd party, where one of the resulting "guidelines" was to darken borders around all our inputs and buttons for better contrast. These had the effect of decimating the visual texture and readability of each page, as you were caught up in a sea of near-black borders on light background. But the design team felt it was a worthy tradeoff, can't say no to accessibility. In other words, for a personal blog, I'd say do what brings you joy first and foremost. It's hard enough doing work you end up feeling proud of.

On shieldfont, I feel like many posts in this thread are glossing over the point that most scraping operations are operating at scale, and all we have to do is make a piece of content (or many pieces) too expensive to scrape _at that scale_. It's not really about whether AI scrapers could or could not mimic a screen reader well enough in an individual case.

So, require an expensive-enough computation to access the true text, similar to the anti-DDOS measures that gate many full webpages today (admittedly, I'm not well-versed in how these affect scrapers). As annoying as these pages may be - or extra button clicks to "reveal" true text to a screen reader - this seems like a very pro-human space to explore, since it's one mechanism that can affect bots greatly and us individual viewers relatively little.

Isn't this the same sort of cost CloudFlare and anime catgirls are making us pay daily? Only enough to deter bots, or "a few seconds processing."

I take your point that one extra click/interaction required for screen readers only is objectively more friction, but it's only by exploring these technologies instead of dismissing them that we'll arrive at UX solutions truly work for people of all stripes (and ideally, not for bots, scrapers, and the like). I think if you're applying a tool like this you already have very different priorities than fueling Google.

Thanks for introducing me to shieldfont.org! It's the first of these I've seen that feels designed to be more than a visual experiment, reading through their landing page is interesting. In particular, their section on accessibility seems to contradict this post's opening premise:

> Screen readers get the real words. A screen reader reading down the page is never handed scrambled text, and our NVDA test asserts exactly that. Screen review and touch exploration are untested. ShieldFont hides shielded passages from accessibility tools by default with aria-hidden="true", because a decoy read aloud is fluent, grammatical, wrong English, and that is worse than silence.

> The real words remain sealed in the same page, and a visible notice above the block carries the control that uncovers them. It is on by default and reachable by mouse, keyboard and screen reader alike. Pressing it sets the reader’s browser to solving a compute-heavy puzzle: JavaScript and a few seconds of processing, more than most mass scrapers are willing to spend. That puts the words within reach of a screen reader, a translator and copy/paste.

I'd love to hear your thoughts on that. Also just aside, love this TUI-esque blog design and color palette (maybe a bearblog theme? still worth an upvote)

"There will be no curiosity, no enjoyment of the process of life. All competing pleasures will be destroyed. But always— do not forget this, Winston— always there will be the intoxication of power, constantly increasing and constantly growing subtler. Always, at every moment, there will be the thrill of victory, the sensation of trampling on an enemy who is helpless. If you want a picture of the future, imagine a boot stamping on a human face— forever."

George Orwell, 1984

Any chance you'd be interested in sharing the story?

There it is. Thanks!

Is there an xyz's law for this yet? Will add - lines of code (as long as you don't believe code is the product/output).

The point is that safety depends on context and intent being known - with unknown context or intent, dangerous situations will appear _some_ of the time, thus the system as a whole can "never" be fully safe.

There is no contradiction here.