The appointment of Bernadette Meehan as the new CEO of the Wikimedia Foundation was announced on December 9 and she started work on January 20. The first part of this interview was published in a rush on December 17. Bernadette now returns with time enough to address the remaining questions in depth. – S

Signpost: Your qualifications from working for the US State Department in the Foreign Service culminating as the US Ambassador to Chile are very impressive. But how will the skills you developed there help you run a large non-profit organization dependent on volunteers to accomplish our mission?

Bernadette: My path to the Wikimedia Foundation has been unconventional—but every chapter has prepared me for this moment. Along the way, I've developed skills and experiences that closely align with the mission of the Wikimedia Foundation, Wikimedia projects, and the role of CEO. Just as importantly, I feel a deep connection to the Foundation's values and community ethos.

In diplomacy and at the Obama Foundation—a global nonprofit—collaboration has been my compass. Diplomats are constantly dealing with seemingly intractable problems. I've built trust in complex environments, brought diverse stakeholders together, and found common ground across differences. Serving as Ambassador and leading a large embassy reinforced lessons I carry with me every day: disagreement isn't failure; open-mindedness is strength; facts and transparency build trust; respectful debate sharpens outcomes; and principles must guide not just what we do, but how we do it.

I've also managed large teams, significant budgets, and difficult tradeoffs—experience that feels especially relevant as the Wikimedia movement navigates growing external challenges. We cannot go it alone. The important decisions ahead will call on us to work together with care, thoughtfulness, and shared purpose to shape our future.

When I look at the Wikimedia Foundation and community, I see our shared commitments: mission-driven work, broad participation, intellectual curiosity, principled action, and optimism in the face of complexity. Some of my proudest accomplishments have been partnerships forged across divides and grounded in shared purpose.

Each step of my journey has stretched me—strengthening resilience, humility, innovation, and kindness. I've grown alongside extraordinary teams, striving to practice servant leadership and remain a lifelong learner. I enter this next chapter at the Foundation confident in what I bring and humbled by how much I have to learn from this remarkable community.

If you'd like to learn more about my journey—and three past projects of mine that echo the spirit of Wikimedians' work—I invite you to read the Diff blog about my appointment from December 2025.

Signpost:There are diverse opinions about artificial intelligence in the Wikipedia community, but many Wikipedians have expressed opposition to using AI for Wikipedia articles. Can you tell us your views on using AI on Wikipedia? Are there other concerns you have about AI?

Bernadette: I respect the care and thoughtfulness with which Wikimedians are approaching this topic.

In my first 30 days as CEO, I've spoken with 229 Wikimedians—at gatherings like Wikimedia Futures Lab and in one-on-one conversations. Unsurprisingly, AI has surfaced in many of these discussions, with a wide range of thoughtful perspectives. I've also been learning more about ongoing conversations across communities.

My goal in these early days is simple: to listen. As I do, I'm grounded in a core belief—knowledge is human. At a time when synthetic and unreliable content is proliferating, human-created knowledge on Wikipedia is more essential than ever, even as it becomes less visible in an AI-shaped landscape.

Last year, the Foundation shared its AI strategy for supporting editors, centered on putting humans first. This aligns with my view. The question is not whether AI should exist within our ecosystem—it already does—but how we choose to engage with it.

The concerns I've heard are real: machine-generated content can accelerate disinformation, introduce security risks, erode trust, and increase pressures on volunteers. At the same time, AI offers meaningful benefits. Used responsibly, it can help editors identify vandalism, detect bias, improve accessibility through translation and summarization, and reduce repetitive tasks that may contribute to volunteer burnout.

AI is rapidly reshaping the information environment. If we do not proactively decide how to work effectively in an AI-dominated world—guided by the principle that AI must not replace human knowledge—we risk being sidelined or replaced by systems that do not share our commitments.

I look forward to continuing this dialogue with communities worldwide so that together we can safeguard what makes Wikipedia unique and important—and protect the integrity of human-created knowledge so it thrives in the AI era.

Signpost: Writing an encyclopedia is an intellectual endeavor. What books are you reading now? What other intellectual activities do you use to give you a break from your job?

Bernadette: Reading is my favorite hobby, and libraries and bookstores are my happy places. My nightstand holds a teetering stack of books and magazines, and the rest of my house isn't much different—clusters on shelves, tables, more than the occasional floor pile. A Foundation colleague recently introduced me to the term Tsundoku (積ん読): the art of acquiring books and letting them patiently wait their turn. Another colleague put it even more plainly: "Buying books and reading books are two different hobbies." I fully embrace and practice this philosophy.

On my nightstand right now:

• Some People Need Killing by Patricia Evangelista
• Pandora's Jar: Women in the Greek Myths by Natalie Haynes
• Leaders: Myth and Reality by Stan McChrystal
• The Bee Sting by Paul Murray

Outside of work, my world revolves around my family—my very patient husband and our amazing seven-year-old daughter—so lately I'm immersed in K-Pop Demon Hunters. When I carve out a little time for myself, I love to swim (for me exercise = focus and clarity and less stress), tackle The New York Times' "Spelling Bee" puzzle, watch a good thriller on streaming, and plan future adventures—especially road trips.

Signpost: Different CEOs will naturally have different priorities. What's the most important thing that you want to make sure you accomplish during your tenure at the WMF?

Bernadette: I step into this role committed to building on the progress that has come before me. I believe leadership is a phase, not a possession. A leader is a custodian for a period of time—entrusted with care, continuity, and responsibility—not an owner. My role is to work alongside this community so that together, we leave it stronger for those who come next.

As we mark 25 years of Wikipedia, my central focus is this: how do we ensure that the next 25 years remain deeply human?

We are living through a profound shift in how information is created, distributed, and consumed. In a world increasingly saturated with AI-generated content, human-created knowledge is more valuable than ever. The power of Wikimedia projects lies not only in the information they contain, but in how that knowledge is made—through transparent volunteer effort, debate, sourcing, consensus, and shared principles. Protecting and elevating that human foundation is essential.

That means adapting to changes in search, technology, and content reuse without losing what makes us distinct. Our reuse strategy must center open knowledge and the volunteers who create it. As Wikimedia content travels across platforms and informs new technologies, we must ensure the human judgment, care, and community processes behind it are respected and sustained.

Equally important to me is preserving the joy of participation. People don't just contribute to Wikimedia projects because they're useful—they contribute because it's meaningful. There is real satisfaction in improving an article, resolving a debate, sharing an image, mentoring a new contributor, leading within a community, or seeing knowledge made more accessible. As we evolve, we must ensure that this joy—the sense of purpose, curiosity, and belonging—remains at the heart of the experience.

If we can safeguard human knowledge, strengthen our communities, and keep participation vibrant and rewarding, we won't just sustain Wikipedia for another 25 years—we will help it flourish for generations to come.

Signpost: This may be the most important question. How can Wikipedians and others in the Wikimedia movement help you be successful in your new job?

Bernadette: I love this question—because the human connection and spirit of collaboration are two of the main reasons I was drawn to the Wikimedia movement.

So my number one request to Wikimedians is simple: engage with me. You know your communities best. You understand the challenges and opportunities facing our projects. Your insight will help shape my path forward.

I'm calling this listening, learning, and engaging tour "Around the Puzzle Globe"—meeting Wikimedians virtually and in person across regions and projects. You can also reach me on my talk page.

Everywhere I go, I'm starting with three questions:

• What brought you to this movement?
• How do we stay relevant over the next 25 years?
• What three Wiki resources should I read first?

I'm here to listen, to learn, and to puzzle through the future—together.

Signpost: Thank you, Bernadette.

