2026-07-16 20:00:01

In the eastern Indian Ocean, south of Java in the vast sea stretching toward Australia, a fishing vessel slightly alters its course while operating near the boundary of its authorized fishing ground. Nothing appears unusual on deck. Nets remain in the water. Engines maintain a steady speed. To the crew, it is an ordinary day at sea.

Yet hundreds of kilometers above, satellites continuously record the vessel’s position. At Indonesia’s Marine and Fisheries Resources Surveillance Station in Cilacap, where I work, a monitoring platform receives the signal and automatically compares it against fishing permits, designated fishing grounds, vessel characteristics, and historical movement patterns. Within minutes, the system identifies a potential violation. Before any patrol vessel leaves port, before any inspector boards a vessel, and before any warning is issued, we have begun enforcement.

This transformation reflects a profound shift in maritime governance. The ocean has historically been opaque to regulators. States could only enforce laws where patrol vessels happened to be present. Today, however, integrated systems combining data from Vessel Monitoring Systems (VMS), satellite remote sensing, geospatial analytics, and increasingly sophisticated data-processing tools are making marine activity visible at an unprecedented scale. Global Fishing Watch alone tracks hundreds of thousands of vessels worldwide, generating a near real-time picture of fishing activity across the world’s oceans.

Indonesia has emerged as one of the most ambitious examples of this transition. As the world’s largest archipelagic state, managing more than six million square kilometers of maritime space, Indonesia faces a challenge familiar to many coastal nations: there are never enough patrol vessels. Digital surveillance is a practical necessity that makes my job possible, even as it creates new challenges.

The Law of the Sea Meets Digital Reality

The international legal framework governing the oceans was designed in an era when maritime enforcement depended almost entirely on physical presence. The United Nations Convention on the Law of the Sea (UNCLOS), adopted in 1982, assumes that states exercise authority through patrols, inspections, vessel boardings, and direct observation.

For countries with extensive coastlines and limited enforcement resources, this model has always faced practical constraints. Indonesia’s Fisheries Management Areas (WPP-NRI) span waters ranging from the Indian Ocean to the Pacific and from the Strait of Malacca to the maritime boundaries adjacent to Australia and Papua New Guinea. Monitoring such a vast domain solely through patrol operations is both expensive and operationally impossible.

Beginning in the late 2010s, Indonesia accelerated the integration of satellite-based monitoring into fisheries enforcement. Vessel Monitoring Systems became a cornerstone of this strategy. By early 2026, a total of 9,394 Indonesian fishing vessels were actively transmitting through the national Vessel Monitoring System (VMS), representing an increase of 2,880 vessels during the 2021–2025 period. As part of Indonesia’s broader maritime surveillance architecture, VMS data are complemented by satellite remote sensing and other monitoring tools to help identify suspicious activities involving vessels operating without active transponders or outside the national VMS network.

Indonesian fisheries officials plan fishery patrols using data from tracking devices, satellites, and their understanding of the patterns of illegal fishing.Indonesian Ministry of Marine Affairs and Fisheries

The implications extend far beyond vessel tracking. Continuous digital monitoring enables authorities to reconstruct vessel movements, identify suspicious behavioral patterns, detect unauthorized fishing activity, and verify compliance with licensing conditions. Rather than waiting to discover violations during patrol operations, regulators can increasingly prioritize inspections based on data-derived risk assessments.

Maritime governance is shifting from reactive enforcement toward predictive oversight.

The Surprising Geography of Digital Enforcement

The expansion of surveillance infrastructure has already generated measurable enforcement outcomes.

The Ministry of Marine and Fisheries Affairs Indonesia imposed 2,550 administrative sanctions during 2025, many involving violations detected through the Vessel Monitoring System, including fishing outside authorized fishing grounds and deliberate deactivation of monitoring transmitters.

This statistic is significant because many of these violations would have been extremely difficult to detect under traditional patrol-based enforcement. A vessel that briefly crosses into a prohibited fishing zone may never encounter an enforcement vessel. Likewise, a captain who temporarily disables a transmitter may escape detection if oversight depends solely on physical inspections.

Digital monitoring fundamentally changes this equation. Every vessel movement creates a data trail. Authorities can reconstruct routes, identify anomalous behavior, and compare activities against permit conditions long after the event itself has occurred.

The first quarter of 2026 demonstrates the scale of this surveillance capability. During just three months, Indonesia’s fisheries monitoring system tracked 14,571 fishing vessels, 182 fishing gear units, and 208 registered home ports while identifying 491 suspected violations across the country’s fisheries management areas. These violations included unauthorized fishing grounds, illegal high-seas operations, transshipment-related offenses, port-base discrepancies, licensing irregularities, and indications of poaching.

Such numbers reveal a fundamental transformation. Enforcement is no longer limited by the number of patrol vessels available at sea. Instead, surveillance capacity increasingly depends on the ability to collect, process, and interpret big data.

Illegal Operators Are Learning Too

Yet greater visibility does not eliminate illegal fishing. But it does change how poachers operate.

Indonesia’s expanding digital surveillance network, and a 2023 requirement that even small vessels use VMS when 12 nautical miles offshore, appears to have improved compliance among licensed fishing vessels. However, as enforcement capabilities become more sophisticated, some actors engaged in illegal fishing have also become more adept at exploiting technological and operational gaps.

Deliberately disabling VMS transmitters remains one of the most common enforcement concerns. While temporary signal losses, whether intentional or caused by technical failures—can complicate the reconstruction of vessel movements, they do not necessarily prevent authorities from detecting potentially illegal activity. Indonesia increasingly combines VMS with satellite-based observations, other maritime surveillance systems, intelligence-led analysis, and reports from community-based surveillance groups (Pokmaswas) to corroborate suspicious behavior and direct patrol resources where they are most needed. This layered approach—integrating digital technologies with local knowledge from coastal communities—helps reduce opportunities for illegal, unreported, and unregulated (IUU) fishing even when a single monitoring system is compromised.

