ShieldFont: Bludgeoning AI Scrapers That Disrespect Robots.txt

August 14, 2026 by Maya Posch 56 Comments

In the more innocent days of the World Wide Web you could simply put a robots.txt file in the root of your website that search engine indexing bots and similar would consult for the indexing wishes of the site owner. In this brave new world of LLM training data indexing such pleasantries are however rarely respected, leaving site owners to resort to increasingly more involved ways to bludgeon so-called AI scrapers, with ShieldFont being one of the most recent methods.

Its basic functioning is detailed in the white paper, explaining their use of ligatures. These are normally used to join multiple graphemes or letters into a single glyph which are rendered in the final text. By substituting about a quarter of the words in a text with such ligature-based versions in an intelligent, dictionary-based manner, the HTML version – as typically parsed by a scraper – will read as grammatically valid but nonsensical text, while the rendered font version will look normal.

Naturally, there are some disadvantages to this, such as screen readers for the visually impaired needing to also use the rendered font version, and it’s just as effective on legitimate search engine indexing bots. That said, if you apply this to static, archived content, or content marked as ‘do not follow’ in said robots.txt, then it might just be one way to make ChatGPT and friends spit out really funny output in the future now that the novelty of wood glue on pizza and eating rocks has somewhat worn off.

While LLM scrapers can adapt to this by also parsing the rendered text, this makes the scraping effort significantly more expensive. Together with maze traps like Nepenthes and Cloudflare’s offerings that seek to keep these scrapers busy scraping dynamically generated content through infinite linked pages, the tools available to combat the menace of these scrapers keep developing.

Removing Microplastics From Soil With Tumbling Magnetic Flakes

August 13, 2026 by Maya Posch 12 Comments

While in aquatic environments microplastics can be filtered out relatively easily, in soil it’s much harder to get to these microscopic particles. While you can certainly strip mine an entire area to process its soil, a less invasive method would involve something like the magnetic flakes proposed and demonstrated by [Jeonghyo Kim] et al. in a recent article in npg asia materials.

The Ti₃C₂T_x flakes, referred to as MXene microparticles, were designed to attract target microplastics. These were then combined with ferromagnetic nickel nanoparticles to make structures that can be propelled through soil using an external magnetic field.

During tests under laboratory conditions the researchers managed to remove about 81% of polystyrene and 72% of PET particles this way from soil, with a correspondingly higher percentage in water. After having the flakes rummage about for a while through the target material, they are removed with a strong magnetic field, which should recover most of them.

Naturally, the question with any such system is how it’ll perform once exposed to real world conditions and its myriad of soil types and conditions.

The Chernobyl NPP And Forty Years Of Robots For High Radiation Environments

August 13, 2026 by Maya Posch 17 Comments

With the massive steam explosion that shredded the #4 RBMK reactor at the Chernobyl Nuclear Power Plant in 1986 it suddenly made robots that could survive a high ionizing radiation environment into the hottest item on the planet. Over the course of forty years many generations of such robots were developed, tested, improved upon or discarded, all to explore and handle hazardous waste throughout the depths of the #4 reactor’s remains.

Researchers of the ISP NPP next to one of the TR robots. (Credit: ISP NPP)

Even if the entire development and decisions here would easily fit a couple of feature length movies, the recent documentary by the [Chornobyl Family] provides a solid overview of the engineering challenges, the issues encountered along the way and the forced evolution of initially very basic designs into the robotics that today trundle and wriggle around inside reactor #4, as well as their cousins over at the couple of stricken reactors at Japan’s Fukushima Daiichi power station.

Unlike the other robots developed from 1986 onwards to provide general clean-up of scattered core material outside of the core, these robots had to venture deep inside, where radiation levels were the highest and correspondingly the challenges much more severe. This was such a problem that initially it were humans who did the exploration, as robots proved to be too fragile and too prone to getting stuck.

Until the 1990s exploration of the ruined core was quite limited, also because of a lack of urgency. While the outside clean-up and construction of the sarcophagus had to be done as quickly as possible, the core exploration was more slow and methodical, based around trying to establish its condition, what core material remained inside and try to take samples of interesting objects like the well-known ‘elephant’s foot’.

Continue reading “The Chernobyl NPP And Forty Years Of Robots For High Radiation Environments” →

The Agony Of Packaging Linux Apps

August 12, 2026 by Maya Posch 61 Comments

One of the great things of Linux as an ecosystem is that there is so much choice. Yet this is also its greatest weakness, as unlike on MacOS and Windows this means that simple questions often do not have a simple answer. The topic of distributing software is one of these vexing topics that never really goes away, with [Noam Lewis], as author of the Fresh editor, recently expressing their frustrations on this topic.