From approximately 16:00 UTC until 17:00 UTC on March 5, Wikimedia sites including English Wikipedia were put into read-only mode by site administrators in response to an incident in which Wikimedia user accounts with advanced permissions were seen on Meta-Wiki to post the message, "Закрываем проект" (Russian for "[we are] closing the project") on many pages, and in the edit summary of their post. During the shutdown, users monitoring Recent changes page on Meta could view WMF operators manually reverting what appeared to be a computer worm propagated in common.js, while other operators with compromised accounts continued to post the message.

As all the Wikimedia wikis were closed to editing, users took to Wikimedia channels including Discord and Telegram to discuss the situation. Community members speculated about the cause, expressing fear and anxiety that the incident was a government attack related to any of the military conflicts in which the United States is currently engaged, and a readiness to believe that Wikipedia was a suitable target for any government wanting to attack access to information.

The lead of the WMF's Product Safety and Integrity team stated

We have no reason to believe any third-party entity was actively attacking us today, or that any permanent damage occurred or any breach of personal information.
— User:EMill-WMF, in Wikipedia Discord #general

The Wikimedia Foundation described the incident at "March 2026 User Script Incident" on Meta-wiki, explaining that it happened while "Wikimedia Foundation staff were conducting a security review of user-authored code across Wikimedia projects." The talk page there is the place for anyone to raise further questions, share comments, and link to any discussions or coordination which follows this incident. As summarized in less technical terms by a community member:

The cleanup did not involve a database rollback, i.e. there were no lost edits due to the incident (not including edits that were never made because of the outage).

Russian Wikinews published an article on the incident. English Wikipedia editors posted the incident to Wikipedia:Village Stocks, a joke page where major blunders like accidentally deleting the Main Page are recorded both for educative purpose and lolz. Opinions are divided on whether it should be featured there. – B, H, Br

The Wikimedia Foundation has announced that it will delete all notes in the Wikimedia-hosted Etherpad instances at https://etherpad.wikimedia.org/ in April 2026. Since the adoption and recommendation of etherpads as a Wikimedia community notetaking platform in 2011, the Wikimedia community has used etherpads for notetaking during meetings of Wikimedia chapters and usergroups, Wikimedia conferences, and informal in-person or virtual meetings where community members have live voice conversations. As of Friday March 6, a Wikimedia volunteer rescue effort has backed up many etherpad notes linked from the most popular Wikimedia wikis in Wikimedia Toolforge, but the completeness of note preservation is uncertain.

The Site Reliability Engineering team of the Wikimedia Foundation communicated the decision in Wikimedia Phabricator ticket T415237 on January 22, framing the issue as a technical matter. On 10 February 2026, the Wikimedia Foundation made an announcement to Wikitech-l sharing that the Wikimedia Foundation will delete all the texts on 30 April 2026. The primary rationale for deletion is that this collection uses excessive resources. There is something odd here, as the filesize of Wikimedia etherpads is 233GB, which is about ten times the Wikipedia:Size of Wikipedia. Some of this content is the expected and familiar hand-typed notes from hard-working Wikimedia volunteer note takers, and the other 232GB is probably something unexpected.

Wikimedia technical editor and volunteer Audiodude communicated the matter to the Wikimedia community in venues including the Etherpad talk page and the Village Pump (miscellaneous).

While Wikimedia Foundation system administrators tend to start conversations as technical issues, Wikimedia users tend to think of software in terms of tools for achieving goals. While it may be the case that the etherpads are consuming more resources than anticipated, the point of the etherpads is to value and preserve discussion notes on important Wikimedia community volunteer concerns for user governance, strategic planning, and addressing the challenges we face in supporting global coordination of Wikimedia content development programs. The Wikimedia Foundation for years has recommended etherpad usage for event documentation, including at Wikimedia conferences including Wikimania, in discussions with Wikimedia Foundation staff and Wikimedia Foundation board members, and as a default notetaking service in all situations where notes can be public and collaboratively edited.

Looking ahead to deletion and to remember sample Wikimedia etherpad use, here are screenshots of typical notes documents, archived as PDFs in Wikimedia Commons. – BR

• 
  meeting notes, Strategic Wikimedia Affiliates Network, virtual, July 2024
• 
  Wikipedia editing & AI, WikiConference North America 2025 in New York City
• 
  Chat with the Wikidata development team, Wikimania 2025 in Nairobi
• 
  Future of Wikimania, Wikimania 2025 in Nairobi

See related Signpost content in this issue's In the media and Technology report

Archive.today has been deprecated as the result of the Archive.is Request for Comment (5) (RfC 5) which closed 20 February. The RfC closure begins with the following text:

There is consensus to immediately deprecate archive.today, and, as soon as practicable, add it to the spam blacklist (or create an edit filter that blocks adding new links), and remove all links to it. There is a strong consensus that Wikipedia should not direct its readers towards a website that hijacks users' computers to run a DDoS attack.

Further information on the decision and practical outcomes for editors can be found at WP:Archive.today guidance. – B

Three Iranians have stopped by Talk:Timeline of the 2026 Iran war thanking Wikipedians for providing news in the article that is otherwise unavailable. Communications and access to the normal news sources are down or blocked within Iran, but surprisingly enWiki is getting through. The requests for more news were also taken to The village pump. Editors have been advised to make sure to follow WP:Verifiability and WP:Reliable sources.

• Articles for Improvement: This week's Article for Improvement is Reef (beginning 9 March) followed by Christmas dinner (beginning 16 March). Please be bold in helping improve these articles!
• Request for adminship: The second Request for adminship of 2026 is open as we go to press.

This security incident is also the subject of this issue's opinion essay, and covered in News and Notes.

It has become the talk of the town that somebody set up us the bomb, that we were on the way to destruction, that Wikipedia was hacked, and other such things.

Well, it kind of was.

A horrifying exploit took place, which could have had catastrophic and far-reaching consequences if used maliciously; instead, it seems to have happened by accident and was used for childish peepee-poopoo vandalism.

The official statement, which you can see here, does not say a whole lot about specifically what happened:

This is not very enlightening, so let's take a closer look.

The actual script, whose source code can be seen from the Phabricator ticket page, is relatively simple. It does not do anything particularly horrifying or complicated; mostly it's just dumb schoolkid vandalism. It cannot actually get into the backend database or the server's shell, which is where private data is stored, and irreversible actions can be taken: all it can do is make a big mess on the wiki.

The way it works hinges on the fact that, on MediaWiki, all users have a page called "common.js", which is where userscripts go. If you're logged in, yours is here; mine is here. On this page, you can put code that is automatically run whenever you load a page on the website. They can either be written in the file itself, or loaded from somewhere else.

In mine, for example, I have it (among other things) load User:JPxG/Difformatter.js, a script I wrote that gives me buttons in the editing box to automatically format external diff URLs (like my 123,456th edit, whose URL is https://en.wikipedia.org/w/index.php?title=&diff=prev&oldid=1336463538 and looks like this) into internal links (like Special:Diff/1336463538, which looks like this). Most userscripts do something along these lines. There are a great number of them, and there is a semi-active newsletter for new ones, which I at one point wrote an issue of.

There is also a page on every wiki called MediaWiki:Common.js, which the English Wikipedia has here, and Meta-Wiki has here. This is a version of the same page that runs for everybody on the entire site. Because this could be very easily used to make a huge mess, either intentionally or unintentionally, access to it is very limited: I am a template editor and an edit filter manager and one of the thousand or so sysops on Wikipedia who have to be elected, and I could put Goatse on the Main Page if I wanted to, but I still cannot edit the site's common.js unless I make a request for another userright, "interface administrator". There are only fifteen of these; in addition to being administrators, they are all serious-business technical editors like Izno and Oshwah who can be trusted around high voltage.

Anyway, here is what Ololoshka562's script does:

• Loads jQuery, gets the account name of the current user, and checks to see if it has already infected the site. Literally, it fetches the current site's MediaWiki:Common.js and checks to see if it has "Ololoshka562" anywhere in it.
• Tries to edit the sitewide common.js, and replaces it with a gigantic block of gibberish. This gibberish is also JavaScript, but it's encoded as a URL is, so it is kind of hard to read. The script de-gibberishifies it later, so the only reason it's that way is to make it hard to read the code. Presumably, if it was just written directly, it would be obvious what it did, so it is kind of munged up.
• Also edits the current user's common.js, and replaces it with the same bolus. Only interface administrators can edit the sitewide common.js, so this allows it to work on people who aren't intadmins.
• Tries to use Special:Nuke three times. If you aren't an administrator, you can't do anything from this page, but I can use it to delete massive numbers of pages. That is what this script does.
• Gets twenty random pages and tries to vandalize them by adding what's now File:Woodpecker10.jpg (this file didn't exist when vandalism occured), and then tries to load... something... from some sleazy-looking website I've never heard of. This site was, by March 2026, not only nonexistent but also unregistered.
• Gets twenty more random pages, and tries to delete them. If you aren't an administrator this won't do anything.

