cyber-crime

Social engineering and malware combine to enable financial fraud before banks have time to act

A new social engineering and malware campaign targets Android users, stealing card details to make payments or withdraw cash. Group-IB discovered the campaign, calling it WindRelay, and found that several successful attacks were carried out on European victims within the space of a 13-minute phone call.

The attack relies on a skilled social engineer walking the victim through the process and two malware strains: An NFC relay malware called WindRelay, first discovered in August 2025, and SpyNote, a remote access trojan (RAT) that was leaked on cybercrime forums as far back as 2016.

It goes like this: The attacker calls the target while posing as a helpdesk employee at their bank, convincing the victim-in-waiting that there is a problem with their payment card.

While still on the phone, the attacker gets the target to install a version of SpyNote on their Android device. The file name includes the target’s name, which the researchers said could suggest that each target is singled out specifically, and a degree of reconnaissance has to be carried out prior to the attack.

Once installed, the attacker quickly uses the RAT’s remote access to quietly install WindRelay on the attacker’s device without their knowledge or input, all while the call was ongoing. 

The attacker then instructs the target to tap their payment card on their NFC-enabled smartphone and, when prompted, enter their PIN. 

WindRelay then captures the data from that interaction between the card’s chip and the reader, similarly to how genuine point-of-sale machines authorize contactless payments. This is known as a live EMV APDU exchange.

In order to fraudulently make payments using this data – without physical access to the payment card or the cardholder – the attacker must have a second device capable of using this data to authorize a payment. 

This could be a second Android smartphone capable of loading this data and transmitting it to an attacker-controlled POS terminal, which is linked to a fraudulent merchant bank account, or an ATM.

The attacker then uses the captured live exchange data to execute fraudulent charges on the victim’s card, authorized using the PIN they entered during the call.

Group-IB said in its write-up: “In effect, the victim’s card and the real terminal are still talking directly to each other – the fraudster’s setup is just an invisible relay in between, passing the exchange back and forth across a distance. 

“Because the terminal is genuinely completing a live handshake with a real card, the transaction goes through and processes the withdrawal or purchase as normal.”

Doubling down on their access, Group-IB also noted that the attackers in one instance used their RAT access to access the victim’s banking app and take out loans in their name.

The researchers also said they observed 23 WindRelay-related samples uploaded to VirusTotal between November 2025 and July 2026, with signs pointing toward targeting victims in Czechia, Slovakia, and Slovenia. 

They were not able to pin down the attacker(s) behind the malware, although they said it was independently developed and the samples they saw uploaded to VirusTotal all contained unique UI elements, such as the victim’s name, just like with the RAT.

“This suggests the threat actor behind these campaigns most likely has the capability to dynamically build malicious applications tailored to individual victims,” said Group-IB.

“This case shows that modern fraud rarely relies on one technique,” it added. “Here, the fraudster combined three capabilities in a single session – a live social engineering call, a personalized RAT for remote device control, and an NFC relay malware for physical cash-out. 

“The fraudster also used these capabilities to hit two separate payout channels – a digital loan and card-present purchases – before the bank or victim could react.”

The attack is similar to previous NFC relay-related campaigns, such as NGate in 2024 (and more recently in 2026), and Ghost Tap, the techniques involved in which closely align with WindRelay.

Ghost Tap, also discovered in 2024, relies on a Chinese malware sold throughout the country’s cybercrime Telegram communities, and according to Group-IB, it was responsible for losses exceeding $355,000 between November 2024 and August 2025 alone. ®

Security researchers have disclosed new “Plug and Pwn” attacks that abuse the Windows Plug and Play feature to trigger Windows into installing vulnerable or insecure vendor software and gain SYSTEM privileges.

The research, presented at DEF CON 34 by security researchers Alejandro Hernando and Borja Martínez, exploits how Windows automatically identifies new connected hardware, locates matching driver packages, and installs vendor software as the NT AUTHORITY\SYSTEM account.

By using software to emulate USB devices, the researchers found they could force Windows to install signed vendor packages containing exploitable components or weaknesses that can be abused to gain SYSTEM privileges.

Some of the demonstrated attacks require no user interaction or logged-in user, while another can be performed remotely over RDP without any physical USB hardware being connected to the targeted computer. plugandpwn.com.

Abusing Windows Plug and Play

Windows supports a feature called co-installers, which automatically downloads and installs vendor software and drivers when a new USB device is inserted into a computer.

In 2021, BleepingComputer reported on how this feature was abused along with a Razer Synapse vulnerability to give a standard Windows user SYSTEM privileges simply by plugging in a Razer mouse or keyboard.