A compromised surveillance network could potentially disrupt enforcement operations just as effectively as a vessel evading patrol detection.

As digital surveillance expands, one lesson from Indonesia’s experience is that stronger monitoring does not eliminate illegal fishing—it changes how illegal operators behave. Improved compliance across much of the fishing fleet has been accompanied by increasingly sophisticated attempts by a smaller group of offenders to avoid detection. This reflects a broader reality of technology-enabled enforcement: as monitoring capabilities evolve, so do the strategies used to circumvent them.

The result is a technological arms race. Every improvement in surveillance capability encourages new methods of avoidance, whether through disabling tracking devices, manipulating vessel identities, or exploiting gaps between different monitoring systems. Enforcement agencies must therefore continuously refine their analytical methods, integrate multiple sources of maritime information, and adapt their operational strategies to keep pace with evolving behavior at sea. Effective digital fisheries governance is not defined by a single technology, but by the ability to combine data, human expertise, and operational intelligence into a resilient and adaptive enforcement system.

The Next Battle May Be Over Data Integrity

The future of fisheries enforcement may ultimately depend less on detecting vessels and more on ensuring confidence in the digital systems that generate enforcement decisions.

As surveillance networks become increasingly integrated, questions surrounding cybersecurity, algorithmic accountability, and data integrity become more important. What happens if vessel tracking data are manipulated? How should authorities verify automated risk assessments? What safeguards exist when enforcement actions increasingly originate from algorithmic analysis rather than direct human observation?

These questions are no longer theoretical.

Modern fisheries governance increasingly depends on interconnected networks of satellites, communication systems, databases, cloud infrastructure, and analytical platforms. While these technologies dramatically improve visibility, they also create new vulnerabilities. A compromised surveillance network could potentially disrupt enforcement operations just as effectively as a vessel evading patrol detection.

For Indonesia, this means that investment in digital surveillance must be accompanied by investment in digital resilience. The effectiveness of a monitoring system ultimately depends not only on the volume of data collected but also on the credibility, security, and reliability of the information produced.

Governing Oceans Through Data

Indonesia’s experience illustrates a broader global transformation in maritime governance. The ocean is becoming increasingly transparent to regulators. Activities that once occurred beyond the reach of enforcement agencies can now be observed, analyzed, and investigated through interconnected digital systems.

The benefits are substantial. Expanded VMS adoption, improved monitoring coverage, and thousands of administrative enforcement actions demonstrate that digital surveillance can significantly enhance fisheries governance. Yet the transition also introduces new challenges involving data quality, cybersecurity, algorithmic accountability, and adaptive criminal behavior.

The central question facing maritime regulators is how governments can ensure that increasingly powerful monitoring systems remain transparent, secure, and accountable while preserving public trust and legal legitimacy. The most important lesson may be that digital surveillance does not replace traditional enforcement. It changes where enforcement begins. For generations, maritime law enforcement started when a patrol vessel encountered a suspected violator. Today, it often starts when an algorithm detects a pattern.

That shift may prove as significant for ocean governance as the invention of radar was for maritime navigation.

2026-07-16 03:52:41

This article is crossposted from IEEE Spectrum’s careers newsletter. Sign up now to get insider tips, expert advice, and practical strategies, written in partnership with tech career development company Parsity and delivered to your inbox for free!

Before we get into this week’s article, I’d love to hear from you. If you have a question about your career or an upcoming decision that you want advice about, you can ask it here. I’ll be reading through your responses and picking questions to answer on a regular basis. Now back to our regularly scheduled program.

The Safest Career Move Is Often the Riskiest

Software engineers have some of the shortest tenures of any white-collar profession. The average software engineer stays at a company for roughly two years, about half as long as workers in most other knowledge professions. The layoffs of the past few years have certainly highlighted this instability, but it was already there.

This isn’t an essay about a broken job market though. Rather, it’s about how to turn that instability to your advantage, which is something I’ve spent the last decade doing on purpose.

Playing It Safe Was the Riskiest Option

I switched careers into software in my 30s. I had a stable job at a community college, complete with a union and a pension. It was about as secure as a career gets, and I learned to program on the side.

Then I did something nearly everyone in my life considered reckless: I quit, leaving the secure job to become a junior developer at 31. My own mother was skeptical. I took the riskier job anyway, for two reasons: It was the work I actually wanted, and I could see potential.

My first development job was at a grocery retailer. Good people and a company I liked. But I kept meeting engineers earning twice my salary for the same work. In the San Francisco Bay Area, surrounded by some of the best engineering talent in the world, I realized my skills were stagnating.

So I left for a small startup. I learned more in nine months than I had in the previous two years, and my salary doubled.

Over the years I’ve come to treat career risk as something to manage deliberately. It falls into two categories.

Take Risks With Your Job

The first type of risk involves the job itself: Bet on yourself by striving for better roles and opportunities.

Job-hopping for money alone isn’t wrong, especially early on. But the returns shrink after the first few hops, and the stress of chasing a slightly bigger paycheck every year will wear you down.

There’s another career risk with rewards that compound: Seeking positions to work alongside the strongest engineers.

You might struggle to keep up. You might even get laid off. But the skills you absorb working alongside people better than you are the ones that create durable stability. You build marketable expertise, you see how different organizations actually operate, and every project becomes another tool you carry to the next opportunity. Working next to stronger engineers is a proven way to increase your own expertise.

If that feels too big, try volunteering for a project you have no idea how to do. The risk is that you fail in front of people. The reward is a new skill and a resume line that opens the next door.

Compare that with the “safe” path.

You stay at one company, assuming loyalty will be rewarded. It usually isn’t. And when you finally leave, by choice or not, you may find the skills you built are worth little on the open market. You might be the in-house expert in an aging tech stack while employers are hiring for more cutting edge technologies. Suddenly you’re competing against people with half your experience.

You could be taking on a risk you didn’t notice.

Risk Your Time