The actual bolus of crap that it loads does a few more annoying things:

• Loads itself.
• Makes every link to a page called "common.js" unviewable, so you cannot fix it from the normal web interface.
• Redefines the importScript function so that, when userscripts try to load other userscripts, instead of the local site they load them from cyclowiki.org.

Strewn among this is a bunch of junk that doesn't do anything malicious, and looks like it came from some normal wiki's Common.js (like you would find here) to expand and collapse boxes, tables, and so on.

As far as I can tell, this was either made purely for the lulz, or as part of some puerile beef between two random wikis. It doesn't do anything permanent or extremely dangerous; basically everything it does is within the interface that MediaWiki exposes to users. It does load and execute random JavaScript; at the time it was written, whatever was in those offsite URLs could have been some kind of horrifying smallpox code that stole your banking details. However, it didn't do this when it was actually executed, because the URL didn't exist anymore. Whatever heist this was originally cooked up for, if it was carried out at all, seems to have been finished and wrapped up years ago. This script is basically just a random grenade that was left lying in a cornfield. It was basically harmless, except in the specific scenario where somebody with extremely powerful sitewide permissions decided to import and run it with full privileges, which is usually something that people do not do. Mostly because this kind of thing can happen as a result.

Essentially, to carry the analogy further, a grenade lying in a random cornfield is not a particularly dangerous or sophisticated attack against the nation in question. It would cause significant damage if a head of state picked it up off the ground and fixed to take a bite out of it, but under normal circumstances there are people whose job it is to prevent this from happening.

In the aftermath of every accident, it is necessary to figure out not just why it happened, but why it was allowed to happen. The "find one guy to yell at" system is alluring, because it is simple, but in most cases it is not sufficient to explain failures. Especially with systems as complex as modern software, it is rarely the case that the person who bumped into the "blow everything up" button is to blame — for starters, why is there a "blow everything up" button in the first place? Was it right next to the light switch?

At the Meta-Wiki page created to discuss the incident, a great deal of confusion ensued. Generally speaking, in the software industry, this is not supposed to happen. Over decades, it has become pretty well understood that some activities are inherently risky, and in most systems there is a framework in place to test them out where it won't blow anything important up.

The basic principle is similar to how, when the army is making some new type of gigantic bomb, and they need to test something by actually blowing it up in real life instead of working it out on graph paper, they go to some sand dunes in the middle of nowhere, even though their offices are in the middle of a densely populated city. Most companies and organizations that develop software have similar arrangements. Indeed, the prevailing practice in most software-related industries is to maintain two copies of infrastructure, called "testing" and "production".

On Wikipedia, there is a single-page version of the Nevada Test and Training range, at the aptly-named Sandbox; there's a whole-website-sized version of it at test.wikipedia.org. The Wikimedia Foundation, which develops a lot of software, has a wide variety of testing environments, which are used for developing the MediaWiki software and testing various things. It's not immediately clear what test was being done here, or why it was being done on the live site, or why it was being done with an account with such high privileges (e.g. an interface administrator).

However, there are some clues. The most likely thing, in any situation like this, is that there wasn't a solidly established framework for whatever was being tested here; either it was a quick, one-off thing that nobody wanted to build a whole testing harness for, or it was something where a whole testing harness would be extremely time-consuming to create. This is not a very good reason to "test in production", as it's called, but it is often necessary on Wikimedia sites. This brings me to my next point.

While MediaWiki may seem like a paragon of orderly version control — after all, every action a user account takes is logged, timestamped, diffable and reversible — in practice it has become kind of a mess.

As an example: on the English Wikipedia there are a great deal of templates and modules. The original purpose of the "template" function was to let the periodic table be displayed on every element's article without having to hard-code it in the article source; they now do basically everything. Templates (which use MediaWiki markup and HTML) and modules (which use Lua) do a dizzying variety of things, and handle virtually all elements of a Wikipedia page that aren't the bare text of articles, and sometimes that. They format infoboxes, display maps, organize maintenance, display citations, display a lack of citations, and most importantly provide functions and components for other templates.

Templates and modules all individually have version histories; for example, Special:History/Template:Section sizes. However, most templates on Wikipedia are meta-templates, which call other templates. For example, I created {{Generating stations in California}}, which is the big expandable box at the bottom of Topaz Solar Farm and Gateway Generating Station that lists all the power plants in the state. All of the categories and links are coded into that template. Navboxes are heavily used, so they are a very straightforward and simplified type of template. But even with this one, if you look at the tree of every template that the template itself uses, you get this:

Now, you might think 21 templates (what most programmers would call "dependencies") is not a whole lot for something as big as a navbox. But each of them have their own tree of dependencies. For example, here is every template used in {{Collapsible option}}:

Why does it matter what dependencies a template has? Who cares? Well, there's no form of inter-page version control whatsoever!

When you edit {{Generating stations in California}}, for example, you cannot specify that you want to use the version of {{collapsible option}} from 2026-03-09. The only option is to just use whatever the current version happens to be. This means that, from time to time, templates just break for no apparent reason, and the only way to debug or fix them is to go through everything they transclude individually and see what changed.

More relevantly to this incident, there is no way to "create a testing branch" of the whole dependency tree. If you want to make a version of {{Generating stations in California}} that has different colors, you cannot do this on your local machine, or even on a different Wikimedia site. You need to do it on the English Wikipedia specifically, because the English Wikipedia is the only MediaWiki install in the world that has this specific panoply of templates and modules and meta-templates. It's possible to create a separate copy of the template, on the English Wikipedia — most templates (especially complicated ones) have a sandbox subpage where you can test modifications. But there's no way to actually replicate the testing environment without replicating the entire English Wikipedia.

If templates were designed as a programming framework, there might be, but they weren't; they were designed as a way to put the periodic table at the bottom of articles about elements.

This may seem like it has nothing to do with userscripts, and I admit it is a long digression, but I mention it to illustrate a fundamental point about MediaWiki: it's a quarter-century-tall stack of weird kludges built on stuff that in most cases wasn't designed for its current purpose. Any time you are asking yourself why some weird thing happened, this is probably a big part of the answer.

I may be biased in my characterization of the situation, but as far as I can tell, the root issue here is likely not that the Wikimedia Foundation employed engineers to poke around with the software, but rather that they did not employ enough engineers to poke around with the software.

The one thing that seems pretty clear is that this was not some kind of sophisticated cyberattack, and there was no Tom Clancy business — it was just a random grenade lying in a cornfield that was for some reason imported and run with one of the highest privilege levels possible. It did not have shell access, and it did not have database admin access, but it did have the ability to load random scripts for viewers of the site.