When a Razer device was connected, Windows automatically downloaded and launched the Razer Synapse installer with SYSTEM privileges. A flaw in the installer allowed a standard user to launch PowerShell from the installation interface, causing the shell to inherit the installer’s privileges.

BleepingComputer tested the vulnerability at the time and confirmed that it could be used to gain SYSTEM privileges in approximately two minutes.

At the time, vulnerability analyst Will Dormann previously warned that similar vulnerabilities were likely present in other software automatically installed through Windows Plug and Play.

Hernando told BleepingComputer that Plug and Pwn belongs to the same family of attacks, but the new research focuses more on the Windows device installation path itself.

“The Razer bug is the same family. The difference is that we went after the install path itself instead of one vendor’s installer,” Hernando told BleepingComputer.

“Some of our chains need no clicks and no logged-on session, and one of them runs over RDP with no hardware at all.”

The researchers say the main issue is that when Windows detects new hardware, it may automatically retrieve an associated signed package and execute vendor-supplied components as SYSTEM.

This privileged installation path can include co-installers, services, support executables, and drivers, with no UAC prompt displayed by the operating system.

From fake USB devices to remote RDP attacks

The researchers told BleepingComputer that they used FaceDancer with Cynthion and GreatFET hardware connected to a small Linux computer to emulate USB devices.

FaceDancer is a software framework for emulating USB devices, allowing researchers to define the descriptors, interfaces, device classes, and endpoints that a computer uses to identify connected devices.

Connecting hardware running FaceDancer to a computer can make the operating system behave as though a specific USB device had been plugged in.

Using FaceDancer, the researchers could make their hardware appear to Windows as specific USB devices, causing the operating system to recognize the emulated hardware and locate and install the associated vendor driver packages.

Some attack chains also require the emulated device to disconnect and then reappear as a different device identity.

“Several of our chains depend on presenting the device as composite so Windows loads usbccgp.sys and enumerates each interface on its own, which is what makes it match the vendor package instead of the inbox driver,” Hernando explained to BleepingComputer.

“We also need to re-enumerate on demand, dropping the device and coming back as a different identity.”

In their zero-click physical demonstration, the researchers exploited behavior in Sierra Wireless and Sony FeliCa installation packages.

The attack first impersonates a Sierra Wireless device, causing Windows to install software that can be abused to change the computer’s DNS settings.

The researchers then impersonate a Sony FeliCa device, which causes Windows to install additional Sony software that downloads files over an unencrypted connection.

By controlling the system’s DNS settings, the researchers can redirect those downloads to a server they control and exploit a flaw in the Sony software to place a malicious file on the system with SYSTEM privileges.

Finally, they impersonate the Sierra device again, causing Windows to load the malicious file and allow the attackers to open a reverse shell with SYSTEM privileges.

The researchers demonstrated this chain against a fully updated Windows 11 computer with nobody logged in, saying the complete attack takes approximately five minutes.

When questioned if this attack can be conducted with small portable devices, Hernando said their research hardware is already portable enough to carry around and that a Raspberry Pi operating in USB gadget mode should theoretically be capable of conducting this attack as well.

However, he said the Flipper Zero cannot currently perform the FaceDancer attacks.

“Flipper Zero, no. There’s no FaceDancer backend for it and the framework won’t run on it,” Hernando said.

“Its BadUSB mode is fine for HID, but arbitrary composite descriptors and re-enumeration would be a firmware project.”

The researchers also demonstrated what they call “NoPlug & Pwn,” which requires no physical hardware emulation.

Instead, the attack abuses RDP USB redirection, a feature that allows USB devices attached to a user’s local computer to be available inside a remote Windows session.

Rather than redirecting an actual device, the researchers created a Python RDP client that sends specific USB descriptors over this USB redirection feature when connecting over RDP.

The remote Windows host then treats the fake descriptors as a legitimate USB device connected to the guest computer, creates the corresponding Plug and Play device on the host, causing the corresponding drivers and vendor software to be installed.

In the researchers’ demonstration, they impersonated an Intel RealSense camera whose Windows Update package contains a co-installer that can be abused through DLL hijacking to obtain SYSTEM privileges.

“The server’s USB hub driver enumerates our phantom device, and Windows PnP does exactly what it did in the physical demo: it matches the hardware ID and installs the driver, as SYSTEM,” the researchers explain on the Plug and Pwn site.

The RDP attack only works on systems where USB redirection is enabled, which Hernando says is common in virtual desktop environments.

Disabling co-installers helps, but does not stop Plug and Pwn

Will Dormann suggested that Windows administrators concerned about this type of attack can enable the ‘DisableCoInstallers’ registry value, which prevents driver packages from executing co-installers during device installation.

To do this, open the Registry Editor and navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Device Installer Registry key.