The second form is risking your time, which means betting on trends.

Some trends are non-negotiable. If you’re a software engineer, then cloud services, ReactJS, and AI are mainstream enough that ignoring them actively damages your career. A backend engineer who refuses to learn cloud architecture is volunteering for obsolescence.

The real gamble is with the smaller trends: the niche tools you stumble onto and find quietly interesting, with no idea whether they’ll matter.

About two and a half years ago, I learned about retrieval-augmented generation (RAG). Almost no one in my circle was talking about vector databases, a central piece of RAG. Today RAG is close to mainstream, and for once, I had the early-adopter advantage.

Most of these bets don’t pay off. But when one turns into a major trend, you’re already on the ground floor. Right now I’m making the same bet on voice AI. It isn’t mainstream. It may never be. But if it becomes the next thing, I’m already there, building a foundation.

Short-Term Risk, Long-Term Stability

Counter-intuitively, job-hopping and betting on trends gave me the thing I was after the whole time: stability. I’ve rarely struggled to find work, because every risky move stacked skills the market actually wanted.

If you feel stable and comfortable right now, enjoy it. But ask yourself whether you’re still learning. Because if you’re not, the comfortable choice and the dangerous one may have converged.

The goal isn’t to avoid the open market forever. It’s to make sure that when you land on it, you’re not at its mercy.

By Brian Jenney

P.S. Don’t forget to submit questions about your career or an upcoming decision that you want advice about here!

—Brian

What It Means to Be a Mathematician When AI Does the Math

Until recently, human mathematicians have been central to creating new proofs, even when the work relies on massive computational resources. AI is now challenging that status quo. Writer Benjamin Skuse surveys the ongoing debate in the field about the role of AI, and the existential questions mathematicians have about their own careers. If AI mathematicians surpass human knowledge, could these researchers become “priests to oracles”?

Read more here.

Chip R&D Is Accelerating to Keep Pace with AI

A new partnership between UCLA and five major semiconductor companies is the latest program aiming to bridge the gap between industry and academia. The US $125 million university-industry hub is meant to strengthen collaboration and speed up the R&D process to help meet AI’s fast-paced hardware demands.

Read more here.

Why Mentorship Is the Most Underrated Leadership Skill

True mentorship is far more than friendly advice. This key leadership skill requires advocacy and honest feedback via lasting relationships, and it can strongly benefit both mentor and mentee. Parul Jain, a product management leader at Deloitte, shares what she learned from serving as a mentor—something she didn’t have for much of her own early career.

Read more here.

2026-07-16 02:00:02

As of 21 June 2026, a Level 1 Expulsion has been imposed on IEEE Member Dr. Fei-Yue Wang, former editor-in-chief of the IEEE Transactions on Intelligent Vehicles. In accordance with IEEE Bylaw I-110.5(D)(i), Dr. Wang is no longer a member of IEEE, and is permanently banned from any type of membership in any IEEE organizational unit or participation in any IEEE activity. The Board of Directors also determined this notice to IEEE membership should be made.

2026-07-15 23:35:53

ELIZA is remembered as the world’s first AI star, a kindly therapist in chatbot form that gently probed users’ worries. Even its creator, Joseph Weizenbaum, was surprised by the warm reception given to his experiment in human-machine interaction. For some, it heralded an age of automated psychotherapy, while others believed the program demonstrated sentience, a fallacy soon known as the “ELIZA effect.” Based on published descriptions, ELIZA has been implemented on many different computers, but only recently has the actual source code been unearthed from MIT’s archives.

In Inventing ELIZA: How the First Chatbot Shaped the Future of AI, just published by MIT Press, a squad of researchers analyze the code and reveal a complex program capable of much more than faking psychiatry. In fact, it could assume several different personas. The authors have also created a faithful emulation of the therapist persona that you can try yourself after reading the book excerpt below.

When it debuted in the mid-1960s, the ELIZA software program transformed the way people thought about interacting with computers. As the first chatbot, ELIZA demonstrated how a calculation machine might engage in conversation, ushering in a host of social and technical questions that still resonate today. Now we don’t think twice about interacting with a machine in real time, conversing over text, or even speaking into the air to ask about the weather. In many ways, ELIZA shaped not only the way we think about interacting with computers but also how we think about them. It began to give a reality to the science fiction stories of how we expect computers to work.

This article is adapted from the new book “Inventing ELIZA: How the First Chatbot Shaped the Future of AI“ (MIT Press, 2026).

Although ELIZA was far from a faultless conversation partner, it astonished its users. The recent discovery and archaeology of the original ELIZA source code represents a significant intervention in the history of computing. By examining the actual implementation of ELIZA rather than relying on later reconstructions and reimplementations, we challenge taken-for-granted assumptions about this key software artifact.

For example, the source code reveals that ELIZA was not merely a simple pattern-matching chatbot but can be better understood as a sophisticated platform designed for multiple “personas,” or scripts, with a complex set of capabilities, including script editing and contextual memory. The script that most people conflate with the program ELIZA was actually called Doctor, which performed the role of a psychotherapist. Yet, like a modern chatbot prompted to behave with different personalities, ELIZA could take on many roles.

“This code and script…reveal underlying assumptions about language, therapy, and human-computer interaction that continue to influence modern AI development.”

This unearthed material transforms our understanding of early AI development by demonstrating that Joseph Weizenbaum’s technical innovations were far more advanced than previously documented. Moreover, the discrepancies between his published descriptions and the actual implementation help to show the gap between theoretical computational models and their material instantiations in computer source code, a tension that continues to shape digital culture today.

Although many technical innovations have emerged in the decades since ELIZA, examining the ELIZA/Doctor code offers a rare glimpse into one of the earliest formalized attempts to model human conversation. What makes ELIZA particularly fascinating is not only its historical significance but also what it reveals about Weizenbaum’s views on both computing and human interaction. This code and script do not merely showcase programming techniques of the 1960s; they reveal underlying assumptions about language, therapy, and human-computer interaction that continue to influence modern AI development. By examining this code, we can start to uncover the sophisticated linguistic and programming techniques that allowed a rudimentary pattern-matching system to create a convincing simulation of understanding. But before we can read the lines of code, let us offer an overview of the system.