In all likelihood, whoever Ololoshka562 is had no clue that it was even happening, and certainly did not plant it there to make this incident happen on purpose. This is quite fortunate, because if they had, it could have been a giant global catastrophe. Wikipedia is one of the world's most widely-used websites, and it did not have an arbitrary code execution incident, but seemingly purely by coincidence. This is a pretty narrow bullet-dodge (or nuke-dodge as the case may be), and some changes need to be made.

What changes I cannot say. It's hard to say exactly what went wrong, and whether it was an infrastructure issue or an organizational issue or what — but it was very fucking bad, and it is of paramount importance that it never happen again.

A Swedish singer has called on her TikTok followers to change the photo on her biography, an open-source analyst encouraged people on his blog to improve a Wikipedia article, and a government blocked editors from logging into their Wikimedia accounts.

Editors in Indonesia are currently unable to log into their Wikimedia accounts after the country's Ministry of Communication and Digital Affairs (Kemkomdigi) ordered internet providers on 25 February 2026 to block access to auth.wikimedia.org. The government cited the Wikimedia Foundation's failure to register as a private Electronic System Provider (Penyelenggara Sistem Elektronik, or PSE) under Indonesian regulations. (Tempo)

While readers' access to the various Wikimedia projects is not affected by this block, editors in Indonesia have effectively been prevented from logging into their accounts, and new accounts cannot be created. Editors who were logged in before the block was instituted are still able to use their accounts. However, as authentication cookies expire over time, Indonesian editors may gradually lose access to their accounts. This could prevent established editors from editing protected pages and administrators from using administrative tools needed to maintain the projects.

If Wikimedia Foundation registered as a "Electronic System Provider", then it would be subjected to Indonesian laws. These laws may give Indonesian authorities broad access to user data including access details as well as authority to demand the removal of "prohibited content". Human rights organizations have previously described content definitions as overly broad restrictions on free speech. (Human Rights Watch) The vague wording of what can be taken down, such as creating "community anxiety" or causing "disturbance in public order" are also a cause for concern among free speech advocates. The law was established in 2019 by the previous government and has since gone through several amendments. Tech in Asia notes that the enforcement on Wikimedia platforms is based on this already established law. Before the latest action on Wikimedia Foundation, other international companies or services such as PayPal, Steam, Dota, CS:Go, Yahoo, Origin.com, Epic Games, Archive.org had run afoul of the law, having their platforms blocked as well until they had registered as PSEs. (Digital Policy Alert). As of writing, there are 779 foreign PSEs (around 4%) registered out of a total of 16,255 PSEs. (Komdigi PSE Statistics)

The latest enforcement on 25 February 2026 came on the heels of the formation of a dedicated Digital Space Oversight Directorate General in January 2025, which operates under the Ministry of Communication and Digital Affairs. It has an expanded mandate, and has also asked for an increase in its operating budget, in part to centralise digital oversight, including compliance and law enforcement, in the digital space. (Indonesia at Melbourne, Lexology). Prior to this, the Wikimedia Foundation had received multiple notifications from the authorities since November 2025, urging them to be registered as a PSE. (VOI) Cloudflare was similarly warned in November 2025, and its staff have met the authorities since then and are currently reviewing the applicable laws while stating that as an infrastructure provider, they do not directly curate content. (Tech in Asia 2)

In a statement to The Signpost, the Wikimedia Foundation said that it is aware of the access restriction in Indonesia and that Wikimedia projects remain accessible to read and contribute as logged-out users. The Foundation further explained that they are "actively investigating the scope and underlying basis of this situation", while engaging with the Indonesian authorities to seek a resolution. It added that it "deeply values the dedication and contributions of the Indonesian Wikimedia communities" and expressed hope that access would be restored soon so that volunteers could resume editing without disruption.

Addendum: On 9 March 2026, after a week of discussion, the Indonesian Wikipedia community released a statement asking Komdigi to undo the block (In Indonesian: Indonesian Wikipedia). Additionally, a Central Notice banner in Indonesian, alerting readers of the situation, has been requested to be placed across the various projects after seeking consensus among 20 other project communities. (Central Notice request)

Swedish singer Zara Larsson entreated millions of followers on TikTok to change the infobox photo in her Wikipedia article, which she loathed (People, Rolling Stone, The Independent). The resulting barrage of edits led to page protection, which quickly escalated from semi to extended-confirmed. The Daily Dot kind of nailed it when they said "The utopian open-source ethos of Wikipedia can become an enemy to a public figure trying to control their image." A Request for Comment on the talk page ensued.

Pitchfork followed up with what appear to be pretty straightforward directions to other artists on how to upload their favored photo and make an edit request. – B

See related "Signpost" coverage at News and notes and the Technology report.

"Wikipedia blacklists Archive.today, starts removing 695,000 archive links" and "If DDoSing a blog wasn't bad enough, archive site also tampered with web snapshots", said Ars Technica on Feb 20. The blacklisting was also described at Times of India; International Business Times; TechCrunch; Boing Boing; PC Magazine; Tom's Hardware, and others. – B

Open-source analyst Andrew S. Erickson's blog had an entry about the Chinese People's Armed Forces Maritime Militia (PAFMM), in which he notes other analysts calling PAFMM "little blue men"^[a] and invited more people to do their own analysis and contribute to Wikipedia. He says:

Folks outside government looking for a way to enhance public understanding may wish of their own accord to update and enhance Wikipedia’s entries on "Maritime Militia" (now in English, Chinese, Japanese, and Czech)—which have improved significantly yet remain far from comprehensive or complete. It's easy to become a Wikipedia editor, by the platform's very design...

In sum, rarely is a topic so little recognized and so little understood (even now), yet so important and so amenable to research using Chinese-language open sources.

– B

See related content at News and notes

A recent security incident involving a computer worm forced the Wikimedia Foundation to temporarily put all wikis into read-only mode. The incident has drawn the attention of some tech-focused outlets, with Bleeping Computer reporting that "approximately 3,996 pages were modified", with the commons.js files for 85 accounts being replaced by it. In the same article, they also analyzed the code. — B,M

404 Media reports that AI Translations Are Adding 'Hallucinations' to Wikipedia Articles. The Open Knowledge Association (OKA) is a small Swiss not-for-profit associated with the effective altruism movement and run by it's main donor, User:7804j. OKA recruits and pays newby editors from the global south to translate articles into English using AI translation, raising questions about paid editing, and the proper use of AI. Recent community discussions, culminating at WP:AN, have instructed OKA to make sure they comply with WP:Paid and AI rules, and suggest that more suggestions may be coming. 7804j seems amenable. Other interesting challenges may include the community's ability to adapt its governance processes to new conditions while continuing to assume good faith. – S

• [insert name]pedia: Following on the heels of last issue's Signpost coverage of Xikipedia, now we have on our radar Jikipedia (aka Jwiki) at Gizmodo, The Verge, and others. The 'pedia is part of the Jmail suite created by Riley Walz and Luke Igel that repackages the 3,000,000 or so documents released by the DOJ on the Jeffrey Epstein case. We are going to run out of letters of the alphabet if this keeps up. N.b. Dickipedia is already taken.
• Kiwix proves its worth, again: In Lamu County, Kenya, "Students and teachers at Shela Primary School can now access Wikipedia and thousands of educational resources without an internet connection following the installation of Kiwix for Schools". ("Wikipedia Provides Shela School With Digital Library", The Coast [Kenya])
• Majority rules: 65.8% of respondents voted to largely ban the use of AI on the German Wikipedia (for context, they use polls). "German Wikipedia bans AI-generated content while other language editions take a softer approach" (The Decoder, Heise Group)
• Training: "Hamas-linked org. trains Gazans to edit Wikipedia pages about Israel, Palestine" (Jerusalem Post), "Hamas-Linked Nonprofit Launches Wikipedia Training Program to Smear Israel" (Algemeiner (New York)), "Wikipedia's Information Intifada" (Algemeiner)