Under that key, add a DWORD-32 value named DisableCoInstallers and set it to 1, as shown below.

When BleepingComputer asked whether this would effectively block Plug and Pwn, Hernando said it would disrupt some of the demonstrated attacks, including the Sony FeliCa attack and the Intel RealSense RDP attack.

However, it does not eliminate the underlying attack surface.

“It helps, and it would break parts of what we showed,” Hernando told BleepingComputer.

“It doesn’t stop the class of attack, though. It leaves PnP enumeration, Windows Update resolution, driver staging, INF processing and INF-installed services untouched.”

The researchers illustrated this with another attack using Wacom and Atheros packages that exploits a vulnerability (CVE-2019-10617) in an Atheros driver service installed through an INF file rather than a co-installer.  

Hernando recommends that organizations with sensitive systems use ‘DisableCoInstallers’ along with additional device blocking.

“In anything sensitive I’d pair it with device installation restrictions or hardware-ID allow-lists, and turn off PnP device redirection on RDP and VDI hosts that don’t need it (`fDisablePNPRedir`),” Hernando told BleepingComputer.

The researchers have not reported all of the attack scenarios as new vulnerabilities to individual vendors, saying that many are not standalone security flaws and only become exploitable when combined with other functionality.

Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply.

The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments.

Advertisement

Get the report

Looking ahead: Sunlight has been used to generate entangled photon pairs, offering an early look at how quantum technology could reduce its reliance on power-intensive lasers. Researchers at the University of Ottawa and the Max Planck Institute for the Science of Light in Erlangen, Germany, used focused sunlight to produce entangled photons, which are essential to many photonic quantum computing and quantum communications systems.

The research, which was published in Optica, does not suggest that sunlight can replace laser-based quantum sources. Those systems remain more precise and produce stronger results. But the study shows that the light used to create entangled photons does not necessarily have to come from a laser, challenging the long-standing assumption that it does.

Entangled photons are pairs of light particles with linked quantum properties. Measuring one particle can reveal information about the corresponding measurement of the other, even when the two are separated. That behavior makes entangled photons useful for quantum encryption and other forms of quantum information processing.

Most systems generate these pairs through spontaneous parametric down-conversion. In that process, a laser shines through a special crystal, producing photons with correlated quantum properties. Researchers have favored lasers because they generate coherent light, meaning the waves maintain a consistent phase and typically operate within a narrow range of wavelengths.

Sunlight is not coherent. It contains many wavelengths and reaches Earth from different directions, making it seem like an unlikely candidate for generating entangled photons.

The Ottawa and Max Planck researchers had previously explored the question through theoretical work and experiments using light-emitting diodes. Their work suggested that incoherent light could generate entanglement if the relevant quantum property did not depend on the light’s wavelength or direction.

Experimental setup for generating polarization-entangled photon pairs with sunlight. The solar concentrator is at right; the photon source and electronics are housed in a light-blocking tent at left. Inset: The source’s optical components and avalanche photodiodes.

For the solar test, the researchers needed to concentrate sunlight tightly enough to direct it into a small crystal. Hanieh Fattahi’s team at the Max Planck Institute built a glass, cone-shaped concentrator that collected light from a window-sized Fresnel lens and funneled it into a thin optical fiber.

The team tested the system outdoors at the institute over three days. The resulting photon pairs achieved about 94% fidelity with a perfectly entangled state. The experiment also violated Bell’s inequality, a test that helps establish whether correlations between particles are genuinely quantum rather than explainable by classical physics.

The Bell violation was limited, which the researchers partly attributed to weak seasonal sunlight and passing clouds. The entanglement quality also did not match the best results from laser-driven systems. Cheng Li, who co-led the research as a graduate student at the University of Ottawa and is now at Lawrence Berkeley National Laboratory, said the shortfall was likely caused by distortions in the optical components rather than the nature of sunlight itself.

He called it a proof of principle.

The researchers are now working to improve the brightness of the source and the quality of the entanglement. A more capable system could eventually be used outside the laboratory, including in remote locations or on satellites.

That prospect is part of the technology’s appeal. Laser-based systems require electricity, stabilization, and cooling, while much of their energy is lost as heat. A source powered directly by sunlight could eliminate the electrical-to-optical conversion step.

Li said satellite systems could one day use the sunlight already available in orbit to produce quantum encryption keys. The idea remains far from deployment, but the experiment points to a different approach to building quantum infrastructure.

In these days of hundred-gigabyte-and-more monster games, it can be nice to stop and remember what a human can do with assembly language and very, very little storage space. In this case, only 3 KB — yes, three kilobytes — to play TinySol, a tiny solitaire game for DOS that’s compatible with the common CGA/EGA/VGA graphics modes. [ClassicBits] even fits the 640×400 AT&T 6300 mode that was used for some GRiD computers in that 3 KB.

