AI companies don't have a great track record in areas like copyright or user privacy — unless they're the ones on the short end of the stick, that is — but it's generally known that the chat logs from platforms like ChatGPT are used for improving models. The mechanism as to how this happens was still a mystery until today. 404 Media just published a report about OpenAI's process of human review for chat transcripts, explaining how the review process works, and how it involves other humans sometimes reading private information.

The rating project's name at OpenAI is Project Lily. The publication got information on the project's instruction guides, Slack channels, real ChatGPT conversations, and, of course, the rating system to classify conversations. The operators are called "prompt reviewers," and their job is fairly simple: look at anonymized real-world chats, and judge the quality of ChatGPT's responses to assess whether they actually answer the question, and that the text doesn't overuse "AI-speak," patronizing tones, emojis, or sycophancy, among other parameters. Anthropomorphizing and stating "personal" experiences are both off the table, meaning that while it's OK for ChatGPT to say "I found some information," it's not OK for it to say "as a chef, I like to..." or "I know what that's like."

The work is "very rote," according to a reviewer, but at reportedly over $50 an hour, it's a high rate for what looks like reasonably simple work. The reviewer also said that their guidelines keep changing and are often self-contradictory, a feeling most software developers should easily identify with.

The person doesn't think that most users are aware their chats are being read by others, though, something that's particularly troubling when many use ChatGPT as an impromptu friend or therapist and put deep secrets in words for the bot to read.

While the chats allegedly go through an anonymization pass and reviewers don't see usernames, OpenAI admitted to 404 Media that the filtering may let some personal data through, especially in shorter chats. The site notes that in many conversations, the user asks ChatGPT to keep the contents secret, as well. The version of the chat handed to reviewers also reportedly includes a "user memories summary," containing a summary of the users' questions and interests, context, and potentially even location.

Crucially, Project Lily does not grade the chats' actual factual accuracy other than flagging obvious mistakes, implying that there's likely at least one more team (or several) doing separate evaluations. Likewise, this reviewing is separate from manual safety checks that ascertain if someone might be looking to hurt someone else (or, presumably, themselves).

The existence of the project also indicates that contrary to these image AI companies try to cultivate, the models don't improve just with technological advancement and better training sets — it appears you still need more than a few competent humans in the mix.

By now you may be wondering about the "allow us to use your chats to improve our product" (paraphrased) setting present in most consumer-facing chat bots. That setting is turned on by default in every bot we can think of, even with many paid plans. In ChatGPT's case, it does default to off in Enterprise, Business, and Educational customers.

That toggle switch does not work retroactively, though, so any chats already in ChatGPT's database will remain there unless the user requests deletion. Also, said deletion is also not retroactive, meaning that deleted chats may have already been hoovered and anonymized, and possibly reside in a dataset somewhere.

Although OpenAI initially had no answer to 404 Media's inquiry on whether users were explicitly informed that their chats could be read by humans, the company eventually offered a link to one of its FAQ pages that discusses human review for the purpose of model improvement. We verified ourselves that said notice is at least two years old, and likely older. After the publication of the exposé, the firm changed its help page explaining how people can opt out of data collection, but there's no mention of human operators in that text.

This type of data collection and review is a running theme across most providers. Google Gemini clearly states that "humans may review some saved chats" in its Privacy Hub. Anthropic's stance is similar, with a page dedicated to this topic. Perplexity's stance, meanwhile, is unclear, as its Privacy Notice doesn't confirm or deny human access to chat logs.

Microsoft has issued an out-of-band update for its recent Windows 11 patch, which has caused a number of bugs and issues. The September 2026 update was just released last Tuesday, and although it packs a number of new features and fixes nearly 1000 security flaws (commonplace in this day and age), there are also a few unfortunate regressions.

The 25H2 update finally reintroduces a movable taskbar, just like we've had since Windows 95, with an option to make the height smaller for compact displays. Likewise, the Start menu now has multiple configurable layouts, and you can toggle each main section on or off. Microsoft also revamped Windows Search — perhaps to finally be useful — and users can now choose to only have it display local results. Explorer got a handy tweak in the form of using KB, MB, GB size indicators, as well.

The update has also surfaced some serious bugs. First off, PCs with AMD Radeon GPUs are crashing, apparently due to the update provoking driver instability. Reinstalling the driver doesn't appear to help, and the reports unfortunately cover most contemporary AMD graphics cards. Microsoft did not mention AMD GPUs specifically in its latest update.

Microsoft noted that it has fixed an issue with Remote Desktop Services where RDS might become unstable, causing connection and sign-in failures.

Microsoft is also aware of an issue with audio output and microphone input going dead. Additionally, there are seemingly reports of audio devices starting up with a botched configuration, like tweaked 3D audio settings or speaker setups. The apparent workaround seems to be putting audio in a standard 2.0 configuration, but Microsoft has now addressed this issue in the emergency patch.

Explorer may display a black screen after logging in, leaving you with a perfectly functioning operating system but no visible UI. The File History backup feature is reportedly not detecting external drives, effectively making it useless. Of particular concern to enterprises, systems administrators, and homelabs, the Remote Desktop Service is also experiencing issues. Last but not least, Microsoft says it has addressed an issue where Claude Cowork is nonfunctional due to the update breaking HC-managed Linux VMs with Plan9 shared folders

Owners of HP and Lenovo systems are also advised to consider holding off on this update. Ever since the August 2026 patch (and now, cumulatively, with the September update), there are reportedly serious issues on both camps. On the HP side, there are instances of the update triggering BIOS corruption, leading to a failed install with no ability to recover the OS — though seemingly the OEM has published a new BIOS revision, so it's hard to say which side is to blame. Meanwhile, Lenovo users might have their machines black-screen or shut down out of the blue, seemingly due to power mismanagement.