• Jimbo, live from Indian AI summit: Jimmy Wales is optimistic about India's future in tech, but emphasizes the importance of keeping humans in the AI loop.
• Who can you trust?: Reason magazine talks about Wikipedia's power 62, Trump, Grokipedia, Justapedia, and "Can you trust Wikipedia?" (video and transcript). Zach Weissmueller interviews Betty Wills, Larry Sanger, and Jimmy Wales. You might even think that Jimbo and Larry have finally come together for an online debate. But no, the interviews were separate, and carefully spliced, with the questions and accompanying commentary rerecorded.
• Props from Craigslist founder: Craig Newmark (known for his Craigslist) interviewed on Lay of the Land podcast... Starting at 36:45, he talks about Wikipedia, which he says "maintained a great moral compass" despite the lure of billions to go commercial.

The San Francisco Chronicle reviews Annie Rauwerda's stage show "The Depths of Wikipedia". Rauwerda first appeared in this Signpost column in 2021, and most Wikipedians are likely to be familiar with her work. The Chronicle gives lots of good reasons why it's a great show, but it boils down to one simple fact. It's fun! In one segment Riley Walz was invited on-stage and answered trivia questions from Rauwerda.

I got a chance to see the show this week in Philadelphia. Like Walz, I was invited on-stage (for about five minutes) and then was quizzed on WikiTrivia. I demonstrated that I don't know anything about WikiTrivia, so Rauwerda showed several photos that I've posted of my dog, Graf. It was great fun and the audience seemed to enjoy it. COI disclosure - I received a free ticket. – S

A monthly overview of recent academic research about Wikipedia and other Wikimedia projects, also published as the Wikimedia Research Newsletter.

Grokipedia, the AI based online encyclopedia launched XAI in October 2025 to counter perceived bias on Wikipedia, continues to attract researchers' attention (see also our previous coverage: "Comparing comparisons of Grokipedia vs. Wikipedia by three different research teams").

Reviewed by Mitchsavl

A recent paper titled "Is Grokipedia Right-Leaning? Comparing Political Framing in Wikipedia and Grokipedia on Controversial Topics"^[1] provides a comparative analysis on "semantic framing, political orientation, and content prioritization". The study concluded that both encyclopedias were generally left-wing, with Grokipedia showing a small right-wing bias on contentious topics. They also found that later sections within articles had greater differences than the lead.

...these findings challenge the widespread perception of Grokipedia as an extreme right-leaning encyclopedia, instead suggesting broadly comparable tendencies between the two platforms in their treatment of politically controversial topics, while still indicating a modest but consistent right-leaning bias in Grokipedia relative to Wikipedia.
— Is Grokipedia Right-Leaning? Comparing Political Framing in Wikipedia and Grokipedia on Controversial Topics

The study selected six controversial topics, which were the most divisive in polling data from Gallup: abortion, cannabis legalization, climate change, gender identity, gun control, and immigration. Across all these topics, Grokipedia was determined to be shifted towards the right compared to Wikipedia, with cannabis legality and gun control averaged a right wing bias.

Reviewed by Tilman Bayer

Another recent preprint,^[2] by six researchers from Sapienza University of Rome presents "a comparative analysis of Wikipedia and Grokipedia" based on a much larger sample, finding that

"Inclusion is non-uniform: pages with higher visibility and greater editorial conflict in Wikipedia are more likely to appear in Grokipedia. For included pages, we distinguish between verbatim reproduction and generative rewriting. Rewriting is more frequent for pages with higher reference density and recent controversy, while highly popular pages are more often reproduced without modification. [...] Across multiple topical domains, including U.S. politics, geopolitics, and conspiracy-related narratives, narrative structure remains largely consistent between the two sources. Analysis of lead sections shows broadly correlated framing, with localized shifts in laudatory and conflict-oriented language for some topics in Grokipedia."

Like the Cornell researchers whose paper was covered in our previous issue, the authors detected Wikipedia-sourced articles when scraping Grokipedia:

We consider a Grokipedia page to be not rewritten if it contains the standard Creative Commons footer. Specifically, we determine whether a Grokipedia article is kept unchanged by checking for the presence of the following text at the bottom of the page: “The content is adapted from Wikipedia, licensed under Creative Commons Attribution-ShareAlike 4.0 License”.

However, their assumption that those articles are "not rewritten" are somewhat in contrast to findings of the Cornell team, who calculated a "mean chunk similarity" score between corresponding Grokipedia and Wikipedia articles which at 0.90 was higher than for those articles without that footer, but still below a perfect 1.0 similarity score.

Reviewed by Tilman Bayer

A preprint titled How AI Reshapes Human Content Creation: The Case of Wikipedia^[3] by two economists from Wake Forest University offers a surprising conclusion:

"We [...] examin[e] the short-run impact of the introduction of Grokipedia, an AI-generated online encyclopedia operated by xAI, which provides automated summaries that could either substitute for human editing or draw in new contributors. We develop a simple theoretical framework in which AI entries can redirect user attention and stimulate human editing through novel framing, yielding ambiguous effects on UGC [user generated content] ex ante. Using a new panel dataset covering 1.4 million Wikipedia pages of notable individuals, we exploit the fact that only a subset have comparable Grokipedia entries to estimate the causal effect of AI on subsequent human contributions, constructing matched samples of treated and untreated pages within occupational fields. We find a consistent and surprising result: the availability of Grokipedia increases human editing activity. Page views also rise, suggesting that AI entries act as an attention amplifier rather than a pure substitute for Wikipedia content. Exploiting variation in the semantic similarity between Grokipedia entries and their corresponding Wikipedia articles, we further show that pages with lower similarity experience larger increases in editing after Grokipedia’s launch, consistent with the model’s predictions. [...]"

The paper's "Introduction" section points out that

Theoretically, the effect of Grokipedia on Wikipedia’s UGC is ambiguous. AI may act as a substitute: if users rely on Grokipedia entries instead of Wikipedia, the reduced traffic and diminished perceived value of contributing may depress human editing activity. But AI may also act as a complement: users may draw information from Grokipedia to improve or update Wikipedia pages, or the publicity surrounding a new AI platform may direct attention toward existing Wikipedia entries, leading to more edits. The competition for viewers may also elicit greater effort from Wikipedia contributors. Which force dominates is ultimately an empirical question.

(The authors cite this edit as a concrete example of how information on Grokipedia may inspire activity on the corresponding Wikipedia article.)

The paper's statistical analysis focuses on

a new panel dataset of approximately 1.4 million Wikipedia pages of notable individuals across five occupational domains—Academia, Culture, Leaders, Politics, and Sports. Only about 170,000 of these pages (roughly 12%) are covered by Grokipedia at launch, while the remaining 88% do not receive an AI-generated entry.

To assess the impact of Grokipedia's October 2025 launch on these Wikipedia articles, the authors compare views and edits as follows:

Because Grokipedia coverage is concentrated among highly visible pages and baseline visibility varies systematically across occupations, we construct matched samples using Mahalanobis-distance nearest-neighbor matching within occupational fields. Treated pages—those with a Grokipedia entry—are paired with the closest untreated pages based on pre-treatment views, editing histories, long-run readership, and page characteristics, approximating the counterfactual trajectory each treated page would have followed absent Grokipedia. We then estimate treatment effects using a Difference-in-Differences framework, which compares changes in views and edits before and after Grokipedia’s launch between treated pages and their matched controls.

The analysis of post-launch views and edits is confined to a rather short timespan of just three weeks (October 27–November 16). The authors justify this "focus on short-run outcomes" by observing that