The “full” version is actually 3.5 KB. That extra half kilobyte gets you the ability to load and save games, plus mouse support. The 3 KB version you must play through to the end using only the keyboard, but if you’re hitting this on the minimal-supported-hardware target of the IBM 5150, you probably don’t have a mouse. The smaller build can still score the game, auto-finish, congratulate you on a win, and even automatically detect the correct graphics mode for you. It can also be launched from a QR code, which [LGR] demonstrates in a video embedded below. Check it out for a play demo, but it’s Klondike Solitaire. If you don’t know what to expect by this point, you must not have used a PC in the last 30 years.

Even smaller versions of TinySol are available if you know you’re only going to need, say CGA, but even with 360 KB floppies we’re not sure we’d feel the need to save a kilobyte. If it doesn’t fit on the floppy, just print it onto the sleeve as a QR code, like [ClassicBits] did with the floppies he was giving away at Vintage Computer Festival Southwest 2026. Well, technically that’s the “Tiny” version on the QR code, but we have faith there’s some visual code that could hold the 3 KB “medium” game.

[ClassicBits] takes care to point out that his game is 100% human-written, which is something you cannot guarantee even for retro assembly-language products. We’ve already seen that Claude can code for the Z80, which means the 8088 won’t escape it either. Of course these old machines have a lot to recommend them if you want to escape modernity and learn to code without the help.

Header image: TinySol v1.3 on Jerry Parker’s Zenith Heath/Z-110 (8088, 256KB, CGA) at VCF Southwest 2026, via ClassicBits.net

from the the-ducks-are-in-a-biting-mood dept

For all the talk of “reforming” or “repealing” Section 230 in Congress, the fact is that the courts over the past three or four years have effectively chipped away so steadily at the law that it’s lost a significant chunk of its usefulness. The latest comes from the Ninth Circuit, which ruled earlier this week that Section 230 is not, in fact, an immunity from lawsuit, but merely a defense against liability. This may sound like a procedural technicality — and, indeed, the coverage of this case from the likes of Reuters covers it as a boring procedural story — but it’s a huge deal.

To get there, the panel had to rewrite the history of Section 230 and wave off a whole stack of its own prior rulings as either sloppy word choice or mere dicta.

To understand why this ruling is such a big deal, you first have to understand Section 230’s true benefit: it would get bogus cases tossed at the earliest moment. This is the entire key to why Section 230 is important. The point of Section 230 is to put the liability on the party actually violating the law — which would be the creator of the content, and not the intermediary tool they use to host/distribute that content. But the mechanism used to protect speech is that it gets the cases against intermediaries dismissed very early (aggrieved parties can still sue the actual speakers).

If it didn’t do this, the vast majority of the benefits of Section 230 would be lost. Indeed, in one of the many early Section 230 cases, the Ninth Circuit’s Alex Kozinski colorfully described why Section 230 immunity was so important in the famous Roommates case:

Websites are complicated enterprises, and there will always be close cases where a clever lawyer could argue that something the website operator did encouraged the illegality. Such close cases, we believe, must be resolved in favor of immunity, lest we cut the heart out of section 230 by forcing websites to face death by ten thousand duck-bites, fighting off claims that they promoted or encouraged—or at least tacitly assented to—the illegality of third parties…

Every bit of that bolded section is important — and it’s what the court is now ignoring. First, it’s Kozinski not just calling out that Section 230 provides “immunity” but that without it, we would “cut the heart out of Section 230” by “forcing websites to face death by ten thousand duck-bites.” Kozinski was exactly correct, and Section 230’s authors, Ron Wyden and Chris Cox, have said he got it right (I was at a conference years ago where both Cox and Kozinski were present, and when Cox said this interpretation was correct, Kozinski made a joke to the effect that it wasn’t often that a priest got word directly from God that his interpretation of the scriptures was correct).

The operative aspect of 230 is that it’s an immunity that gets rid of those cases early. Because without that, the mere threat of litigation would force many websites to simply remove content to avoid the cost of going through litigation. That’s the duck bites part of this.

And part of what’s important about it being an immunity is that if the district court refuses to dismiss the case on Section 230 grounds, you can immediately appeal that (“an interlocutory appeal”) to the appeals court to say that the district court got this wrong… rather than having to go through the entire litigation process (the thing you’re supposed to be immune from) and then telling an appeals court about the error. By not allowing an interlocutory appeal, it would do away with the element of Section 230 that makes it so effective.