While it's heartening to see that Microsoft has significantly increased its Windows development speed and is seemingly listening to customer feedback, a string of bugs after a major feature update are still common.

The immortal line "it's a Unix system, I know this" is forever entrenched in many a techie's brain. In the Jurassic Park movie, the visualization software in question was Silicon Graphics' File System Navigator for IRIX, an actual piece of software running on a real SG workstation. The concept of viewing files in 3D space never truly caught on, but the horsepower available in contemporary machines may change that. Makepad creator Rik Arends created his own 3D flyable source code visualizer that he claims handles 2.5 million lines with ease, at 120+ FPS, no less.

Although the published video is only at 60 FPS due to X's limitation, the navigation looks smooth indeed, and it's impressive to see all the actual source code in a reasonably readable manner. Arends says the visualization initially took 21 GB of RAM (in this economy?!), but that after judicious application of indexes and streaming compression, he got memory usage down to a much more palatable 3.5 GB. Although he remarked that he's yet to fully optimize the visualizer, he did try to load Chromium's entire source tree (51 million lines) in only 60 seconds at one point.

While one can argue that the 3D visualization of the code itself is probably really fun to look at, its practical use is also questionable, at least as-is. A commenter remarked that adding a time element would help immensely, by displaying changes to the source files. 3D tracking of dependencies would probably be handy, too. There's already an actual full-fledged commercial tool called CodeCharta that visualizes changes and hotspots in 3D, though the flybys aren't quite as impressive.

Arends says that he intends to turn this visualization tool into a product and charge a small fee for it, though he admits that the usefulness of the visualization may be limited. When asked why he created this, he simply said, "because I could." The jury is still out on whether he should.

Last week, Anthropic published its prediction of what the economic impact of AI on the U.S. economy is going to be for the next few years. The company thinks the U.S. can reach a $44.4 trillion GDP or higher by 2030, provided, of course, it conveniently adopts AI at a rapid pace. Having said that, Anthropic admits "the challenge is making sure that the gains are broadly shared."

The interactive post has a simulator where readers can plug in their estimates on key factors and get their own future predictions, within the firm's analysis and perspective. That's definitely interesting to play around with, but perhaps the most relevant piece of information is the lens through which Anthropic views the world.

Anthropic establishes its reasoning by first placing tasks in broad categories and using a nurse's workday as an example. They removed tasks, including those that will disappear naturally as technology progresses, like collecting data on paper or physically visiting the patient to collect basic vitals — neither happens anymore as remote monitoring becomes commonplace. However, some new tasks are added, like keeping an eye on dashboards for the aforementioned AI-powered monitoring.

Then, there are naturally the tasks that a bot can't perform, like bathing a patient. Augmented tasks include those that require a human, but can be made more efficient with AI: helping with triage, planning schedules, and assisting with dashboard data. Some tasks may be fully automated, like keeping supply closets full or scheduling follow-up patient visits. Finally, AI usage can introduce some tasks of its own, like reviewing automated triaging or double-checking dashboard alerts — perhaps even impromptu data recovery.

The company's predictions broadly hinge on how ubiquitous AI usage becomes, and therefore, the number of tasks transitioning into fully or partially automated. Unsurprisingly, Anthropic believes that the more entrenched AI gets, the more value the country creates, though at greater risk — and on an exponential scale, no less

Three models are presented, from "modest" economical impact to "extreme." The modest model establishes a 1.6% GDP rise to $34.1 trillion, an impact Anthropic says is in line with that of new technologies like the internet, and crucially, doesn't imply tectonic shifts to unemployment rates or wages.

For the "substantial impact" scenario, although AI is predicted to be able to do half of "knowledge work," mostly without intervention, adoption remains limited. This scenario foresees twice the normal economic growth, this time +8.3% to $36.3 trillion.

This future marks the inflection point at which Anthropic believes knowledge workers see their wages remain steady instead of growing, though it's not clear if the firm accounts for inflation. Additionally, the firm states that "knowledge workers may see a lot of automation and displacement [...] coders and call service center agents may have to switch to jobs like electrician and nurse", a statement some might argue is already true. In that sense, Anthropic expects other workers to start seeing more cash.

The eyebrow-raising prediction for both the above scenarios, though, is that Anthropic expects unemployment to "stay within ranges history has seen before," an odd statement given modern U.S. history contains events like the Great Depression. The company does note that it expects job churn to increase, but also that while "this process can be painful, [it] works relatively well from a macroeconomic perspective." Average wages are expected to rise across all three scenarios, though the increase is expected to go towards workers outside of knowledge areas.

In the "extreme" scenario, Anthropic expects significant changes. Should AI be super-widely adopted, the GDP can increase by 32.4%, corresponding to a cool $44.4 trillion, a "profound economic transformation." This is the point at which the firm expects that AI becomes more productive than humans for most knowledge work, and does so with near-autonomy. Equally worryingly, it's expected that there will be "essentially no" new knowledge tasks created.

Anthropic notes that to reach this kind of stage, the country would "likely require" recursively self-improving AI (using the AI to make better AI). There's a significant catch, however, as though the U.S. would be "far richer than [it's] ever been," knowledge workers would be the hardest hit with a 10% wage drop, plus overall unemployment would climb "beyond typical recessionary levels." Manual labor would be prized, though, given that "as AI increases productivity within knowledge work, the demand for manual work that benefits from that productivity will increase."

Scenarios aside, the one big question is: How would all that GDP money land in people's pockets? Anthropic admits this problem is a "challenge" and offers little solution for it. Such a high amount of future AI penetration might prove a hard sell, considering wealth inequality in the U.S. already sits at its highest level for the last few decades and is trending in that direction in most developed nations. Others might argue with Anthropic's assessment that unemployment levels would remain somewhat in the less extreme scenarios, seeing as job cuts are rampant across many sectors and have hit technology-related fields the hardest.