Beginning on October 27, 2025—the day the platform went live—traffic spiked abruptly, reaching over 500,000 daily visits worldwide during its first week, with more than 100,000 daily visits per day originating from the United States alone. Peak attention occurred immediately after launch, exceeding two million global visits on October 28, before declining in the following days.

• A call for Lightning Talk proposals has been posted for the research track of this year's Wikimania conference (to take place 21-25 July, 2026 in Paris, France, as an in-person and online event). Submission deadline: March 31, 2026.
• Registration is open for Wiki Workshop 2026, "the annual forum bringing together researchers exploring all aspects of Wikimedia projects" (March 25-26, 2026, online, free of charge).
• The Wikimedia Foundation's Data Engineering team announced two new monthly data dumps that provide unparsed content from Wikimedia project wikis in XML format. (These dumps remain freely available to the public, unlike the paid offerings of Wikimedia Enterprise.)
• A proposal to shut down the #wikimedia-research IRC channel resulted in a "consensus we should stop sending new folks there and requiring the [Wikimedia Foundation'] research team to maintain it", but also in a decision to keep it open for now, with operation handed over to volunteers.
• See the page of the monthly Wikimedia Research Showcase for videos and slides of past presentations.

Other recent publications that could not be covered in time for this issue include the items listed below. Contributions, whether reviewing or summarizing newly published research, are always welcome.

Compiled by Tilman Bayer

From the abstract:^[4]

"Participants read Wikipedia or GPT-4o summaries of two historical events [the Seattle General Strike and the Third World Liberation Front strikes of 1968], with AI summaries maintaining factual accuracy while exhibiting different types of framing biases. Default AI summaries led to more liberal opinions compared with Wikipedia, demonstrating the persuasive capability of LLM's latent biases. Summaries purposefully induced with a liberal framing also led to more liberal opinions, regardless of readers’ ideologies. Summaries constructed with a conservative framing produced conservative shifts primarily among conservative readers."

See also a thread by one of the paper's authors

From the abstract:^[5]

"When Wikimedia users make edits without signing into an account, their IP addresses are used in lieu of a username. Wikimedia site dumps therefore provide researchers with over two decades worth of timestamped client IPv6 addresses to understand address assignments and how they have changed over time and space.
In this work, we extract 19M unique IPv6 addresses from Wikimedia sites like Wikipedia that were used by editors from 2003 to 2024. We use these addresses to understand the prevalence of IPv6 in countries corresponding to Wikimedia site languages, how IPv6 adoption has grown over time, and the prevalence of EUI-64 addressing on client devices like desktops, laptops, and mobile phones."

From the paper:

"The majority (∼64%) of the IPv6 addresses that are logged in Wikimedia edits appear only once"

From the abstract:^[6]

"This article presents neo-liberal notions of knowledge and market and explains why this is important for the functioning of digital platforms. Neo-liberals are concerned with everyday knowledge of the common people, their mental states and feelings, not intellectual knowledge. [...] Hayek defines market as a communication system that is digesting dispersed information. Millions of minds are doing data generation and processing. That way, neo-liberals see all digital platforms, including Wikipedia, as markets. Classical encyclopaedias are centrally controlled and expert driven, while neo-liberal markets create knowledge through crowds’ ‘voluntary exchange’ and ‘spontaneous cooperation’. The fundamental difference is that encyclopaedias were an Enlightenment project, while Wikipedia is producing recycled intellectual and layman’s knowledge without any political or revolutionary engagement."

This paper found that German and Italian "wikiquette" stipulates the informal "du"/"tu" among editors (instead of the more formal "Sie"/"Lei"), whereas French Wikipedia lacks consensus on "vous" vs. "tu". From the abstract:^[7]

"This paper asks [...] how the appropriate use of address pronouns is negotiated on talk pages of the German, French, and Italian Wikipedia. The talk pages of Wikipedia share features of CMC [computer-mediated communication] genres such as a dialogic structure and an informal writing style with non-standard language. There are two types of Wikipedia talk pages, whose data are considered in this study based on the multilingual corpora by the Leibniz Institute for the German Language: article talk pages, where authors negotiate online encyclopedic content, and user talk pages, where the contributions of individual authors are discussed. These two types of talk pages will be analysed for the study."

From the abstract:^[8]

"Using the complete dataset of the English, Spanish, and Italian versions of Wikipedia (2001–2020), we analyzed metrics such as the number of articles, creations, or edits performed by users. We calculated their distributions, adapted the Gini index to measure participation inequalities and employed network science methods to understand user-edit interactions. [...]

Our analysis confirms significant disparities in content generation and engagement, emphasizing content editing. However, we demonstrate that these differences coexist with extensive collaboration. Specifically, our findings reveal that disparities in participation levels and collaborative editing complement each other. Curatorial leadership by a central group of contributors is extremely collaborative, while occasional contributors intervene flexibly in specific contexts."

From the "Conclusion" section:

"Our first result has been to confirm the existence of strong inequalities in content production and participation that were already highlighted in the literature, focusing in particular on content editing. However, we have also shown how, despite such forms of gatekeeping of the core group of contributors, Wikipedia’s users who manage the vast majority of the edits carry out this task in a largely collaborative manner. That is to say, our analysis suggests that inequalities in the level of participation and high levels of collaboration are not antithetical, but rather mutually reinforcing building blocks of Wikipedia."

From the abstract:^[9]

We introduce WETBench, a multilingual, multi-generator, and task-specific benchmark for MGT detection. We define three editing tasks empirically grounded in Wikipedia editors’ perceived use cases for LLM-assisted editing: Paragraph Writing, Summarisation, and Text Style Transfer, which we implement using two new datasets across three languages. For each writing task, we evaluate three prompts, produce MGT across multiple generators using the best-performing prompt, and benchmark diverse detectors.We find that, across settings, training-based detectors achieve an average accuracy of 78%, while zero-shot detectors average 58%. These results demonstrate that detectors struggle with MGT in realistic generation scenarios [...]

From the "Experimental setup" section:

We generate MGT using four multilingual models from two families: proprietary and open-weight. [...] For proprietary models, we use GPT4o mini [...] and Gemini 2.0 Flash. For openweight models, we select Qwen2.5-7B-Instruct and Mistral-7B-Instruct. [...]

We evaluate six detectors from three different families: [...] Specifically, we use XLM-RoBERTa [...] and mDeBERTa [...] as training-based detectors, which we fine-tune with hyperparameter search; Binoculars [...], LLR [...], and FastDetectGPT (White-Box) [...] as zero-shot white-box detectors; and Revise-Detect [...], GECScore [...], and FastDetectGPT (Black-Box) [...] as zero-shot black-box detectors.

The proprietary detectors Pangram and GPTZero are not mentioned in the paper. (A recent investigation by Wiki Edu "found [Pangram] to be highly accurate for Wikipedia text".^{[supp 1]})

See also our review of an earlier paper by different authors that had relied on Binoculars (and GPTZero) for its conclusions: "'As many as 5%' of new English Wikipedia articles 'contain significant AI-generated content'"

Supplementary references and notes:

Prof. Madhav Gadgil (User:MadhavDGadgil) (1942–2026) was an Indian ecologist who championed environmental science, citizen-led open knowledge, and Wikipedia.

When many senior academics in India dismissed Wikipedia from a distance, Prof. Madhav Gadgil chose a different path: he logged in, showed up, and promoted it with great conviction. A pioneering ecologist, public intellectual, and chair of the Western Ghats Ecology Expert Panel, Gadgil believed that knowledge about local resources including biodiversity, rivers, forests, should be collated and used by local communities and not sit behind distant institutional walls. Instead, he saw Wikimedia projects as living platforms for citizen science — places where local communities could document their environments, hold authorities accountable, and democratise ecological knowledge. Until his passing in January 2026 at the age of 83, he remained a rare figure of his stature who actively bridged professional science, grassroots activism and the open knowledge movement.