Yet, on Monday, the same Ninth Circuit basically said “eh… nope.” Yes, the ruling was specifically procedural, but it was procedural on that point. Meta and TikTok — and, by extension, every other company facing these suits — have to get pecked to death by ducks first, and only afterwards can they tell an appeals court they never should have been pecked at all. The “procedural” rejection by the Ninth Circuit means that more than 3,000 lawsuits filed against these companies can move forward. It’s not (yet) the full ten thousand duck bites Kozinski warned about, but it’s in the ballpark. And we’re already seeing those duck bites in action.

What’s incredible, though, is just how confused the panel is about all of this. Judge Jacqueline Nguyen, writing for the court, starts by getting the history of Section 230 wrong:

The drafting history adds weight to the view that Congress employed a belt and suspenders approach. In the House bill, where section 230 originated, subsection (e)(3) contained only the first sentence. See H.R. 1555, amend. 744, 104th Cong. (1995), 141 Cong. Rec. H8469 (daily ed. Aug. 4, 1995). In reconciling a competing bill, the Senate adopted the House proposal “with minor modifications,” including what is now the second sentence. S. Rep. No. 104-230, at 194 (1996) (Conf. Rep.). It would be surprising if these “minor modifications” included the addition of immunity from suit.

However, as Jeff Kosseff — literally the guy who wrote the very comprehensive book on the history of Section 230 — notes, Judge Nguyen is exactly wrong.

Kosseff notes that his book goes through this, though so does the law review article he published a few years ago, which details how Section 230 changed during the conference committee and how it was, deliberately, about making internet intermediaries immune from lawsuits. He points out that while the initial draft of the law was supposed to prohibit the FCC from regulating the internet, during the reconciliation process, they deliberately “clarified the intention to preempt litigation” by adding in that “No cause of action may be brought and no liability may be imposed under any State or local law that is inconsistent with this section.”

If it was just about being a defense against liability, they would not have included “no cause of action may be brought.” But the ruling this week claims that Congress was just being superfluous there:

Meta argues that the phrase “[n]o cause of action may be brought” implies immunity from suit because reading it to provide immunity from liability would render the phrase “no liability may be imposed” superfluous. Id. § 230(e)(3). Not necessarily. Congress may have included “cause of action” to encompass suits for injunctive and declaratory relief, since “liability” could be read to encompass only damages. At the same time, Congress may have prohibited the imposition of “liability” to encompass orders by state administrative agencies, which may not involve causes of action. Whatever Congress’s reason for including both phrases, “sometimes the better overall reading of the statute contains some redundancy”

The ruling this week then dismisses all of the many other times that the Ninth Circuit (and other courts) said that 230 was an immunity from suit by basically saying “eh, previous courts were sloppy with language” along with “and when we said that it was never that important.”

It is true that we have used the phrase “immunity” somewhat loosely in our section 230 jurisprudence; although we generally describe it as “immunity from liability,” we sometimes describe it as “immunity from suit.” But none of this usage is binding, because we have never addressed whether the denial of a section 230 defense is a collateral order…

In a footnote, the ruling lists off many (though not all) of the times the same Ninth Circuit has said “immunity from suit.”

See, e.g., Lemmon v. Snap, Inc., 995 F.3d 1085, 1087, 1090 (9th Cir. 2021) (describing section 230(c)(1) as immunity “from . . . suit” and “from liability”); Barnes, 570 F.3d at 1099–1100 (stating that section 230 “protects certain internetbased actors from certain kinds of lawsuits” and that it “protects from liability”); Zango, Inc. v. Kaspersky Lab, Inc., 568 F.3d 1169, 1173, 1175 (9th Cir. 2009) (describing the statute as “plainly immuniz[ing] from suit” and providing “protection . . . for civil liability”); Carafano, 339 F.3d at 1122, 1125 (referring to “immunity from liability” and “immunity from suit”).

So, in order to reach this result, the Ninth Circuit needed to reinterpret and dismiss both many prior Ninth Circuit cases, claiming they were just sloppy with their language and the literal text of Section 230, again insisting that the “no cause of action may be brought” was just the drafters being redundant, rather than the much more likely (and as Kosseff’s history has shown, accurate) interpretation that the law was literally written to prevent intermediaries from having to face these kinds of lawsuits entirely.

It is true that the Tenth Circuit (and only the Tenth Circuit) has also ruled this way, but the Ninth Circuit has way more impact because a huge number of internet companies are based in California, which is covered by the Ninth Circuit. And many other circuits have ruled the other way. In Nemet v. ConsumerAffairs, the Fourth Circuit talked about “a sphere of immunity” created by 230 and points out that:

Section 230 immunity, like other forms of immunity, is generally accorded effect at the first logical point in the litigation process. As we have often explained in the qualified immunity context, “immunity is an immunity from suit rather than a mere defense to liability” and “it is effectively lost if a case is erroneously permitted to go to trial.” Brown v. Gilmore, 278 F.3d 362, 366 n.2 (4th Cir. 2002) (quotations omitted) (emphasis in original). We thus aim to resolve the question of § 230 immunity at the earliest possible stage of the case because that immunity protects websites not only from “ultimate liability,” but also from “having to fight costly and protracted legal battles.”

In the Sixth Circuit, in the Dirty World case, the court quotes the Eleventh Circuit’s Almeida v. Amazon ruling to note:

The majority of federal circuits have interpreted the CDA to establish broad “federal immunity to any cause of action that would make service providers liable for information originating with a third-party user of the service.”

So while the Ninth Circuit argues that this is some sort of novel issue… it’s simply not. Other than the Tenth Circuit in that one case, almost every other court (including the Ninth Circuit itself) has always held that Section 230 provides for immunity from suit, which as the record and the authors make clear, was exactly the point.

Technically, the panel isn’t wrong that none of those other cases squarely held that a 230 denial is immediately appealable. Courts aren’t bound by things they assumed rather than decided. But there’s a difference between “no court has ruled on this” and “every court to touch this for thirty years, plus both authors of the statute, absolutely understood it the same way to the point that they never needed to directly say so.” The panel treats three decades of consistent understanding as if it were a typo.

And while this latest ruling notes that this is fine because the court can always “revisit the issue of section 230 immunity at a later stage of the proceedings,” once again that destroys the very point of 230. This new ruling even points out that the district court is skeptical the plaintiffs even have a case here:

The court expressed its “skepticism” about plaintiffs’ ability to proceed on their “novel” failure-to-warn theories in light of section 230 but allowed the claims to proceed “for now” given that the litigation was at an “early juncture” and the law regarding section 230 immunity was “in some flux.”

But, once again, that’s the entire point of Section 230! To end these weak cases early!

Indeed, going all the way back to the Roommates case that we mentioned up top, where Kozinski coined his duck bites line, what was most memorable about that case is that the ruling denied Section 230’s protections to Roommates.com over one feature (though dismissed other claims because of it). And Roommates then had to spend four more years litigating the case… only to still win many years, and many millions of dollars later.

That, on its own, shows how important 230 is in getting rid of cases early. The whole point is that most of these kinds of cases are losers for their plaintiffs in the long run on First Amendment or other grounds. The benefit of Section 230 is that the companies don’t have to waste many years and many millions of dollars to get to that final conclusion. But the Ninth Circuit, apparently no longer caring about death by ten thousand duck bites, now says that such cases are free to proceed without interlocutory review at the very point it matters most.

Now the internet companies have a choice: they can ask the entire Ninth Circuit to review en banc, even as that’s a crapshoot with its current roster. They can ask the Supreme Court to weigh in, when we already know a few of the Justices hate Section 230. Or, they can submit to the first 3,000 duck bites, and see if they survive.

Which is the real irony here: for all the years of congressional threats to gut Section 230, it turns out the courts are the ducks, and there’s less of the law left after every bite.

Filed Under: 9th circuit, alex kozinski, content moderation, duck bites, immunity, intermediary liability, section 230

Companies: meta

Google’s new Pixel 11 series devices bring more than just hardware upgrades. One of the lineup’s most interesting new features is designed to break down the communication barrier between deaf and hard-of-hearing users and those who don’t know sign language.

Pixel Camera can now turn sign language into text

Google has introduced a new sign-to-text accessibility feature that uses the Pixel Camera to recognize sign language and automatically convert it into text, so users can sign as they normally would instead of stopping to type a response. Google says the goal is to turn the phone from a one-way listening tool into one that supports natural, two-way conversation during spontaneous, face-to-face interactions.

The feature runs on a new AI model called sign-language-to-text (SL2T), built by Google DeepMind, which the company says marks a breakthrough in translating sign language at scale. Once the Pixel Camera captures a user signing, the model translates it, and Gboard converts it into text anywhere someone would normally type, including web searches, messages, documents, and Gemini queries.

At launch, the feature supports American Sign Language to English translations on the Pixel 11 series, with Google saying more languages and support for additional devices will follow.

Built with privacy and real-world signing in mind

To protect privacy, the system tracks the location points on a signer’s body on-device instead of analyzing raw video, sending only those coordinates to Google’s servers for translation before discarding the original camera feed. Google DeepMind says the model was trained on more than 100,000 hours of data across more than 50 sign languages, and that it specifically tested performance for left-handed signers, who make up about 10 percent of users, and for one-handed signing, common when someone is holding the phone in their other hand.

The company says the model scored higher on a standard sign language translation benchmark than any previous system, though it hasn’t published data on how it performs in less controlled settings, poor lighting, or fast, casual conversation.