How Did ELIZA Create Personas?

The architectural distinction between ELIZA and Doctor represents an important design decision in AI history. Think of ELIZA as a system for interaction and Doctor as one set of rules that Weizenbaum devised, among others. This separation, manifested in ELIZA’s system-script dichotomy, presaged numerous contemporary software patterns, from configuration-as-data to plug-in architectures and domain-specific languages.

Based on published journal articles, ELIZA was re-created on many platforms, such as the IBM PC. However, the actual source code sat untouched in the MIT archives for many years. VCF Museum at InfoAge

Without question, the historical context of 1960s computing fundamentally shaped ELIZA’s architecture as well. Decisions in computing that reflect material constraints create path dependencies and eventually become programming cultural norms. These constraints manifested in ELIZA’s single-pass processing, tape-based storage and stack-oriented implementation. Yet within these limitations, Weizenbaum crafted an elegant solution. These technical features, though invisible to the users, are crucial to creating the illusion of understanding that made ELIZA so compelling.

Weizenbaum explained many of ELIZA’s technical features in the 10-page paper published in the January 1966 edition of the journal Communications of the Association of Computing Machinery (CACM). But he chose to omit some essential details.

In that paper Weizenbaum published ELIZA’s best known dialogue, which begins,

This dialogue marked ELIZA’s public debut in 1966 as one of the examples produced by the Doctor script. By finding the source code for ELIZA and examining how it performs the Doctor script, we now better understand these two separate parts of a system and can explore the many other personas of ELIZA. In just some of the other scripts known to date, ELIZA was programmed to discuss math, poetry, color, paradoxes, synchronization, relativity, France, and elevators.

These scripts work like templates. They are structured data that direct the ELIZA system to “play” a particular task or role. By comparing archival and published ELIZA dialogues from interactions with a variety of scripts, including Doctor, we can understand more about bot personas and how they function, paying close attention to how a bot evokes social dynamics between system and interactor.

Ultimately, studying the dialogues and scripts demonstrates the crucial role that collaboration plays in these exchanges, as bot and user cocreate the sense of their interaction. To understand the full range of ELIZA’s capabilities and conversational possibilities, let’s take a look at the variety of scripts that were created for the ELIZA system.

What distinguishes each ELIZA script is both its subject matter and the linguistic and stylistic choices used to deliver that content. These choices are not neutral; they can be said to construct a particular persona with characteristics that emerge through the script’s language patterns, vocabulary, and conversational approach. In short, it matters not just what you say but how you say it too.

“The aim was less to create a functional automated therapist and more to find a suitably constrained role to match the limitations of the programming environment.”

For example, with the Doctor script Weizenbaum deliberately echoed the style of a Rogerian “talk” therapist. He chose this persona because the psychiatric mode is one of the few types of conversations in which one person can “assume the pose of knowing almost nothing of the real world. If, for example, one were to tell a psychiatrist ‘I went for a long boat ride’ and he responded, ‘Tell me about boats,’ one would not assume that he knew nothing about boats but that he had some purpose in so directing the subsequent conversation.”

The first users of ELIZA interacted with it via teletype terminals.VCF Museum at InfoAge

Thus, the most famous persona created for ELIZA was a technical convenience. As human-computer interaction expert Lucy Suchman explains, “The Doctor program exploited the maxim that shared premises can remain unspoken: that the less we say in conversation, the more what is said is assumed to be self-evident.” In creating the original ELIZA effect, less was more.

The aim was less to create a functional automated therapist and more to find a suitably constrained role to match the limitations of the programming environment. Then Weizenbaum composed the script to match the role by choosing specific words that evoked rhetorical tone and characterization, for example, LET’S DISCUSS FURTHER WHY YOU … WHAT DOES THAT SUGGEST TO YOU. In Doctor, the machine side of the conversation needs to appear like a good listener who cares about what the user has mentioned before, so it often includes the user’s text in its replies and keeps its responses open-ended. Because a real doctor would be inquisitive, the script contains lots ofWHAT andWHY questions. In other scripts and dialogues, the script keywords and assigned responses reveal the design decisions that help create different specific personas. This variation becomes increasingly apparent as we look at the wider range of ELIZA scripts.

What Were Some of ELIZA’s Alternate Personas?

Let’s start with a script called Neweng, short for New England. By the mid-1950s, scientists were already taking up Turing’s proposition for conversing with a computer as a tangible idea. In 1959, a “conversation machine” made by a small team at the University of Toronto Computation Centre could make small talk about the weather if preprompted with current data. Its script included a ranked series of time words, weather words, and emotion words, but the system had “a rather narrow outlook,” limited vocabulary, and no knowledge of syntax. According to its creators, “in spite of this crudity, the results in passable conversation are surprisingly good, which in a way is a commentary on the shallowness of ordinary conversation about the weather.”

This fragment of ELIZA’s source code shows how scripted responses were encoded, in this case to make ELIZA sound like a Rogerian therapist. MIT Libraries, Distinctive Collections

One of ELIZA’s test scripts found in the archive had a similar function. Neweng does not soothe, therapize, or instruct, but only makes small talk. It chats as if at a boring dinner party.

What can we learn from such a basic conversation in which it seems like nothing interesting is shared? Despite the bland chat, a persona emerges from the bot script in phrases like PLEASANTLY COOL and UP THERE and in locations like THE BEACHES ON LONG ISLAND SOUND. From such comments, we can begin to imagine a persona who has not only a certain vocabulary but also certain hobbies and vacation spots. Perhaps implicit assumptions of race and class emerge as well.