Prof. Madhav Gadgil passed away in January 2026 at the age of 83. A pioneering ecologist, he established ecology as an academic research area at the Indian Institute of Science where he founded the Centre for Ecological Sciences. He headed the Western Ghats Ecology Expert Panel which he handled through public consultations and conversations across the region. He received a Padma Shri in 1981, the Padma Bhushan (2006), and was awarded the United Nations Champions of the Earth (2024). He was co-recipient of the 2015 Tyler Prize for Environmental Achievement.

He engaged and corresponded with several Wikipedians and was particularly interested in efforts to improve ecological and scientific content in Indian languages. He participated in outreach workshops in several states including Maharashtra and Kerala. He advocated the re-licensing of scientific and environmental literature under free licences, released several of his own books under CC BY-SA for digitizing them on Wikisource, and supported digitisation initiatives that enriched Marathi Wikisource. A significant portion of his father's library (Dhananjay Ramchandra Gadgil) had been digitized and made available through the digital library of the Gokhale Institute of Politics and Economics. He also encouraged the use of public datasets, including census data, to improve village-related content on Indic-language Wikimedia projects which resulted in the improvement of 25,000 village articles on Telugu Wikipedia.

Subodh Kulkarni, his close associate in the environmental movement and later an active Marathi Wikimedian, has noted Gadgil’s sustained encouragement of and support for the Wikimedia movement in India.

"Madhav Gadgil was a pioneering advocate for knowledge democratization, championing the role of grassroots communities in open platforms like Wikimedia. He envisioned these projects as vital "Citizen Science" tools for documenting local environmental data, biodiversity, and traditional wisdom, such as folksongs and folktales. By recording observations on issues like illegal mining and river health, Gadgil believed local communities could provide critical insights that formal science often overlooked. He envisaged these digital repositories to serve as a medium for social audits, holding authorities accountable through transparent, community-led data.
To support this vision, Gadgil collaborated extensively with the Centre for Internet and Society (CIS) and various civil society organizations to scale awareness. He spearheaded thematic content generation & digitization drives and led by example by donating his own published works to Wikimedia Commons under open licenses. His influence successfully persuaded numerous authors and institutions to embrace the relicensing process, significantly expanding the Indian public domain. Furthermore, Gadgil served as a hands-on resource person for Wikimedia workshops across Maharashtra, Goa, Telangana, Karnataka, and Kerala. His sustained engagement effectively bridged the gap between professional scientific expertise and grassroots documentation, leaving a lasting legacy in the open knowledge movement."

Another user, Shyamal, grew up in the same campus neighbourhood where Gadgil worked and was influenced into contributing to the English Wikipedia after attending a workshop on biodiversity databases in 2005. Gadgil had then given a talk to the attendees, noting how Wikipedia had become particularly valuable within the community of mathematicians (this was based on what he had heard from his son who is now a professor of mathematics) and that other science communities would do well to emulate. – PS, SK, S

Fredrick Brennan had made over 11,000 contributions in his main User:Psiĥedelisto account, spanning across multiple Wikimedia projects; 9,807 in the English Wikipedia alone. He was prolific in his contributions to articles related to linguistics, typography and law (including Philippines law). Using his own open-source font editor MFEK, he designed free fonts (freely licensed for personal and commercial use) made available on his personal website. At least four of the articles Brennan wrote achieved good article status, according to his userpage: 2channel, Osteogenesis imperfecta (a condition he was born with), Deseret alphabet, and Bureau of Immigration Bicutan Detention Center. After 8chan, the site he founded, came under the management of Jim Watkins, it became a mecca for the QAnon conspiracy theory, and, later, housed the manifestos of the attackers of the 2019 Christchurch, Poway, and El Paso shootings. Brennan fought to have the site shut down and also participated in podcasts which critically researched QAnon. His founding of 8chan earned him a Wikipedia article, though he disputed his notability on his userpage. He spoke Esperanto fluently, and had at least some proficiency of Spanish, Tagalog, Japanese, Chinese, Hebrew, and Russian. He converted to Christianity in 2019. – Mimyuu, V

Mark Miller (User:Mark Miller) began editing Wikipedia in January 2007 and had made over 50,000 edits, expanding articles about a variety of topics, especially military history and Hawaii. Mark was proud of his Hawaiian heritage (he also signed with his Hawaiian name Maleko Mela) and descended from the formal Kamehameha family from the Royal Court of Kamehameha III. He took some pages to good and featured status and won the Million Award twice. He also helped out new users at the dispute resolution noticeboard and the Teahouse. Mark was instrumental in the earliest days (late 2012) of the Editor of the Week award. He was known as User Amadscientist back then and was an integral participant in the creation discussions for Wikipedia:WikiProject Editor Retention and the EDDY Award.

Mark was an amazing artist, a passionate researcher and writer (especially genealogy), cook, gardener, avid outdoorsman, and enjoyed traveling. Just before his passing he had recently discovered a love of cooking, and enjoyed making lasagna especially for his neighbors.

Mark will be dearly missed by his beloved lifelong partner of 37 years. They enjoyed many adventures together and especially loved traveling. Mark also loved his dogs Zeus and Loki, and they were important members of his family. – G

Chip Berlet (User:Cberlet) was an American investigative journalist, research analyst, photojournalist, scholar, and activist specializing in the study of extreme right-wing movements in the United States. His Wikipedia activity focused on improving articles related to his field. – A

This essay was written in 2024, detailing potential security issues regarding the interface administrator user right on Wikimedia sites. It was submitted, and we now publish it, due to its great relevance to the recent security incident, which is also the subject of this issue's Special Report and covered in News and Notes.

Interface administrators are users with the ability to edit sitewide CSS and JavaScript. In principle, it is possible for a malicious interface administrator to do almost all things which are not "supposed to" be tied to the interface administrator privilege, as well as some things which are not "supposed to" be possible at all.

This essay will contain some technical information about how such an attack would work, because very few people have these privileges, and they are all highly trusted members of the community. The comparatively negligible risk that one of them will decide to try any of these techniques out is, in my judgment, outweighed by the theoretical significance of these attacks (particularly as applied to subjects like account security, inactivity, and the global sysop and global interface editor rights). I will not be showing specific code samples, because I do not believe this is necessary to explain the risk, and I do not want to facilitate the actions of any script kiddie who might obtain unauthorized access to an interface administrator's account in the future.

While the attacks described below are rather frightening, I would also like to stress that this is not "new information." None of these attacks are peculiar to MediaWiki or Wikipedia, nor do they represent security vulnerabilities that ought to (or can) be "fixed." Rather, these attacks are the logical consequence of giving a group of users unlimited control over JavaScript. Anyone familiar with offensive security, web technologies, and basic facts about Wikipedia gadgets and user scripts should be able to rattle off a similar or identical list of attacks within minutes (and they might well do better than I did). Accordingly, I do not consider this a report of any kind of vulnerability, and have not placed it under an embargo. I have not filed a Phabricator ticket or requested a CVE, and I do not encourage anyone else to do either of those things. The developers are aware of this - that is why we only have 15 local interface administrators, why they're required to use 2FA on their accounts, and why the interface administrator group even exists in the first place (the right was split out in MediaWiki 1.32, ca. April 2018, specifically because of attacks like those discussed below^[1]).

It should go without saying, but nothing in this essay is meant to suggest that anyone who holds this right is likely to take any of these actions. If you are an interface administrator, please interpret this essay as a friendly reminder that your account is very powerful, and you should take account security seriously. For everyone else, think of this as a thought experiment describing what might happen, if an interface administrator's account were compromised.