Translating sign language is a fundamentally different problem than translating speech, since sign languages have their own independent grammar and vocabulary instead of word-for-word mapping. An estimated 70 million deaf and hard-of-hearing people worldwide use sign language, and Google DeepMind says this marks the first time sign language AI at this scale has reached a consumer product. Whether SL2T holds up in fast, everyday signing, rather than the benchmark conditions Google has published so far, will determine if it becomes a genuine communication tool or another AI feature that undersells its own demo.

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.

Going With The Flow

Although workflows are a fairly personal thing in terms of preferences, we’re all creatures of habit with a strong tendency towards laziness. We also tend to prefer workflows that are easier for that reason. This is where after the very manual approach of the Ender v2 I really liked much about the Neptune 4, ranging from its much faster and open source Klipper firmware to a semi-automatic bed-levelling procedure, and of course the Fluidd web interface.

With this I can just pop open an interface in a browser tab and manage the printer, watch the webcam view, etc. from there. Somehow there’s now a third option that seems to be taking over, however. Although a web interface seems straightforward and easy for the average user, there’s been this move towards requiring the use of the slicer via a special API or such that leads to fun access situations as we have recently seen with Bambu Lab printers.

Out of a sense of morbid curiosity I decided to look at what I’d be dealing with if I were to upgrade to the latest & greatest Elegoo (CoreXY) printer if I ever grew tired of my Neptune 4, and noticed that they seem to have gone more in the direction of Bambu Lab. The firmware is Klipper-like but closed, with the most recent FDM printers like the Centauri Carbon series also requiring access via a slicer and/or a special mobile app with a lot of Cloud things mixed in.

To me this seems hugely cumbersome, since one of the things I like with the Neptune 4 is that I can access it from anywhere on a system with a slightly modern browser and print models that are stored on the internal memory. This is where the the GK3 Ultra scores pretty well in my book, too.

Certainly, this resin printer doesn’t do fancy web UIs or APIs, or much in terms of remote-anything. You do get Ethernet, a Wi-Fi USB dongle and the rather nifty ability to set up an SMB file share that you can dump sliced models onto before waddling over to the SLA printer. It’s low-tech yet also universally supported and open, while more convenient than plain Sneakernet, though that’s also an option using the front-mounted USB-A port.

Can I just briefly say how much I love having a USB-A port for Sneakernet purposes, rather than a tiny USB-C port or microSD slot? The Ender 3v2 offered either microUSB or microSD for inputs, none of which really made me like that printer more.

Finally Some Printing

For this first printing round, I printed the same parts on the Neptune 4 in white PLA and black PLA. For the GK3 Ultra I just used the ABS-like (AL) clear-blue resin, to not have to switch resins just yet. The prints include a range of items like bottles, some figurines and a bunch of LEGO Technic-compatible parts. The latter two serve to give dimensional accuracy a good workout, along with basic durability testing.

Starting with FDM printing, this was largely uneventful, though I upped the difficulty challenge with the N4 by using a spool of extra-brittle white PLA. Somehow even that came out fine, aside from an unfortunate spaghetti incident that required some PVA glue to be slathered onto the PEI build plate.

On the resin side of things, it was pretty much as I remembered it from my LD-002R days, just with an absolutely massive build plate, the auto-feeding of resin and of course the use of this rather nice transparent blue ABS-like (AL) resin.

On the slicer side of things I kept things as boring as possible, with OrcaSlicer for FDM, and ChituBox’s free version for SLA. I did look at Lychee as well, but they require registration for even the ‘free’ version, so that one was out for now. I’ll also say that ChituBox got a bit heavier resource-wise than since I used it six years ago, and somehow its UI still feels rather unintuitive, though that’s a bit of a central issue with slicers.

To be fair to Uniformation, they also provide their own slicer on the USB stick and as a download, but since the latter involves a random Google Drive, it triggered my system security-related anxiety. It’s probably a perfectly cromulent slicer, but using ChituBox was the less exciting option for me here as a first try.

Comparing Parts

Since both Elegoo FDM printers come with an example model in the form of this happy Buddha figurine, I figured that I’d also print it with the GK3 Ultra. Here you can see how these compare in a sloppy smartphone photo for which I apologize:

The model was clearly intended to be printed on FDM printers, so the SLA version doesn’t really add a lot, other than a lot of weight. Unlike FDM prints where you have aspects like ‘infill’, an SLA printer can print everything 100% solid with zero time penalty. In fact you want to do this so that you don’t need to drill a hole in it for liquid resin to leak out.

Of course, you can totally hollow out models to save resin and weight, but in that case you do need to add those drain holes lest you end up with liquid resin sloshing inside forever.