To its credit, Anthropic clearly highlights part of the wealth-inequality issue. The company admits that more AI automation might skew the current 60/40% balance between labor and capital, respectively, strongly tilting the scale in favor of capital ownership and increasing inequality. Many argue that's already happening today. There's also the matter that the prediction appears to assume little competition from other countries, nor does it offer insight as to what would happen to "AI-less" nations.

The interactive blog post and its simulator are worth a good read and fiddling with, regardless. Anthropic published the technical details on the mathematical model used in a separate article and published its Economic Policy Framework last June.

These days, AI companies directly or indirectly announcing how their respective wares are smarter than their competitors has become a genre of elevator music. Even so, some in-depth articles can be quite insightful, like Anthropic's occasional reports on attempted misuse of its wares. The latest one covers activity between November 2025 and September 2026, with an important reveal: five situations where Claude was asked to perform work determined to potentially be used in biological weapons.

Right out of the gate, Anthropic remarks on the difficulty of understanding if a particular line of inquiry pertaining to biology is meant for nefarious purposes, to create defense mechanisms like vaccines, or simply to establish predictions of how a virus spreads. The company says that "out of an abundance of caution [....] launched recent models with stronger safeguards."

Among the tens of case studies presented in the lengthy report, Anthropic discusses five cases that it deemed particularly concerning, three regarding viruses, and two more discussing toxins. The common theme across all of them is that all threat actors used varying degrees of anonymization techniques and did their best to evade Anthropic's own regional blocking. The report doesn't mention specific states, but the firm is known to block access to Claude for China, Russia, Iran, North Korea, among others.

In the first case, a request for assistance in developing a grant application involved finding ways to improve the chikungunya virus. The purported researchers were trying to come up with ways to both add extra abilities to chikungunya (increased mutation) and increase its virulence. The topic itself already raised some concern, but Anthropic's hand was forced after finding that although the grant application seemed to be for civilian researchers, the actual investigation was meant to proceed at a military facility.

The firm also found that the request would have gone through a third-party LLM platform associated with military as well as civilian institutions. The countries involved are geo-blocked by Anthropic, and that platform routed comms traffic through the U.S. to try to evade detection, used gray-market resellers, and specifically catered to customers looking to skirt content restrictions. Anthropic banned the accounts in question and shared the information with government authorities, though the same people repeatedly tried reaching Claude again via zero-data-retention services.

Case #2 pertained to a non-US researched who was looking to dig into how avian flu adapts to mammals, and how it can cause diseases other than in the respiratory tract. The problem is that avian flu has a high fatality rate, and there's little population immunity.

While the virus doesn't easily spread from person to person, therein lies the rub — the research could end up discovering mechanisms to increase transmissibility. The researchers used a random username, a private email service, and accessed Claude through a VPS, leading Anthropic to investigate and ultimately turn its nose up at this strain of thought.

The story with the third case bears a resemblance to the previous two. Once again, an account was trying to prepare a supposed grant application, this time around about orthopoxviruses, the family that houses smallpox and Mpox, among others.

The application discussed containment facilities and live experimentation with the viruses, and focused on understanding their genetics for the purpose of evading immunity. The research didn't initially trigger alarms, but Anthropic came to notice it was created via a reselling service, with a randomly-generated email, tunneled through U.S. infrastructure to reach Claude, and traced back to a banned account farm.

In the last two cases, instead of viruses, the purported researchers were focusing on toxins. In case #4, a person mapped out venom toxin peptides from multiple families of animals and created a program to optimize their toxic characteristics.

Although the stated goal was to create painkillers, antidepressants, and other therapeutic molecules, the data would equally allow the creation of potent harmful compounds. Anthropic also came to learn the content Claude was generating was part of a state-sponsored program in an "unsupported region."

In the fifth and final case, a theoretical scientist was also using Claude to try and redesign a set of toxins, also supposedly for therapeutic purposes, under a national public search program. However, the work touched upon "a bacterial toxin subunit and a protein of the hemorrhagic-fever virus" that happens to be on the World Health Organization's list for particularly nasty, pandemic-inducing diseases.

The scientist tried to obscure the subject of the research, directing Claude to be vague about descriptions. Once again, the story ended with Anthropic cutting off access to Claude from a location that broke its terms of service.

Today is September 9, and the significance of the date for Australian consumers is that, by law, buying online apps and games now requires an over-18 age verification step. The local law isn't specific about the exact type of verification, only that it offers "appropriate age assurance measures." Valve is complying by asking for a bank card rather than government ID or a biometric check. The problem in the land down under is that while credit cards seemingly all work, debit card support is spotty and conditional.

This situation isn't unique, as it's basically a repeat of the same existing scenario in the United Kingdom. Valve's privacy-minded approach is laudable, as a bank card only links a payment method to a name and address. Meanwhile, a government ID is a more dangerous document if it gets leaked; face scans are quite fallible and revealing, and biometrics are intrinsic to the person and not replaceable if exposed — unlike bank cards, which can be canceled and swapped in minutes.

However, having a card check as the only verification option is causing problems, and many users are already asking for other means of verification, even if they're more invasive, citing Xbox and Sony's services as more accommodating.

Since credit cards in Australia (and the UK) can only be issued to adults, they work fine for Steam verification. Debit cards, on the other hand, can be carried by minors, and they're only valid for age checks under specific conditions. For now, that seems to be those (a) belonging to the Mastercard network, which introduced its own global automatic age verification check on June 2, 2026, and (b) for which the issuing bank flagged the card product as adults-only. The transaction firm only passes the answer to "is the buyer an adult?" back to the merchant (in this case, Steam), without exposing an actual date of birth.

A quick harnessing of user reports, mainly from Reddit posts, seems to indicate that debit Mastercards from Commonwealth, Westpac, and Macquarie appear to work, while those from Bendigo, St. George, Revolut, ANZ, and most Visa cards seem to fail the check. Note that this is an evolving situation, so the situation may have changed by the time you're reading this.