The ability to edit sitewide JavaScript probably sounds innocuous to some readers. To properly understand the threat, we need to consider the scope in which sitewide JavaScript executes. Specifically, sitewide JavaScript has all of the same powers and privileges as any gadget or user script, but it does not need to be enabled or imported to work. It just runs, automatically, on every page load, for every user who has not disabled JavaScript altogether (or otherwise blocked it). As far as Wikipedia is concerned, the sitewide JavaScript is you - in the sense that the sitewide JavaScript can do everything^{[note 1]} that you, the human sitting in front of your computer, can do. This creates many opportunities for mischief of various kinds.

The most obvious thing to do is to impersonate whichever user happens to be executing the malicious JavaScript. For the purposes of this discussion, a user is "impersonated" if the attacker is able to cause that user's account to perform an action that would generate either a history event (i.e. an edit) or a log entry, without the user approving (or, possibly, even knowing about) that action. By itself, this is already enough to wreak substantial amounts of havoc: The attacker can make other users commit acts of vandalism, start a fight on ANI, or even suppress inconvenient edits and log entries.

This is actually much less difficult than it sounds. All the attacker really has to do is copy the source code of e.g. Twinkle, rip out the user interface, and replace it with code that decides what the attacker wants the victim's account to do (via a command and control server or by other means). Then, the next time the victim loads any page, their account will silently do whatever the attacker wants it to do. If Twinkle lacks code to do that, then the attacker can just use another tool instead, or write their own. All significant on-wiki actions can be done via JavaScript, given enough effort.

The obvious problem with stage 1 is that it generates an edit in the history of MediaWiki:Common.js... or does it? While an attacker could edit Common.js to perform these attacks, this is rather obvious and would be spotted by another interface administrator pretty quickly, if they ever look at that file. On the other hand, it could be obfuscated by editing something like MediaWiki:Group-user.js, which is much less commonly edited, but just as dangerous.

Of course, eventually, someone is going to notice that the wiki is under attack, and try to identify the attacker in order to revoke their privileges. But the attacker has control over the site's JavaScript, so they can hide their own edits (or the edits and log actions of others, for that matter), replace the apparent content of the interface page with the innocuous previous version, and even reprogram the edit interface to re-insert the malicious code when saving changes. A user with JavaScript disabled (or browsing in safe mode) would be able to "see through" this trickery, but in order to do that, they would first need to figure out that someone is using JavaScript to pull off the attack, or they would need to routinely disable JavaScript and figure it out "by accident." The fact that the attacker has access to blocking, suppression, etc. would make it much more difficult for such a user to raise the alarm, even after they figure it out.

The attacker doesn't have control over the entire universe. They can't stop people from talking to each other over IRC or by other off-wiki means. Sooner or later, the community is going to notice discrepancies between what they do on-wiki, and what the wiki's history and logs appear to reflect. Given enough time, we can unravel the whole plot, take the attacker's privileges away, and undo at least a large portion of the damage caused (but probably not all of it, because impersonation leaves log entries identical to non-impersonated actions, so you would have no way of telling what was an impersonation and what was a "real" action, other than by analysis of the malicious and probably obfuscated code).

Or at least, that's what we (the community) would like to happen. Unfortunately, things become much more complicated, because Special:Mypage/common.js exists. This page is normally used to enable and configure user scripts, which are like gadgets, but (in most cases) not polished and/or popular enough to turn into "real" gadgets (there's only so much you can reasonably stuff into Special:Preferences before it gets impossible to navigate). However, you can put arbitrary JavaScript code on that page, and it will run on every page load when you are logged in. Since the attacker can force you to take actions without being aware of it, they can install malicious JavaScript on your personal common.js page, and continue to manipulate your account even after the attack has been removed from the sitewide JavaScript. There's nothing stopping an attacker from doing this to literally everyone who has ever been impersonated. Or, if that's too obvious, they could do it to a very small selection of high-privilege accounts, and hope that the community does not notice.

In an ideal world, the community would be aware of this threat, and systematically audit all edits to common.js and vector.js, for all users, during the affected period. Realistically, that's a lot of auditing, especially considering this attack might have been ongoing for a very long time, so the more plausible outcome is an adminbot that reverts all changes to those pages during the period of the attack, and then leaves a talk page message informing the user that they should redo the change if they want to keep it. Since the overwhelming majority of fully automated bots do not execute JavaScript at all, such an adminbot would be immune to any chicanery.

There is one other possible attack that might become relevant at this stage: Booby trap the login page^{[note 2]} to steal credentials. For users without 2FA, those credentials could later be used to manually take over their accounts, even after the attacker's privileges have been revoked. Hopefully, the community would also notice this, and alert the WMF to force a password reset on all users.

Overall, persistence seems to be a harder problem than impersonation or concealment. An attacker would need to be very creative to continue the attack after the community is fully engaged with stopping it. On the other hand, some diligence would be required on the part of either the community or the WMF to identify and shut down every possible avenue of persistence. It would be all too easy to miss something in the mad rush to stop the primary attack.

For further Signpost content on this topic, see previous Signpost coverage, and coverage in this issue's In the media and News and notes sections.

After the website archive.today launched a DDoS campaign against a small blog in January 2026, a request for comment was started. After the discovery of tampered archives, consensus was reached to deprecate the site used almost 700 thousand times on the English Wikipedia.^[1]

Note: archive.today is not to be confused with archive.org, which is the domain of the unafilliated Internet Archive.

On February 5, a suspicious script, added to archive.today's CAPTCHA page, was mentioned at Village Pump (Technical) by a Wikipedian, after it had been previously reported on Hacker News in January. This developed into a request for comment on February 7 over what to do about the site, as addressing the widespread use of the site could lead to significant disruption. With archived web pages being used to verify information across the wiki, concerns were raised about the impact of deprecation or blacklisting. Other Wikipedians raised safety concerns over linking to a website which is running malicious code in user browsers, and some argued that it was a breach of trust, and brought up previous discussions over the sites practices.

archive.today has been cited almost 690 thousand times on Wikipedia, and the main objection to deprecation was on the grounds of losing access to many sources exclusively archived there. While the RFC was still ongoing, several editors began discussing ways to "deprecate without losing verifiability" by creating archives on the Wikipedia platform, using a tool that would fetch content from the archive.today site and remove Javascript.^[2]

The process was monitored by the Wikimedia Product Safety and Integrity team, who left a note explaining their approach and that their view, and encouraged the community to "carefully weigh the situation before making a decision on this unusual case."

On February 18, evidence emerged that some archived pages had been modified by the webmaster, where an alias of the webmaster was replaced with the name of the owner of the blog.^[4] This led to the RFC being closed February 20 with a consensus to deprecate the source, remove links to the site, and eventually add it to the Spam blacklist.

Several members of the community have created guidance to editors on how to proceed with the removal of links to the archive, and have provided resources to aid and direct the process, such as a list of high traffic articles linking to the archive, instructions for users who need to visit the site, and a CSS script which highlights references linking to the domain or any of its mirror sites.

Discussions are ongoing on other Wikimedia projects, and an index has been created on Meta-Wiki. The French Wikipedia followed the English language edition, with the service added to their spam blacklist.^[5] Over on Meta-Wiki, an administrator declined a request to globally blacklist the archive, as "There are too many usages on too many wikis. [English Wikipedia's] consensus alone isn't going to be sufficient to blacklist this domain globally." They added that "the next step would be to open a global RfC."

The incident has drawn widespread attention, with the RFC having over 200 participating editors, 30 thousand pageviews, and more than one thousand total edits. Additionally, the guidance page has had over 13 thousand views, and the archive.today article peaking at 9093 views on February 21, a day after the site was deprecated. Several media outlets including Ars Technica and The Times of India also produced news coverage of the decision; see this issue's In the media for further information.