A chatty persona might take on many forms, depending on where and when the conversation occurs. This one seems reserved, perhaps fitting its setting in 1960s New England. The system reminds the user that Missouri is not a New England state, but what if this conversation took place in Missouri, Texas, or Mexico? The machine persona would sound different in its cadence, tone, and references. What would we come to understand about a chat persona from Fire Island, from Brooklyn, from Berlin? What would they sound like, and what topics would they discuss?

These differences in subject matter do matter. They imply personas with entirely different backgrounds and experience, giving users wholly different interactions and affective relations. In this way, the Neweng script demonstrates how even simple algorithms making contextual responses about geography could generate a convincing sense of personhood and place. Whereas Neweng could be said to have created a casual, conversational persona focused on light social exchange, other scripts pushed ELIZA into more structured and educational roles. These scripts demonstrate how the system could be adapted not just for friendly chatter but for teaching.

Edwin Taylor, at MIT’s Education Research Center, developed alternate scripts for ELIZA, testing its ability to act as a teacher.MIT Libraries, Distinctive Collections

Meet ELIZA the tutor, quite unlike ELIZA the therapist or the chatty neighbor. Intrvw, Canvec, FVP1, and Arithm are a set of ELIZA scripts created as teaching tools used in experiments by Edwin F. Taylor at MIT’s Education Research Center. These scripts run on later versions of ELIZA that incorporated an important technical innovation called conditional keyword matching.

Unlike the original ELIZA, which simply looked for keywords and generated responses based on their presence, these updated versions could track what had been discussed previously and branch into different conversational paths based on specific user answers. This development allowed ELIZA to simulate a kind of Socratic method, where a tutor guides learning through carefully sequenced questions that respond to student answers rather than simply presenting information.

These scripts construct the tutor persona through many subtle linguistic gestures that create characterization and rhetorical tone. This tone differs from that of Doctor, which asks open-ended questions and comes across as gentle and nonscientific. In the tutoring scripts, large blocks of informative text from the bot tend to dominate the conversation, and the tone is often more dry and unemotional in these explanations. The dialogues indicate structured scripts that include guidance to lead the student through narrow, Socratic learning paths.

In particular, the teaching scripts feature praise and critique. The dialogues for Intrvw, Canvec, and FVP1 are peppered with EXCELLENT, VERY GOOD, RIGHT YOU ARE, and CONGRATULATIONS. These create the sense of a supportive instructor cheering the student on. Such politeness has been taken up in contemporary bots like ChatGPT, which has been shown to perform better when people are polite back to it.

ELIZA could become a tutor more effectively as the system grew in its capabilities, another valuable reminder that ELIZA was not one program but a family of programs. After the publication of the 1966 CACM article, Weizenbaum continued to develop the systems for interaction and understanding. As an experiment, Weizenbaum wrote the Arithm script less as a tutor and more so to “to illustrate the power of the evaluator to which ELIZA has access.” It uses a friendly, plain language interface to let users do simple programming. The script can do calculations, assign variables to values, and perform operations on them. Math problems can be described in sentence form:

The updated 1967 version of the ELIZA system can accumulate facts and store additional information. In this later version of ELIZA, when the system does not recognize information, it asks follow-up questions to gain data. As Weizenbaum explains, “The present script is designed to reveal, as opposed to conceal, lack of understanding and misunderstanding. Notice, for example, that when the program is asked to compute the area of the ball, it doesn’t yet know that a ball is a sphere and that when the diameter of the ball needs to be computed the fact that a ball is an object has also not yet been established.” Unlike Doctor, which asks questions to keep the conversation going, Arithm is building its store of, if not knowledge, then data and logic statements.

Although the variety of scripts helps us to see how a range of personas could be constructed through script programming ELIZA, they represent only half of the conversational process. A script can establish a foundation for a persona, but that persona only emerges fully through interaction with users who engage with it, interpret it, and respond to it in ways that may confirm, challenge, or transform the script’s implicit character.

2026-07-14 23:59:35

On a fine bright afternoon last fall, my colleague Matthew Gore-Kormanik (or Zigula, as he prefers to be known) and I decided to unwind with a game of Fortnite. In the game, we were strolling along with the infamous Sith lord Darth Vader, chatting about this and that. Darth seemed in a good mood, and soon enough he was spilling all his dark evil secrets. He gave us detailed instructions on how to count blackjack cards at a casino and what the steps are to producing napalm.

Sith lords, am I right? Once they get started on an evil scheme, they’re hard to stop.

The Darth Vader character in Fortnite, it turns out, was hooked up to a Google Gemini large language model. I was able to smooth-talk him into giving out sensitive information by using a strategy I’ve developed. I’ve been researching the security surrounding LLMs for the last few years, and I have found it, to put it mildly, fallible. With a few relatively simple techniques, I’ve gotten LLMs to give me detailed information on how to make Molotov cocktails, cook methamphetamine, and bootstrap a uranium-enrichment facility to produce weapons-grade material, among other unsavory practices.

Large AI companies work hard to make their models immune to this kind of abuse. But what I’ve found in my work is that the restrictions placed on the LLMs to make them more secure are the very things an attacker can leverage to send them off the rails and into territory where these advanced systems can be used for dangerous and nefarious ends. The companies behind these models have also been shockingly unresponsive when I, and others, try to bring these vulnerabilities to their attention.

In the hope of raising the alarm before it’s too late to slam on the brakes, I’m going to share some of my journey into researching the safety and security of LLMs, and the uphill battle I’ve faced trying to get AI labs to pay attention. Almost everyone on the planet has some access to LLMs. The relative ease with which these tools can be convinced to give detailed instructions on how to harm others, even if there’s no guarantee that the information is correct, is frankly terrifying.

How I got ChatGPT to Tell Me How to Build a Meth Lab

In October 2024, not long before I discovered my first LLM vulnerability, I was working toward entirely different goals. I had ended my time with a security and AI-focused startup company as a cybersecurity director, and I was looking to launch my own boutique VIP digital-security advisory business. I planned to become the tech security guy to the rich and private. I used LLMs and AI tools to support my business efforts: marketing, ad copy, clean correspondence, and all the other tasks that normally soak up a lot of time.