Moving on, I also printed a miniature knight figurine on the N4 and GK3 Ultra, which was a bold decision for the former:

Removing supports on this approximately 32 mm tall model was a bit of a nightmare with the SLA version, and I still need to clean it up better, while also rethinking ChitBox’s insistence on angling it upside-down for some reason.

I didn’t even bother with removing supports on the FDM version, although I was somewhat surprised at how much detail it still had when pushing layer height to its ‘super fine’ 0.12 mm setting, though the SLA printer with the ‘sloppy’ 0.1 mm layer height preset is simply in another universe when it comes to preserving fine details.

Clearly layer heights between SLA and FDM are at best the fuzziest of all overlaps, with even the knight’s cape in the SLA version capturing the flow of the fabric and details in the helmet that the FDM version had obliterated.

Finally there are the LEGO Technic-compatible shenanigans:

There is obviously a lot of variability and improvement possible simply by the orientation you print things in, the type and placement of supports. SLA has the massive advantage here that support points on models can be made absolutely tiny and correspondingly leave almost no mark. This made e.g. printing LEGO-compatible parts a snap on SLA, but a nightmare on FDM where I struggled to find an orientation and support/brim configuration that didn’t lead to misprints and/or interfered with the part’s functionality.

The thing where ChituBox really did me dirty, however, was that it went crazy on supports, even adding lots of supports inside these latter parts that still have to be painstakingly poked out if I want to actually properly use them. This is however a slicer issue and potentially a skill issue on the side of yours truly.

Flipping Of Tables

Even after just this first round of printing there’s quite a bit to unpack. On the FDM side of things the workflow is definitely the easiest, especially in terms of post-processing. I did have some bed-adhesion issues, however, which is where SLA tends to be significantly less fussy with just the long-exposure first layer. For the FDM side of things I had a few misprints as a result, which was annoying.

On the SLA side of things there wasn’t too much to upset me, other than some table-flipping at the automatic resin feeding system which I mentioned in the first article. After starting the print, the system seemed to work and began filling the vat with resin, albeit very slowly. At some point I got a ‘material in/out time-out’ error, following which I retried printing, with the resin system again trying to fill the vat for a long period of time.

Ultimately I decided that since I only needed just over 60 mL for the print, and it had already poured in about half the resin bottle, I’d just cancel it. It’s likely that I missed a step here, such as I’m not sure whether you need to pop open the bottle for this to work, but the manual did not mention such details.

Popping over into settings I disabled this auto-feed system and tried to printing again, which worked without issues, other than the backstabbing by ChituBox and a persistent resin smell. This latter issue I tracked down to the slot for the resin bottle, which may or may not be related to the auto-feed issues. After sealing up the gaps the resin smell faded quickly, making it seem at least plausible that the active-carbon system of the machine does something.

After printing I did the usual post-processing, just with a scraper to knock the supports loose instead of something more gentle with a flex plate. The parts were tossed into IPA for a quick clean, including a trip through the ultrasonic cleaner. This was followed by another quick IPA rinse and finally some tanning with a UV lamp in a water bath. This latter step is to keep oxygen away from the curing process and thus speed up the curing, which is one of those details that have worked well for me in the past.

First Conclusions

Despite some flipping of tables, it’s been a fairly positive experience that at least has allowed me to set a bit of a baseline. My overarching feeling at this point in time is that FDM is rather okay for large parts with little detail, such as a CD rack that I already printed in PLA. Not having to deal with smelly resin and involved post-processing is also generally nice.

That said, the sheer quality and level of detail you get with SLA is just a whole other ballgame than FDM. Although it’s been a few years since I previously printed with resin, I still have quite a few prints from that time, including an absolutely miniscule fox figurine that I scaled down on the LD-002R for fun and which still is very much recognizable. The SBC cases and such printed in resin from back then have this level of smoothness and solid feeling to them that you just don’t get with FDM.

An elephant in the room remains that of ABS and ABS-like printing. Such engineering-grade materials are essential for anything in production, and I definitely have to give this Uniformation ABS-like material a good workout. That said, I’m still very hesitant about printing ABS and ASA filaments with FDM, due to the health hazards this poses, mostly caused by the release of styrene.

Although I already wear a respirator with A1 filters backed up by P2 prefilters against VOCs and kin while processing SLA prints, styrene pushes the hazard levels a few notches higher, since unlike most organic vapors it’s not just an irritant, but a known mutagenic toxin. Here an active carbon filter in a closed-chamber FDM printer would seem to be at best optimistic.

To me this aspect alone makes the idea very appealing to use SLA to print high detail models and production parts, while using FDM for sloppy prototyping in PLA, PETG and of course TPU, but this is something that I’ll have to poke some more at. Any input here would be most welcome so that I can do even better with the next article.