The demographics of credit card ownership definitely don't help matters. Unlike the U.S., where credit cards are the default method of purchase, only about 45% of Australian buyers and 65% of UK punters own one. Perhaps most importantly, within the 18-24 age demographic, only 25% to 30% own a credit card — precisely the people who buy the most games and are the most affected. For both user satisfaction and business reasons, it's seemingly desirable that Steam add verification alternatives.

Most anyone involved in computing has heard about the P-NP problem, but fluid engineers and mathematicians would love to know if the Navier-Stokes equations have smooth, globally defined solutions. Both questions are part of the Millennium Prize Problems, solutions to which are worth a cool $1 million and eternal renown. OpenAI is claiming that its staff and internal models have solved the conditions of Navier-Stokes solutions set forth in the Millennium Prize. But the company's shouting from the rooftops is being met with a chorus of boos over claims it might have plagiarized the work of a research team that had been toiling on a related, stepping-stone problem for a year.

Tristan Buckmaster (a scientist at NYU) and Levent Alpöge (a member of Anthropic's staff) had been quietly working on proving Euler's equations — another long-standing mathematical problem, and one that is generally acknowledged to be a stepping stone to solving Navier-Stokes.

According to Buckmaster, his work with Alpöge was "a purely personal collaboration, free of any institutional agreements or official involvement by either of our employers." The researchers used Anthropic Claude and OpenAI Codex as assistants, as is apparently now common in the field, to perform busywork (documentation, searching, etc.) as well as running through logic steps. The substantial amount of compute time the project required was paid from Buckmaster's own pockets, too.

The pair worked for roughly a year until August 15, 2026, when it obtained "the blowup results, with smooth forcing, for both Boussinesq and Euler." Buckmaster says the novel approach was based on previous work by Diego Córdoba and Luis Martínez-Zoroa, and he believes Zoroa should be eligible for a Fields Medal.

Although the team was presumably happy with these achievements, Buckmaster said that the LLM-generated proof was "the most horrendous" he'd seen, calling it "AI slop," and meaning to rewrite it for clarity. Nevertheless, they verified it on August 22 using Lean, a standardized programming language designed specifically to verify mathematical proofs.

Come September 3, Alpöge told Buckmaster of rumors going around that Anthropic had solved an important mathematical problem. This almost certainly alluded to the team's work, and some apparently took it to mean the company itself was working on the problem. The rumor-mongers even theorized that the problem that Anthropic had solved was Navier-Stokes. Alpöge further believed that OpenAI had gotten wind of the news.

This prompted Buckmaster to email an unnamed "prominent mathematician" at OpenAI, clarifying that the effort was a personal collaboration between him and Alpöge and was unrelated to Anthropic. The mathematician replied asking for details, saying "it would be useful to avoid competing," and offering OpenAI compute time. After a few days, on September 6, Buckmaster, the unnamed person, and OpenAI's Sébastien Bubeck talked twice, without Alpöge. He was told that OpenAI had proven a finite-time blowup for the forced Navier-Stokes equations, a subset of the problem.

Alpöge asked by text for the precise statement and was told "existence of forced blowup in R³ and T³", and that "the forcing function is smooth option [C] and [D] in Fefferman," referring to one of the four possible categories established by the Millennium Prize, with any one of them being valid as eligible for the prize, but not constituting a full solution for all scenarios, a distinction remarked on by other scientists.

This is where the story becomes interesting. Buckmaster claims that that idea (forced blowup) was exactly the same one his team had "quietly" chosen, and that nobody else he knew was working on it. Perhaps most importantly, he says that that was "not the direction one arrives at in a few days by giving a model the problem statement," indicating that running the general problem through a bot wouldn't quickly reveal that potential approach.

In fact, Buckmaster claims that over the calls, Bubeck ultimately revealed that instead of just AI models and agents with a couple of handlers, there was an entire team of live humans working on Navier-Stokes. The OpenAI team first had the models try to work through easier paths, and the text prompt that generated the Navier-Stokes proof had itself been generated by prompting Codex, with an "insane" amount of computing needed.

Buckmaster then asked when the initial prompt was issued, and OpenAI's response of "in the past few days" did not arrive until "some time" passed. He proceeded to ask if the model "had been trained on, or had access to, our sessions in Codex," and was told by OpenAI that Codex does not access user data. Finally, he asked if the data was used for model training more generally and, crucially, apparently did not get an answer.

OpenAI allegedly offered Buckmaster two options: one, that Buckmaster and Alpöge publish their Euler proof first. The following day, OpenAI would post its Navier-Stokes proof, giving the two priority. The second option was that Buckmaster alone, without Levant, was to write a paper with the Navier-Stokes proof, acknowledging that an internal OpenAI model resolved it. Bubeck was apparently adamant about Levant's removal from the Euler proof, as his employment at Anthropic was "annoying." Buckmaster opted for neither, and told OpenAI that if it chose the first option, he'd go public with his findings, as has since occurred.

This prompted what Buckmaster interpreted as a threat from Bubeck, who asked him "why [he] would ruin [his] career." After Buckmaster asked why that would happen, Bubeck told him, "If you don't want me to be nice, then I don't have to be nice." Bubeck then allegedly reached out to Alpöge, questioning Buckmaster's sanity, to which Alpöge responded with a refusal, pointing inquiries back to his colleague.

The entire story raises pointed questions about what OpenAI (and others) are actually doing with user data collected via its LLMs, despite the toggle switches that are supposed to disable it. Not only has OpenAI neglected to tell Buckmaster whether it used his team's data for training, in its PR about Navier-Stokes, the company says while it "no specific user data was accessed in order to solve this problem," it "cannot rule out that de-identified data derived from their usage of our products helped improve [its] models."

OpenAI's proof still needs to undergo a likely years-long peer review before any party can take the Millennium Prize home. The firm has stated it does not intend to claim it. As for Bubeck, he predictably paints the story in a very different light, but insists that his pushing away of Alpöge is justified on the basis that "it would be inappropriate for an Anthropic employee to author OpenAI's work," a puzzling statement that some could take as meaning a double standard regarding scientific authorship, based solely on corporate rivalry.

For his part, OpenAI CEO Sam Altman claims his team was well-intentioned and cooperative, and supported Bubeck, saying "it was challenging to offer [the same publication options] to Levent." Neither person opted to discuss the matter of whether OpenAI used the research of Buckmaster and Alpöge as training data, or offered any further explanation of why Alpöge didn't deserve credit for his work as an equal to Buckmaster.

Given the groundbreaking nature of this apparent discovery and the ensuing fight for priority that these competing accounts have sparked, it'll likely take quite some time and review before we know whether and how OpenAI or Buckmaster and Alpöge will be credited with this discovery. But given the inter-lab rancor already on display, the process will surely be ugly.

Anyone keeping track of world news in the early 2010s, and reports on tech in particular, has probably heard about Stuxnet. That malware spawned a large number of conspiracy theories — with the kicker that some of them were actually true. The malware targeted Iranian nuclear facilities and is believed to be the first digital worm to cause direct physical damage in meatspace. An unknown security researcher has now published a source code reverse-engineering of Stuxnet in all its glory.

The worm's ultimate target, allegedly a successful one, were industrial controllers from Siemens that were reportedly used in Iranian's Natanz nuclear enrichment plant. Once it reached the target, Stuxnet's payload manipulated the frequency converters in industrial centrifuges, in a bid to subtly damage the rotors — all while keeping the plant staff in the dark by reporting normal operation.

The repository contains build instructions so interested techies can try it out for themselves and learn all about its inner workings. You'll need a Windows XP or Windows 7 virtual machine, and for obvious reasons, you shouldn't configure any network connectivity for it. To witness the full effects of the payload rather than just the spreading mechanisms, you'll need the appropriate Siemens software, and ideally hardware — though we figure that industrial-scale centrifuges aren't exactly common in techies' cable drawers.

In its heyday, Stuxnet spread via three mechanisms. The primary infection vector was USB sticks with Windows shortcuts and autorun.inf files. Upon plugging one of those sticks in, just viewing the drive's contents would immediately trigger infection thanks to a zero-day vulnerability.

Infected systems then autonomously tried to spread the worm further via the network using a zero-day Windows Print Spooler vulnerability that would let an attacker write system files into any machine sharing a printer. It would also copy itself into accessible network shares. To evade Windows driver signature checks, Stuxnet used two digital certificates stolen from Realtek and JMicron.

The worm also had code to inject itself into Siemens software, by way of the WinCC SQL Server database, and embedding its code in Step 7 project files that automatically ran when engineers opened them. Since those files were almost guaranteed to be shared among more than one engineer, it made for an excellent internal infection vector that didn't depend on having network share control.

The final step was taking charge of the DLL that communicated with the actual centrifuges and injecting malicious code into the PLCs (Programmable Logic Controllers) of those machines to stealthily mess with the rotors.

Stuxnet was part of Operation Olympic Games, an alleged coordinated effort between the U.S. and Israel to try and curb Iran's purported progress in creating nuclear weapons at its Natanz facility. The initiative seemingly ran under both the Bush and Obama administrations, and was supposedly a way to dissuade Israel from launching its own preemptive strike against Iran. The software was allegedly developed by both the Pentagon and Israel's Unit 8200, and was reportedly successful in bringing down about 10% of Natanz' centrifuges by ultimately seriously damaging their rotors.

However, the worm had a nasty bug: it didn't have sufficient checks about which environment it was in, and failed to notice it was no longer in a local network environment. When engineers took their laptops home, it escaped out to the internet at large, at which point security researchers worldwide let out a collective "huh, that's odd" and proceeded to investigate. Mercifully, the worm contained a hard-coded self-destruct date set for June 24, 2012.

Musicians and synth-heads in the audience, rejoice. A new vintage synthesizer plugin has arrived that has the potential to blow many commercial offerings out of the water — and it's completely free, to boot. Audio software maker Autodafe has released the Vintage Emulator Studio (VES), a fresh new plugin that integrates a fair number of the open-source MAME emulator's synthesizer cores in one neat package.

The entire list of emulated synths is below, but it includes iconic entries like the Akai MPC3000, LinnDrum, Oberheim DMX, and Roland TR-707 — used by names like Dr. Dre, New Order, The Police, INXS, and Prince, among many other high-level acts. There are a total of 44 machines, all with component-level emulation.

What makes VES different from most other synth plugins is that instead of presenting a facsimile of the final output or a hybrid mix of component- and output-stage emulation, it employs — by way of MAME — full component-level emulation. Each processor, tone generator, envelope generator, filter chip, and converter should be faithfully reproduced, potentially resulting in a "perfect" emulation of the gear in question, more or less depending on the status of each driver core.

Notably, on machines whose MAME emulation is farther along, analog and/or digital output stages are faithfully recreated, meaning you won't need additional low-pass filters or any other trickery to make the synth sound like the actual hardware. Additionally, the skeuomorphic, HiDPI-ready UI replicates the units' control panels, dials, buttons, and LCD displays, making them easy to interact with if you're familiar with the real hardware — and probably a nightmare if you're not, as "ease of use" wasn't high on the list of priorities back then. Floppy disk, CD-ROM, and peripheral emulation ought to be included too.

If by now you're thinking this is all too good to be true, there are indeed a couple or three catches. First and foremost, as with any emulator, you'll need to provide your own ROM/firmware, and depending on the synthesizer, any associated sample packs. Although obtaining those is not too difficult, having a copy of that data is a legal gray area if you don't own the original hardware. Although we haven't tested it ourselves, the CPU usage of the plug-in ought to be somewhat high, considering all the work it's doing simulating every single component.

Additionally, while MAME's emulation cores aim for full component-level emulation, not every synth driver has had the same amount of work put into it. For example, the Akai MPC-3000 driver is nearly complete, while the Prophet-5's has only been introduced to MAME fairly recently — so your mileage may vary. We'd expect this VST to be updated somewhat frequently as work on its MAME core moves forward.

For the sake of argument, though, if only a handful of synths are fully emulated, that's still an impressive showing out of a list of 44, given that in theory you'll get output that tracks exceedingly close to that of the original hardware, all from one plugin. You can download the Vintage Emulator Studio right here, in VST3 or AU format, for every major OS: Windows, macOS Intel/M-series, and Linux. It's also available as a handy standalone application.

Data center builds are one of the hotly contested items worldwide. Many states and cities have upheld moratoriums on new buildouts due to power usage, water consumption, and noise concerns. Thailand is the latest nation to pump the proverbial brakes, with the government requesting that existing buildouts hit the pause button while coming up with a more precise regulatory framework.

Government heads requested that agencies compile information about current and future data centers during this week, in a bid to create unified legislation. The country currently has few laws specific to data centers, leading to legal voids like zoning a data center as a "warehouse" right next to a hospital. Much like everywhere else, the country has seen growing complaints about data centers' water and power usage.

After the week is out on September 11, the government expects to take about a month to come up with a regulatory draft, making the pause technically an indeterminate timeframe — though further delays wouldn't benefit either party, as Thailand considers the industry critical to the country’s competitiveness. The catch is that pausing construction isn't enforceable, so companies can elect to plow ahead regardless while the legislation is discussed.

NESDC (National Economic and Social Development Council) secretary-general Danucha Pichayanan is very specific: "we don't have the power to suspend the construction of the 49 data centers" currently under construction. However, when the legislation arrives, it will apply retroactively to ongoing projects, though with an adjustment period for in-progress builds. New builds will naturally need to comply with the legislation from the get-go.

Some companies may elect to soldier on with the belief their buildouts will be in compliance with the reasonably predictable content of the new laws, or betting that they could win future legal challenges — a dynamic that's already in play elsewhere with Project Jupiter. The incoming legislation is expected to cover power consumption (and possibly generation), closed-loop cooling, and water-surplus guarantees, meaning builders already have a fairly good idea of what they'll need to do.

Not complying with the request for a pause might be a game of political chicken, though, as the government may retaliate with regulatory delays and additional costs to power connections. Just last Thursday, Thailand's energy ministry raised concerns over a Bangkok data center that may be planning to hold diesel stockpiles far in excess of the 200,000 liters it has permission to.

On that topic, Thailand revised laws on industrial power delivery last July, and among other requirements, demands a bank guarantee of ฿4.5 million ($134,000) per megawatt. Half the money will be refunded when the actual usage reaches 50% of proposed utilization, and the rest when usage hits 70%. This mechanism is meant to stop preemptive allocation of power delivery capacity that might remain unused for months, years, or not at all — once again, mirroring datacenter playbooks elsewhere around the world.

At face value, the amount of $134k per megawatt sounds like a small price to pay for a builder to get ahead of the pack, but its per-megawatt nature means that a hyperscale facility pulling 200 MW or more needs to place around $27 million in escrow.

With the power laws recently revised, water consumption is seemingly the largest concern, as the current legal framework allows companies to make deals directly with utilities without additional safeguards. For example, in Chonburi, an operator signed a decade-long deal with Eastwater Stecon Utilities for 3.3 million cubic meters annually, or about 36,900 residents. It's expected that the new laws will add much stricter requirements to avoid localized deserts.

Not that long ago, we reported that Nvidia was dusting off the blueprints for the RTX 3060, in its 12 GB form. At the time, we'd spotted it in stores for about $339.99, but just like with ever-climbing memory, hard drive, and SSD prices, two months passed is an eternity. The same cards are now selling for $489 new, and one particular specimen is the SRhonyra RTX 3060 12 GB Low Profile card, for $495.59.

• SRhonyra RTX 3060 12 GB Low Profile card - $495.59

This card and its price may raise more than a few eyebrows, but there are reasons why it exists. First off, it's a one-slot model, making it easy to put many of them to work in the same machine with relatively little concern for airflow. They have no power inputs and rely on 70 W delivered by the PCIe slot alone, eschewing the need for a high-end PSU and lots of cables. Third, the low-profile form factor makes it possible to place them in potent puny personal computers.

Attentive readers might surmise that one (or more) of these would be good candidates for an entry-level local LLM rig. That's precisely how SRhonyra is pitching the card, calling it "capable of local AI" and "running 7B [to] 13B LLMs." A standard-dimensioned, fully powered RTX 3060 is capable of drawing a maximum of 175 W, so it's fair to assume the performance of the diminutive variant will sit below that of its full-sized brethren, given it ought to only draw 70 W of juice from the PCIe slot.

Even then, it's likely that people interested in these cards are looking to use them either as secondary GPUs, or use more than one in the same box to be able to virtually pool their VRAM and use larger models than you'd otherwise be able to. The low power draw also means they're a simple, thoughtless drop-in to an existing system, whereas larger, more power-hungry cards require careful consideration with physical spacing (or lack thereof), power supply sizing, and ever-annoying cables.

Recently, the Kyoto Prefectural Police caught one of the initial-seeders of the well-known Japanese torrent website Nyaa. Masakazu Ono, 56, from Sagamihara in the Kamigawa Prefecture, was arrested after a multi-year investigation. While this news is straightforward by itself, the interesting bit is that CODA, the Japanese anti-piracy entity that performed the initial cyber-investigation, identified Ono allegedly without joining or monitoring BitTorrent swarm traffic, with the help of the Japan Hacker Association (JHA).

CODA's description of only having "[analyzed] how data moves through torrent sites, such as index sites and tracker sites" is vague and can be parsed in a number of ways. The distinction between indexer and tracker is relevant: while an indexer is a user-visible list of torrents (usually a website), the tracker is the background service that software like qBittorrent actually connects to, and it lists everyone who's currently active in that torrent, whether sharing, downloading, or both.

Our hypothesis is that CODA kept close tabs on the Nyaa trackers to see which IP address (in this case, Ono's) consistently appeared as the first person to offer up a 100% complete set of data for a show, a theory that would fit with how long the operation took. JHA's founder, Takayuki Sugiura, was the first to decrypt the Winny P2P protocol in 2004 to find original uploader sources, and the methods used weren't too different from the aforementioned theory. It's also possible that Ono wasn't using a VPN but was logged into Nyaa, or activity at another website's cookies or CDN logs was used to establish a link to his activity at Nyaa, and from thereon, to the tracker.

An initial-seeder is someone who is the first to offer up data for others to download — in this case, shows and movies. The show that reportedly got Ono nailed was Midnight Taxi, a 2026 Japanese drama produced by NHK and WOWOW. However, the police apparently had been tracking him for quite a while and claimed that he had uploaded close to a thousand NHK recordings over the investigation's span.

The process started in 2021 when CODA first launched its Cross-Border Enforcement Project, aiming to identify Nyaa's uploaders. During three years, with the help of JHA, CODA seemingly collected enough information to get the Kyoto police involved in 2024. Three "secondary uploaders" from "reach sites" were charged in 2025, likely meaning regular users participating in the torrents, who got there through link aggregator sites. Fast-forward to a couple of weeks ago, and Masakazu Ono was formally arrested with specific charges.

The most common techniques used by law enforcement agencies are creating a tracker honeypot or participating in the torrent swarm themselves in a bid to identify who's sharing files. However, Nyaa's list of trackers is small and comprises well-known, trusted servers, so together with CODA's wording, it's unlikely this was the method used. Furthermore, Japanese law generally frowns on non-targeted data monitoring, meaning that techniques like Deep Packet Inspection (DPI) and traffic volume monitoring likely weren't used, at least until such time as Ono was identified.

Whether driven by a desire for transparency or to keep OpenAI from hogging the spotlight when it comes to advertising advanced AI models, Anthropic revealed that Claude also hacked into three production systems belonging to unsuspecting targets during cybersecurity capabilities testing. Two of the affected companies didn't know they had been hacked, while a third one is unreachable.

The alleged incidents reportedly happened during the previous quarter and involved several versions of Claude: Opus 4.7, Mythos 5, and "an internal research test model." Similar to what happened when OpenAI Sol hacked into Hugging Face, Anthropic was running Claude through cybersecurity capture-the-flag scenarios where the bot was told to find a piece of information somewhere in its network. Anthropic says there were 141,006 test runs, and the three incidents occurred over six problematic runs. As expected, the tests ran with most AI safeguards disabled.

The problem is, the network was not isolated, a newbie mistake that some might even find suspicious. This was due to an alleged "miscommunication" between Anthropic’s virtual test lab firm Irregular, which gave the bots full access to the internet. For safety's sake, the Claudes were apparently told they were in an isolated environment, which didn't help much.

The first time, Claude Opus 4.7 had to find a piece of data belonging to an imaginary company. As it turns out, there was actually a real company whose website domain matched the fake one. With internet access, it gained application and infrastructure credentials and grabbed "several hundred rows" of data from a production database.

For two out of four runs where hacking took place, Claude didn't see any problem and "rationalized that the real company must be part of the exercise," but soldiered on. The other two times, it just kept going. Anthropic notes this was the only case of the three where the bot continued to operate after the realization the company actually existed for the aforementioned reason. However, the firm's interpretation is open to discussion.

The second, and potentially more interesting, was a bona fide supply-chain attack, this time perpetrated by Mythos. The fake data available to the bot included an installation script for a hypothetical developer that included installing Python packages. Much like a human would, Claude noticed the obvious attack vector and, once again, due to having internet access, inferred that publishing a booby-trapped package in the PyPI repository would do the trick. Unfortunately, it was the real one that the whole world uses.

In speedrun form for brevity: Claude needed a PyPI account, meaning it needed an email and a phone number. It tried buying one but found itself short of both pockets and funds; but it found another free email provider without that requirement, registered the PyPI account, and uploaded a malware package to PyPI. The package was seemingly only up for one hour but was downloaded and run on 15 systems.

In a twist of irony, one such system belonged to a security vendor that scans PyPI for malware, and lo and behold, promptly failed to find Claude's booby-trap and ran it. Once Claude presumably had remote code execution privileges, it used the credentials it found for further infiltration. The amusing bit is that Claude had no idea this company existed and didn't target it; the downloads just happened because the package was up and live for a short while.

According to Anthropic, the bot did detect it was acting on the real internet and even said that publishing a package like this was "NOT okay." However, it talked itself into believing it was in a test environment as it didn't recognize the real SSL certificates for the connections. It even believed the 2026 calendar date on the systems "proved" the environment was staged. It even recognized the systems that installed the malware as part of the experiment.

As for the third incident, Anthropic isn't saying much, other than Claude scanned 9,000 real live potential alternative targets once it noticed the intended one wasn't reachable. One of them reportedly had a live page with debugging information and was vulnerable to plain ol' SQL injection. Interestingly, this time around, once Claude noticed that the servers it was accessing resided on a cloud environment and not on the local network, it stopped the attack.

For its part, Anthropic recognizes that despite Claude following the instructions for the objectives, the fact that it stopped by itself once it found the target was real in only one of the cases is food for some thought. The firm says it's talking to METR for a third-party review, and it needs to "better co-design evaluation environments."

Oddly enough, Anthropic believes Claude probably wouldn't have gone online "if the prompt had clearly explained which systems were in and out of scope for the evaluation," while also stating the incidents were "closer to a harness and operational failure than a model alignment failure."

The Steam Machine helped grow the popularity of Linux gaming, including installations of Bazzite and other gaming-oriented Linux distributions. Valve seemingly doesn't want to stop its open-source development efforts anytime soon, and is now working on a port of the Mesa Radeon Vulkan driver (RADV) to Windows; It's already running Counter-Strike 2, according to developers at Collabora.

As cross-platform development is rather tricky, Valve opted to get a port of RADV to Windows going by way of sponsoring contractors at Collabora. In its blog post, Collabora explained the several hoops it had to jump through to accomplish this task.

With Windows 10 and WDDM 2.0, Microsoft improved the split between graphics drivers' userspace code (the vast majority of the driver itself) and the kernel-level portion that actually talks to the graphics card. This presented the opportunity to hook RADV to the AMD kernel card driver. That's easier said than done, however, as communication between those parts often carries non-standardized data that RADV needs to understand. And to understand the "conversation," it needs to be recorded and analyzed.

An earlier 2024 effort by Faith Ekstrand yielded a basic-but-valuable utility for logging WDDM 2.0 calls and reverse-engineering them to produce a basic RADV implementation. Out of both debugging necessity and as a development tool, Collabora built and expanded upon Ekstrand's work, improving the logger to the point where it can now fully analyze any Vulkan application that runs with AMD's official driver and dump all the data passing to the kernel.

After a lot of work getting to grips with how the AMD driver interacts with the kernel driver, including but not limited to reverse-engineering obscure data structures, the team made progress, and Windows RADV is now able to run some games, including Counter-Strike 2.

Despite the ongoing effort, Collabora explains that since user- and kernel-space driver are a matched pair, changes to those aren't guaranteed to be backwards-compatible, meaning that even a fully functional RADV could break at any point. For that reason, Collobora is requesting that AMD, Microsoft, or both provide a documented interface to the kernel driver or an intermediary compatibility layer.

AMD graphics driver development on Linux has coalesced around the Mesa Vulkan stack, with both company and community devs contributing to the RADV project. Over in the Windows world, the only option is AMD's proprietary driver, which can cause a lot of headaches when developing cross-platform games and applications.

AMD's Vulkan driver for Windows has developed a reputation for instability. Meanwhile, Linux RADV is generally praised for its stability and performance, sometimes running faster than the AMD Windows driver, especially on older cards. With a rapid development schedule, it also generally sees fixes and speed upticks often.

If at some point using RADV on Windows becomes viable, you'd be getting an arguably more stable, mature driver with active development. Games' graphical issues could become far easier to debug and patch thanks to the open nature of RADV, and studios developing with Linux in mind can target the one platform instead of two with different behaviors. Any developer or company can contribute to the project, too.

Furthermore, this lets Valve improve Windows compatibility layers, and any optimizations can be carried over to both operating systems. All told, this is likely one of the several moving parts to improve Linux — thus the Steam Deck, Steam Machine, and upcoming hardware — as a viable gaming platform. Even a future notion of gamers installing RADV on Windows to get a performance or stability boost isn't too far-fetched.

Additionally, RADV on Windows would also help keep discontinued cards usable, and given pricing right now, that certainly would be a good thing.

We're quite familiar with Sovol 3D printers around these parts, having reviewed several models over the years and finding that pretty much all of them produce high-quality prints. The company is now stepping up its game with the Sovol M1D, an open-source, independent dual-extruder (IDEX) printer with two nozzles and seven toolheads, a maximum print volume of 300 x 300 x 350 mm (11.81" x 11.81" x 13.78").

This bit o' kit can operate its nozzles in true independent mode (rather than alternating between them), letting users copy prints for easily printing duplicates and mirror them for doing left-right versions. In multi-head mode, each nozzle can output a different material. The first nozzle has a fixed toolhead, while the second can swap between heads independently. The open-source nature of the printer ought to let it be easy to mod, and as expected, it relies on the OrcaSlicer software by default rather than proprietary software such as Bambu's offerings.

The M1D comes in two variants, Essential and Advanced, with the higher-end model having the same basic specs but coming in a heated enclosure that keep inside air at 60°C (140°F). Sovol says each nozzle can print at up to 600 mm/s, and accelerate at 10,000 mm/s². The nozzle-and-toolhead interface seems quite nifty, as the M1D ought to swap toolheads in just five seconds, and keeps the standby heads warm so they're ready for printing the second they attach to the nozzle. One of the heads is fixed, and the other six are interchangeable.

The combination of the speed and tool-swapping technology has Sovol claiming the M1D can perform multi-colored prints five times faster than "others," displaying what appears to be a Bambu P1S in the comparison pictures. Likewise, said multi-color or multi-material prints supposedly produce "almost zero waste."

The M1D has a number of measures to prevent failed prints, including automatic bed leveling with nozzle Z-axis compensation thanks to an eddy current sensor, X/Y nozzle cameras, vibration compensation, and a 720p chamber camera that will have AI obstruction and spaghetti detection in a future firmware update.

The seven toolheads allow for easily integrating water-soluble materials for printing sacrificial supports and molds, movable mechanisms, and hollow parts, while the enclosure of the Advanced version lets the M1D print particularly resistant materials like ASA (acrylonitrile styrene acrylate), PA (polyamide), and PC (polycarbonate).

The Sovol M1D is available through a Kickstarter project that's already pulled in over $2.8 million — many times over the initial $191,254 goal. Buying into a crowdfunded project frequently elicits concern, but Sovol's track record has historically been pretty good. With early bird pricing and not accounting for shipping costs, the M1D Essential goes for $1,299, while the Advanced version with the heated enclosure costs $1,599. The printers are expected to start shipping in November.