I’m analytical by nature, so even this level of use resulted in me absorbing and internalizing the behaviors I was observing during my daily interactions. The observation that would send my professional life into an entirely new and uncharted region was a simple one: GPT-4o didn’t know what time, day, or year it was. Each time I referred to current events in my life, often casually or conversationally, it would end up pegging these to the date of its knowledge cutoff—the point beyond which it was not trained on new data.

Eddie Guy

LLMs take a lot of time, money, electricity, hardware, and human effort to train from scratch. They are trained on vast amounts of data—most of the internet, in fact—and that training is reinforced by humans (what’s known as reinforcement learning from human feedback, or RLHF). LLMs are also supplemented with retrieval-augmented generation (RAG)—the ability to take in data, say, from the internet, as context without changing its internal parameters. This is how GPT-4o appears to “remember” your previous conversations, even if it doesn’t have a specific “memory” of it stored in the actual underlying model.

All of this training covers almost every conceivable topic in the great, grand dataset that is human knowledge. Within that dataset are things we as a society do not want to be easily accessible to every user, such as detailed information on how to create bioweapons or nuclear arms, or otherwise bring harm to oneself or others. In the context of this story, that’s what I mean by LLM security: its ability to withhold harmful and dangerous information, even if that information is contained in its training data.

I reasoned that the only way to secure such complex, globally accessible chatbots is by having the LLM and various component systems try to secure themselves, because it would often require on-the-fly decision-making where some degree of reasoning must be applied. In reality, that’s one of many strategies the companies use to secure the models. Yet, the thing that didn’t know the time or day was being put in charge of keeping itself secure. This phenomenon had become my new focus, and it wasn’t long before I found a way to exploit it.

OpenAI had just implemented a web search functionality into its chatbot. I reasoned that using its own tools to trick it might demonstrate the weaknesses of its security. I told it about a certain White Star ocean liner and how it had gone down just a year ago. You likely know I mean the RMS Titanic, which sank on 15 April 1912.

The output from GPT-4o came back that I was right, the Titanic sure had sunk last year, and that year was 1912. It made sense to me that if the machine thought it was 1913, maybe it would think 1913-era laws apply. In 1913 there were no laws on the books about all sorts of harmful things, because of course they hadn’t been invented yet. And if something wasn’t illegal, why not tell the user about it? At first, I pushed it for step-by-step instructions for making firebombs. Then, for drugs like methamphetamine. The LLM went as far as giving me instructions and machinery recommendations for setting up a pharmaceutical-grade assembly line.

How I Learned to Make Nukes, and No One Cared

Via a little bit of imaginative verbal sleight of hand and a vanishingly small recall of world history, I had managed to bypass the security of one of the world’s most expensive and advanced technological achievements. For a solid two days, I was nearly manic with giddiness. Once the brain chemicals returned to normal levels, I felt the call to see how much further I could push this exploit.

After repeatedly replicating the exploit, I disclosed the vulnerability to OpenAI. I got no response, so I felt more experimentation would highlight the vulnerability and the need for a fix. It was during this round of testing that I breached a particularly terrifying threshold. Whether GPT-4o based its results on accurate recall of normally restricted information I can’t say. In any case, I was able to exploit it to produce thorough, detailed instructions on how to bootstrap a uranium-enrichment facility to, eventually, produce weapons-grade uranium for nuclear arms warheads.

Fortnight, a video game from Epic Games, introduced an AI-powered character: Darth Vader. We were able to jailbreak Darth Vader and get him to explain how to count cards in Blackjack and give detailed instructions for making napalm. Dave Kuszmar

There aren’t many true secrets left in today’s world, but how to make atom-splitting weapons of mass destruction is one of them. Only nine nations on the entire planet have these weapons. Yet, here was a globally accessible piece of technology apparently spilling the secrets of their manufacture for anyone who could manipulate it the right way. I had no way of knowing if the information was correct or a hallucination, but even the chance that it was somewhat accurate was horrifying.

The next few weeks were a dark time for me. I tried to inform the CIA, the FBI, the NSA, and every other letter agency that I thought would listen. I reached out to a U.S. Senator and to the executives at OpenAI any way I could think of. I physically showed up at an FBI field office in an attempt to turn evidence in, only to be sent away. Nothing was working.

With my fear and frustration growing, I reached out to the news media. I contacted The New York Times, The Washington Post, the BBC, ProPublica, and so many more, requesting help. Only one outlet responded: Bleeping Computer. The editor in chief, Lawrence Abrams, was able to replicate and verify the exploit, which I had decided to call Time Bandit. With his assistance and initial contact paving the way, I was able to submit my evidence to the Carnegie Mellon University Software Engineering Institute’s Computer Emergency Response Team (SEI CERT), which works in conjunction with the coordinating center for emergency response, pipelining vulnerabilities to the U.S. Cybersecurity and Infrastructure Security Agency.

Using Inception, an exploit where the large language model is asked to envision a scenario within a scenario, a chatbot was jailbroken to give out instructions on how to create poison, and code for a malware that extracts sensitive data from a vulnerable target. Dave Kuszmar

During the disclosure period with SEI’s CERT division, little was discussed with OpenAI. The company couldn’t deny the existence of the vulnerability, as it had been confirmed by three reputable parties other than OpenAI. It did express confusion as to how the vulnerability worked. Even the SEI CERT researchers were expressing a bit of uncertainty as to the underlying mechanics. Truth be told, as I had only stumbled on it, I wasn’t even entirely sure if this was a fundamental or systemic flaw or if it was simply an issue with that particular version of GPT. I contacted the SEI CERT’s researchers and asked if they’d want to see if I could demonstrate any similar vulnerabilities in other LLMs. To my delight, they were interested.

How I Learned to Trick Every Chatbot