This is a familiar topic that we have covered before, mostly in the context of cross-platform installers. Whereas on MacOS and Windows you just pick any of a handful of standard installer frameworks that do roughly the same thing, on Linux you are dealing with a dizzying number of package managers, including distro-specific ones, NPM, Homebrew, Rust crates, third party repositories like Arch Linux’s AUR or stray APT repositories for Debian, and of course AppImage and Flatpak along with a host of other options.

After going through the entire list with help from the Fresh community, [Noam] ended up creating packages for all of them, and has a lot of thoughts. Since Fresh is a TUI-based editor, something like Flatpack is not a really good fit, while AppImage is just very slow due to mounting the image, which is annoying.

Overall, distro-specific solutions are just unpleasant in general, as they mean repeating the same work over and over, even if you can even get into a distribution channel. Ultimately the solution that [Noam] ended up at was to have a static binary with the musl runtime, along with an integrated updater, which is a solution that should be quite familiar for Windows users. Yet even if it fails some kind of purity test for certain Linux users, is it really a bad solution if it works for users of the software?

Read A USB Logitech Racing Wheel On An ESP32‑S3

August 12, 2026 by Maya Posch 5 Comments

Now that MCUs like the ESP32-S3 are quite capable computer systems including USB host functionality, it only makes sense that you can connect USB peripherals like Logitech racing wheels to them. Of course, these aren’t basic HID USB devices, so they require a bit of setup to make them start spitting out the data updates which we’re interested in. Making this process easy is the goal of the LogiWheelHost project for ESP32-S3 by [Joel Kometz].

This single-header library supports the G29, G923, G920, G27, G25, DFGT, Driving Force Pro wheels, building on top of the EspUsbHost project. As explained in the README, these racing wheels do not start streaming all updates to their controls once powered on, but boot into a restricted mode in which only neutral or combined-axis data is sent.

To change this you need to trigger the so-called native mode switch in which far more detailed information as well as updates on extended features like separate pedals, all buttons and the gear shifter become available. This is done by sending a HID output report to the USB device, which is easy enough.

In addition to handling this detail the library also provides an API using which obtaining and using these controller states in your own code should be quite easy. Presumably the library will work on or can be ported to other ESP32 MCUs that support host USB mode, so this might be good news for anyone who is looking to do more with that old Logitech racing wheel.

Getting Back Into Resin Printing: First Results

August 12, 2026 by Maya Posch 21 Comments

When we last left off, I had just set up a new SLA resin printer and was on the verge of doing the initial round of printing to see just how resin printing in 2026 compares to way back in 2020. Surely SLA printing had to be easier and less fussy than it was in 2020?

During these weeks of printing, setting up printers and taking a gander at the various workflows that certain printers and their manufacturers try to push you into I have both produced a series of not too shabby prints and some delightful spaghetti. I also flipped a few proverbial tables and formed some strong opinions on 3D printing workflows, of which some can considered to be family-friendly.

Without further ado, let’s get into some updates, a bit of ranting, and even some printing results.

Continue reading “Getting Back Into Resin Printing: First Results” →

Lighting 3D Printed Parts On Fire For Science

August 12, 2026 by Maya Posch 10 Comments

Although lighting 3D prints on fire is rarely the intended outcome, it’s possible that said print will at some point in its future come into contact with either an open flame or a significant source of heat. Once that happens, what will be the result and how worried should one be? This is basically the excuse behind [Maker’s Muse] recent decision to light some 3D prints on fire.

Crispy 3D printed combat robot. (Credit: NHRL)

Materials exposed to an open flame in this experiment included various types of PLA, PETG, ABS, ASA, TPU and PEBA. Since PLA filaments have a significant amount of carbon in them it’s little wonder that these burned quite readily, though an interesting difference was immediately visible between an Elegoo PLA+ test cone and a Prusa Galaxy Black PLA cone. The latter required a blow torch to properly ignite, after which it burned rather hot whilst melting, unlike the dirty yellow flame of the PLA+.

So-called ‘high temperature’ PLA (HTPLA) seems to actively resist burning, self-extinguishing after a blowtorch treatment. Just these few samples of PLA already gave very different results, with very likely the additives being the defining factor since pure PLA is easy to burn as a way to dispose of it somewhat cleanly.

Moving on, black PETG didn’t really want to ignite, while ABS and ASA absolutely love to burn with a sooty yellow flame. HIPS was also tested, burning in a similar sooty manner as well.

Of all the materials tested, TPU was the least flammable with even the blowtorch not able to start ignition and only melting the sample. Foam TPU did however burn the most aggressive, followed by ABS, ASA and HIPS. Overall PETG and regular TPU seem to be your best bet if you do not want your 3D print to turn into a happily burning candle and potentially a general fire hazard.

Continue reading “Lighting 3D Printed Parts On Fire For Science” →