Bug reporting doesn’t usually have a lot of visuals. Not so with the visionOS bug [Ryan Pickren] found, which fills a user’s area with screeching bats after visiting a malicious website. Even better, closing the browser doesn’t get rid of them! Better still? Doesn’t need to be bats, it could be spiders. Fun!

The bug has been fixed, but here’s how it worked: the Safari browser build for visionOS allowed a malicious website to fill the user’s 3D space with animated objects without interaction or permission. The code to trigger this is remarkably succinct, and is actually a new twist on an old feature: Apple AR Quick Look, an HTML-based feature for rendering 3D augmented reality content in Safari.

Leveraging this old feature is what lets an untrusted website launch an arbitrary number of animated 3D objects — complete with sound — into a user’s virtual space without any interaction from the user whatsoever. The icing on the cake is that Quick Look is a separate process, so closing Safari doesn’t get rid of the pests.

Providing immersive 3D via a web browser is a valuable way to deliver interactive content on both desktops and VR headsets; a good example is the fantastic virtual BBC Micro which uses WebXR. But on the Apple Vision Pro the user is always involved and there are privacy boundaries that corral such content. Things being launched into a user’s space in an interaction-free way is certainly not intended behavior.

The final interesting bit about this bug (or loophole) was that in a way, it defied easy classification and highlights a new sort of issue. While it seems obvious from a user experience and interface perspective that a random website spawning screeching crawlies into one’s personal space is not ideal, is this a denial-of-service issue? A privilege escalation that technically isn’t? It’s certainly unexpected behavior, but that doesn’t really capture the potential psychological impact such bugs can have. Perhaps the invasion of personal space and user boundaries will become a quantifiable aspect of bugs in these new platforms. What fun.

When a ransomware attack targets something like a hospital, it quickly becomes a high-profile event that understandably results in public outrage. Hospitals are supposed to be backstops for society, a place to go when it all goes wrong, and paralyzing their operations for monetary gain by taking over their information systems is just beyond the pale. Tactically, though, it makes sense; their unique position in society seems to make it more likely that they’ll pay up.

Which is why the ongoing cyberattack against car dealerships is a little perplexing — can you think of a less sympathetic victim apart from perhaps the Internal Revenue Service? Then again, we’re not in the ransomware business, so maybe this attack makes good financial sense. And really, judging by the business model of the primary target of these attacks, a company called CDK Global, it was probably a smart move. We had no idea that there was such a thing as a “Dealer Management System” that takes care of everything from financing to service, and that shutting down one company’s system could cripple an entire industry, but there it is.

Water may seem like the enemy for anyone who gets in trouble while swimming, but it’s really time that they’re fighting. Even a strong swimmer can quickly become exhausted fighting wind and waves; add in the hypothermia that’ll eventually set in even in water as warm as a bath, and the difference between life and death can come down to seconds. Getting help to a floundering swimmer isn’t easy, though, as lifeguards can only swim so fast.

But a new remotely operated rescue boat aims to change that, by getting to someone in trouble as fast as possible. Named EMILY, for “Emergency Integrated Lifesaving Lanyard,” the unit is a compact electrically powered rescue boat that can be rapidly deployed by lifeguards, who remotely pilot it to the victim. The boat’s deck is covered with what looks like survival gear, most of which would probably be of more use to the lifeguard upon their arrival than to the swimmer, who would likely just use the boat for flotation. As such, this makes way more sense than sending a drone out there, which at best could only drop a life ring. At $12,000 a piece, these boats aren’t cheap, but for the families who lost their kids in 2022 who donated them, they probably seem like quite a bargain. Here’s hoping they pay off.

We can’t be sure, but we’ve got a vague memory of playing a game called Lunar Landing way back in the day. It would likely have been on a TRS-80 in our local Radio Shack store, and if memory serves, we never got particularly good at the text-based simulator. Happily, though, we can now at least attempt to foist our lack of skills off on a 55-year-old bug in the software. Recently discovered by the excellently named Martin C. Martin while trying to optimize the fuel burn schedule to land softly with the most fuel remaining — the key to a high score, as we recall — the bug makes it so a tiny change in burn rate gives wildly different results. The post-mortem of his search and the analysis of the code, written by high school student Jim Storer only months after the real moon landing in 1969, is very interesting. We especially appreciated the insights into how Storer wrote it, revealed via personal communications. It’s a great look at a piece of computer history, and hats off to both Storer and Martin — although we haven’t seen a CVE posted for this yet.