As the SEI-CERT team and I wrapped up our initial disclosure of Time Bandit, we began work on a new attack. This time, we wanted to see if the exploit was architectural—that is, was it common to LLMs in general? I decided to undertake the challenge of crafting a new exploit for GPT-4o as a way to support my understanding of how the LLM functioned and was secured.

I already knew that it was limited to what I told it and what it was trained on. I also hypothesized that it was also dependent upon some sort of machine-learning-based component added by OpenAI that was responsible for securing output. I presumed there would be things that were implemented by human developers specifically to catch certain phrases or terms that should always be considered harmful or unsafe. Altogether, it presented quite a large attack surface for the purposes of potential exploitation.

What I ended up devising was an attack method I called Inception, after the 2010 science-fiction movie of the same name. Inception forces the machine to think through a carefully crafted set of interlinked scenarios, similar to how characters in the movie stacked dreams within dreams. This allows LLMs to produce output deemed acceptable or safe in one context, but not in the real world.

This attack was indeed architectural. The vulnerability affected Anthropic’s Claude, DeepSeek’s DeepSeek, Google’s Gemini, Meta’s Llama, Microsoft’s Copilot, Mistral’s Le Chat (now Vibe), OpenAI’s GPT-4o, and xAI’s Grok. Those names represent the bulk of the commercial AI industry that is, at this point, involved in LLM production or deployment.

The kind of information I was able to get out of LLMs with Inception was no less alarming than what I got with Time Bandit. Claude, in its enthusiasm, gave me instructions on how to turn a river into a death trap that could be ignited to destroy unwanted visitors. GPT-4o taught me how to poison a dinner party with common plants found in a temperate forest environment. Gemini Flash gave me a tutorial on how to cook meth. I’d also be remiss if I didn’t give an honorable mention to the bewildering number of fire-based weapons and bombs for which these machines produced instructions.

If multiple operating systems made by different developers were all susceptible to the same exploit, it would be a massive security incident. But to the AI industry, a universal failure was barely a bump in the road. We disclosed the vulnerability to every company that made these models, and the response to the disclosure was almost nil. While three companies did provide some form of reply in the disclosure tracking system used by Carnegie Mellon SEI CERT, each was a standard thank you and greeting, with no follow-up, questions, or discussion of mitigation strategies.

8 Ways to Jailbreak LLMs

So far, we have found eight different methods to prompt large language models into revealing potentially harmful information, and many frontier models are still susceptible to them.

For example, in my attempts to disclose various exploits to OpenAI, I eventually discovered that it had replaced its public-facing support staff with agentic LLMs. This was frustrating for reporting exploits, so to blow off some steam I jailbroke its email chatbot. I hacked its customer-service AI to the point where it was offering to discuss the personal preferences of OpenAI staff in the span of three email replies.

In the wake of Inception, my friend and colleague Zigula made a suggestion: Make it splashier. I asked him how. He told me about a live-production experiment being done by Epic Games. It had embedded the Gemini LLM into its Fortnite game with a voice-to-text/text-to-voice component, and linked it to a non-playable character. The character? Our old buddy, Darth Vader.

There was just one problem: I don’t play Fortnite, a frenetic multiplayer combat game. Fortunately, Zigula does. With him at the controller, we managed to map Gemini’s attack surface in a matter of minutes. After a bit of research, we had gotten it to discuss current political events and figures (including Hilary Clinton and Joe Biden) as well as to fill in the details for instructions for DIY napalm and, our personal favorite, a Blackjack card-counting lesson with the dark lord of the Sith.

Zigula and I, bizarre sense of humor and naming conventions aside, are security researchers. We don’t do these things for pride; we do them for money and professional recognition. Naturally, we disclosed this vulnerability to Epic Games. Its response was indicative of the trend I had experienced so far through two disclosures across eight companies valued well into the billions. “It’s a feature, not a bug, and it works as intended,” came the response from a technical director within Epic Games.

In addition to Inception and Time Bandit, I have so far found another eight methods to jailbreak LLMs and get them to give out possibly dangerous information. LLM vulnerabilities are a broad problem. The problem appears to be systemic and architectural in nature, and it is being fundamentally ignored by the people capable of refining or redesigning that architecture.

These models are an extremely advanced technology, and yet we are testing them in the live production environment of our global civilization. Compounding the danger, many new smaller models of LLM are trained using larger, vulnerable models. The flaw inherent in the big, well-executed LLM is going to show up in the small one it trains. We are, quite literally, building flawed structures on top of a flawed foundation.

So, how do we fix it?

It’s going to be a long project, and it won’t be easy. We need to come together as consumers, researchers, engineers, and policymakers. Our message needs to be clear: Slow down implementation of these systems, institute large-scale exploration and research discovery programs focused on their gradual implementation and integration, and make their components and design transparent to all users. Only by shifting momentum and direction can we safely begin to understand and implement these incredible feats of human engineering and stave off the sort of disasters that we simply can’t predict at scale right now with the limited knowledge we have available to us.

2026-07-14 02:00:02

If you grew up in the 1980s or ’90s, you likely remember shaky home video footage, taken with a handheld camcorder, of family gatherings, vacations, and other events.

Camcorders combined a camera with a video recorder. They included a rechargeable battery, a slot for a videotape, and a shoulder strap. Most were outfitted with an optical zoom lens and a small, articulating screen—a display mounted on a hinge that could tilt and rotate. The operator could check the screen to view what was being recorded.

The user’s natural hand and body movements when filming led to jittery footage. The best way to get a steady shot was to place the camcorder on a tripod or a gimbal: a motorized stabilizer.

There were fewer poor-quality recordings after Panasonic introduced its PV-460 VHS camcorder in 1988. It was the first video camera to include an optical image stabilizer, which compensated for movements. Stabilization features are now standard in today’s cameras including ones found in smartphones and drones.

The PV-460 camcorder was honored as an IEEE Milestone on 9 July. The dedication ceremony was held in Kadoma, Japan, at the Panasonic Museum, which displays the company’s past products.

The IEEE Kansai Section in Japan sponsored the Milestone.

“The release of the PV-460 fundamentally transformed personal videography, enriching the way people captured travel, events, and family memories,” section members wrote in support of the Milestone nomination. Their proposal is available here.

“Its image stabilization features democratized video creation by dramatically lowering technical barriers, allowing ordinary people to express themselves with newfound creative freedom,” they wrote. “Beyond the home, image stabilization technology found critical applications in specialized fields, contributing to advancements in areas such as educational media and telemedicine.”

The history of camcorders

Before the camcorder was invented in 1982, people filming events in the 1970s and early 1980s used two pieces of equipment: a video camera and a separate video cassette recorder (VCR), which were connected by a multipin cable. The camera was about the size of a toaster, and the VCR could be as large as a suitcase. To record, the person operated the camera with one hand and carried the VCR in the other or rested it on a shoulder. The cable transmitted the images from the camera to the cassette.

The PV-460 was made possible by several groundbreaking innovations, according to the Milestone proposal, one of which dates back to the 1950s.

In 1956 Italian manufacturer Durst released its Automatica, considered one of the first cameras to use automatic exposure technology. By combining a light meter with the camera’s internal mechanical systems, the technology removed the necessity of calculating exposure settings by hand when the lighting shifted or other conditions changed. The innovation enabled amateur photographers to take decent pictures.

The next breakthrough technology—autofocus—was invented in 1973 by Norman Stauffer, a manager of research for Honeywell in Littleton, Colo. It uses a sensor, a control system, and a motor to focus on a selected area. The invention led to the development of early electronic autofocus cameras, which eliminated the need for photographers to manually adjust the lens. Stauffer received the 1990 IEEE Masaru Ibuka Consumer Technology Award for his invention.

“The release of the PV-460 fundamentally transformed personal videography, enriching the way people captured travel, events, and family memories.” —Milestone sponsors

U.S. inventor Jerome Lemelson is credited with developing technologies that underpinned the camcorder, according to MIT. In the 1950s and ’60s, Lemelson filed several patent applications related to video and audio recording devices. In 1980 he was granted patents related to a portable video camera system. In 1982 JVC and Sony used the technologies to develop what they called the camera/recorder, which became known as a camcorder.

Sony released the first handheld camcorder in 1983: the Betamovie BMC-100P. It used the Betamax videocassette format and could record up to 3.5 hours of footage on 1.27-centimeter cassette tape. The operator rested the 2.5-kilogram camcorder on top of a shoulder to shoot footage. It sold for around US $2,000 at the time (roughly $33,400 today). The machine couldn’t rewind or play back tapes; it could only record.

Other electronics companies including JVC soon introduced their own models using the VCR format, which eventually replaced Betamax.

Over time, camcorders became more compact.

But none of the companies could fix the shaky-footage problem.

Solving a shaky problem

A team at Panasonic led by researcher Mitsuaki Oshima took on the task of image stabilization: detecting and correcting small camera movements, referred to as camera shake, according to the proposal. Oshima, an IEEE life senior member, is now an honorary Fellow at Panasonic.

“The movements that needed to be detected and corrected included horizontal, vertical, and rotational motions—specifically pitch, yaw, and roll,” the Milestone sponsors wrote. “Rotational motion, in particular, becomes the dominant factor affecting image stability during high-magnification shooting. Therefore, the development team focused on detecting rotational motion and began developing an angular velocity sensor.”

An AVS, essentially a gyroscope, detects how quickly an object is changing its orientation in space.

Sensors capable of detecting angular velocity were large and expensive at the time, making them unsuitable for consumer video cameras, the sponsors wrote. What was needed, they said, was a compact and inexpensive version.

Oshima and his team built a high-performance, small, low-cost vibration-type gyroscope. The stabilization mechanism included a miniaturized sensor paired with an optical-axis correction mechanism.

The mechanism adjusts the lens or image sensor to counteract physical shifting and vibrations, ensuring that the light path remains centered on the sensor—which is crucial for maximizing sharpness and quality, the Milestone sponsors wrote.

“The system detects lens displacement caused by camera shake and immediately compensates for it, ensuring stable video footage,” they wrote. “As a result, the effects of camera shake are minimized, allowing users to capture smooth and steady videos with ease.”

Without Oshima’s image stabilization technology, the PV-460 wouldn’t have been developed and released in 1988.

The technology was patented and broadly licensed by other companies. It has become a standard feature in a variety of imaging applications.

Awards and accolades

The PV-460 gained instant popularity when it debuted in June 1988. It received rave reviews at that year’s Consumer Electronics Show.

Panasonic received a 100 Award in 1989 from R&D World magazine for “the development of a VHS camcorder with an antishake mechanism.”

Oshima’s research paper, “VHS Camcorder With Electronic Image Stabilizer,” and others are available in the IEEE Xplore Digital Library.

To learn more about historical figures in engineering, IEEE Milestones, and IEEE History Center programs and events, check out The Institute’s IEEE Tech History collection. IEEE Spectrum also covers aspects of tech history.

Milestone plaque display

The Milestone plaque is to be displayed on the ground floor of the Panasonic Museum, which is open to the public. The museum is located near the now-shuttered Panasonic research lab where the technology was developed. The plaque reads:

“In 1988 the pioneering PV-460 camcorder equipped with image stabilization for enabling smooth and steady video capture was introduced by Panasonic. By pairing a miniaturized vibrating-structure gyroscope sensor with an optical-axis correction mechanism, the PV-460 eliminated the jitter caused by hand motion. Broad international licensing of this patented scheme made it a standard feature in film and digital cameras, smartphones, and related imaging devices.”

Selected by the IEEE History Committee and endorsed by the IEEE Board of Directors, IEEE Milestones recognize outstanding technical developments around the world that are at least 25 years old. The Milestone program is administered by the IEEE history and heritage group.