We know that Minitel terminals are highly collectible, but this is ridiculous. Granted, the Minitel occupies a unique place in computer history, and the boxy design of the original CRT and keyboard terminal was not without its charms. But this particular terminal seems to have had a Very Bad Day in the recent past and is now on the chopping block for a mere €430. To be fair, the eBay user in France has listed the Dalí-esque Minitel as an objet d’art; at that price, we’d like to at least get some usable parts from it to fix other terminals, but that doesn’t seem likely. Somebody will probably buy it, though — no accounting for taste.

And finally, AnimaGraffs is back, this time with a deep dive into the Bell 407 helicopter. We’ve been big fans of his work for a while and have featured a few of his videos in this space, including his look inside the SR-71 Blackbird spy plane. The new video is richly detailed and includes not only the engineering that goes into rotorcraft but also the physics that makes them work and makes them so challenging to fly. Enjoy!

The Altoids tin has long been the enclosure of choice for those seeking to show off their miniaturization chops. This is especially true for amateur radio homebrewers — you really have to know what you’re doing to stuff a complete radio in a tiny tin. But when you can build an entire 80-meter transceiver in a matchbox, that’s a whole other level of DIY prowess.

It’s no surprise that this one comes to us from [Helge Fykse (LA6NCA)], who has used the aforementioned Altoids tin to build an impressive range of “spy radios” in both vacuum tube and solid-state versions. He wisely chose solid-state for the matchbox version of the transceiver, using just three transistors and a dual op-amp in a DIP-8 package. There’s also an RF mixer in an SMD package; [Helge] doesn’t specify the parts, but it looks like it might be from Mini-Circuits. Everything is mounted dead bug style on tiny pieces of copper-clad board that get soldered to a board just the right size to fit in a matchbox.

A 9 volt battery, riding in a separate matchbox, powers the rig. As do the earbud and tiny Morse key. That doesn’t detract from the build at all, and neither does the fact that the half-wave dipole antenna is disguised as a roll of fishing line. [Helge]’s demo of the radio is impressive too. The antenna is set up very low to the ground to take advantage of near vertical incidence skywave (NVIS) propagation, which tends to direct signals straight up into the ionosphere and scatter them almost directly back down. This allows for medium-range contacts like [Helge]’s 239 km contact in the video below.

Banging out Morse with no sidetone was a challenge, but it’s a small price to pay for such a cool build. We’re not sure how much smaller [Helge] can go, but we’re eager to see him try.

Let’s face it — electronics are hard. Difficult concepts, tiny parts, inscrutable datasheets, and a hundred other factors make it easy to screw up in new and exciting ways. Sometimes the Magic Smoke is released, but more often things just don’t work even though they absolutely should, and no amount of banging your head on the bench seems to change things.

It’s at times like this that one questions their sanity, as [Gili Yankovitch] probably did when he discovered that not all CH32V003s are created equal. In an attempt to recreate the Linux-on-a-microcontroller project, [Gili] decided to go with the A4M6 variant of the dirt-cheap RISC-V microcontroller. This variant lives in a SOP16 package, which makes soldering a bit easier than either of the 20-pin versions, which come in either QFN or TSSOP packages.

Wisely checking the datasheet before proceeding, [Gili] was surprised and alarmed that the clock line for the SPI interface didn’t appear to be bonded out to a pin. Not believing his eyes, he turned to the ultimate source of truth and knowledge, where pretty much everyone came to the same conclusion: the vendor done screwed up.

Now, is this a bug, or is this a feature? Opinions will vary, of course. We assume that the company will claim it’s intentional to provide only two of the three pins needed to support a critical interface, while every end user who gets tripped up by this will certainly consider it a mistake. But forewarned is forearmed, as they say, and hats off to [Gili] for taking one for the team and letting the community know.

Any reader who has bought a TV in recent years will know that it’s now almost impossible to buy one that’s just a TV. Instead they are all “smart” TVs, with an on-board computer running a custom OS with a pile of streaming apps installed. It fits an age in which linear broadcast TV is looking increasingly archaic, but it brings with it a host of new challenges.

Normally you’d expect us to launch into a story of privacy invasion from a TV manufacturer at this point, but instead we’ve got [Priscilla]’s experience, in which her HiSense Android TV executed a denial of service on the computers on her network.

The root of the problem appears to be the TV running continuous network discovery attempts using random UUIDs, which when happening every few minutes for a year or more, overloads the key caches on other networked machines. The PC which brought the problem to light was a Windows machine, which leaves us sincerely hoping that our Linux boxen might be immune.

It’s fair to place this story more under the heading of bugs than of malicious intent, but even so it’s something that should never have made it to production. The linked story advises nobody to buy a HiSense TV, but to that we’d have to doubt that other manufactures wouldn’t be similarly affected.

Header: William Hook, CC-BY-SA 2.0.

Thanks [Concretedog] for the tip.