Research:Patrolling on Wikipedia/Report

This report represents a synthesis of my findings from interviews with four experienced Wikipedia editors as well as my review of previous research on the topic of patrolling, vandalism, and editor workflows. The report focuses on three themes related to patrolling on Wikipedia:

the differences between fast (real-time) and slow patrolling workflows using the 'standard' set of patrolling tools available across all(?) Wikipedias
the experience of patrolling on a single-project basis, and the differences between small and large projects in this context, and
the experience of patrolling across multiple Wikimedia projects

Under each of these thematic headings, the report presents a summary of the findings from the interviews, followed by a list of the current practices that patrollers engage in, followed by a threat model for this type of patrolling—expressed as a list of structural vulnerabilities or attack vectors described by interviewees.

I borrow the term 'threat model' and other language from cybersecurity to describe these phenomena because it seems to be a good fit for how the patrollers I interviewed think and talk about vandalism (especially more sophisticated approaches to vandalism, such as coordinated disinformation campaigns, which are the primary focus of this research project). I also believe that thinking in these terms helps focus the report on assessing risks and prioritizing work to address those risks.

The report concludes with a set of recommendations for technological interventions and further research.

Patrolling fast and slow

Generally speaking, there are two main approaches to patrolling: fast and slow. I'm using this term because it invokes the title of Daniel Kahneman's famous book, which describes two separate human judgement mechanisms: System 1 (quick, instinctive, heuristic) and System 2 (slower, logical, deliberative). It turns out that this System 1 and System 2 distinction does a pretty good job of reflecting how patrolling works across many editors, projects, and contexts.

Both of these systems/approaches are mediated by a set of core tools that are available in some form across all wikis: tools like specialized user roles, Special: pages, revision histories, diff pages, etc. In addition to this more-or-less standard and universal toolset, editors on many Wikipedias have developed additional mechanisms to facilitate fast or slow patrolling, like bots and gadgets. These mechanisms will be addressed in greater detail in the next section: Patrolling a single Wikipedia.

Fast patrolling is generally mediated by the RecentChanges feed (or specialized tools that draw from this feed). Fast patrolling generally focuses on identifying and addressing clear cases of vandalism, and the vandals who perpetrate it, to minimize damage: e.g. quickly deleting Attack pages, reverting immediately damaging edits, and blocking accounts and IPs that are actively and persistently vandalizing.

On many wikis, the ‘patrolled’ parameter associated with each revision allows multiple editors to engage in this type of patrolling simultaneously with a minimum of duplication, edit conflict, and wasted work. This flag can be viewed in the RecentChanges feed and assisted editing programs, and can be changed by anyone with the patroller userright, which exists across all projects. Editors mark an edit as patrolled once it has been reviewed and they have either a) seen no issue with the edit that requires immediate remediation or b) addressed the issues they found (e.g. revert a bad faith edit, correct a damaging edit, warn the original contributor, notify a local admin). The ability to set the patrolled flag is mediated by a userright. On some wikis, it is easier to gain this userright than on others.

Slow patrolling is most frequently mediated by editors’ personal watchlists, but also sometimes mediated through dashboards, bots and WikiProjects. Slow patrolling focuses on reviewing older (but still, generally speaking, relatively recent) edits and pages. Slow patrolling is done for two reasons: first, to make up for ‘gaps’ in fast patrolling—i.e. to review a batch of edits that were made yesterday but never marked ‘patrolled’ because no editors were engaged in ‘fast’ patrolling during the time period that these edits appeared in the recent changes feed. Second, it is done to apply additional scrutiny to edits that may not have been initially identified as vandalism when they were patrolled—perhaps because the patroller was moving too fast, or they lacked the necessary contextual information or expertise to identify the vandalism initially.

English Wikipedia is something of an exception with respect to the patrolled flag: on that project, the patrolled flag is only for newly-created pages. Individual (non-page-creating) edits cannot be marked as patrolled. This seems to be for historical reasons, which are not entirely clear, but which have some negative repercussions for users of patrolling tools, which will be discussed below.

On English Wikipedia, and any other projects that do not attempt to mark each edit as patrolled in a timely manner, or that don’t allow normal edits to be marked as patrolled, the distinction between fast and slow patrolling is hazier because it’s not possible to determine that any particular edit has ever been reviewed by another experienced editor.

Current approaches

Fast patrolling

The patrolled flag allows editors with the associated user right to mark edits that are not vandalism (or vandalism edits that they have personally dealt with) as 'patrolled', signalling that others monitoring RecentChanges need not review them.
Many Wikipedias have AbuseFilters in place that tag certain kinds of probable-vandalism edits, or prevent them from being saved in the first place
RecentChanges filters can be combined to easily monitor for common attack vectors in near real-time. ORES predictions are available via RecentChanges on many Wikipedias.

Slow patrolling

Editors add pages that they are interested in monitoring on an ongoing basis to their personal watchlists, and monitor these watchlists frequently for recent suspicious edits. On some Wikipedias, the enhanced edit review filters used on RecentChanges are also available on watchlists.
The RelatedChanges feature provides the ability to create shared public watchlists of all pages that link to (or are linked from) a given page.
Editors can review the history of a specific page to identify past vandalism to that page.
Editors can view the full history of (non-deleted) edits by a given user or IP address using the dedicated Special:Contributions page.
Editors can check all (public) logs associated with a given user account, IP address, or page using the Special:Logs

Threat model

On some Wikipedias, the patroller userright must be applied for, rather than automatically assigned based on registration date or edit count. Both approaches create potential attack vectors. If a project requires potential patrollers to meet an excessively high threshold to gain the userright, they may suffer from a lack of patrollers. On the other hand, if the criteria for gaining the patroller right are trivial (and especially if they are automatically granted after a given edit count or account age threshold are reached), malicious actors who have registered an account may be able to become patrollers and patrol their own edits (as IPs, or under a sockpuppet), thus hiding their damaging edits from other 'fast' patrollers.
On English Wikipedia, the patrol flag is only displayed in RecentChanges for edits that create new articles. This makes the standard 'fast' edit review process ineffective.
'Slow' patrolling is serendipitous—it depends on the given article being watchlisted by a (currently active) editor and/or a currently active editor reviewing the article history page.

Patrolling a single Wikipedia

Patrolling takes different forms across different Wikimedia projects. The workflows of patrollers are mediated by a variety of factors. The principal factors are:

the type of vandalism or disruptive editing being targeted
the primary type of content hosted by the project (e.g. longform text in the case of Wikipedias, rich media and structured data for Commons and WikiData)
the size of the project in terms of edit volume (esp. proportion of edits from IPs and newly-registered editors), which roughly corresponds to 'size' in terms of pageviews and articles too
the size of the project in terms of number of active registered editors
the number of active contributors on the project who possess elevated user rights and/or particular subject matter expertise
the availability of specialized patrolling tools, beyond those implemented by default across all Wikipedias (e.g. MediaWiki extensions like AbuseFilter). These specialized tools include bots, gadgets and userscripts, assisted editing programs, special-purpose wikipages (reports, triage dashboards, and noticeboards), off-wiki communication channels, and standalone web applications.

Current approaches

Types of vandalism

Some kinds of vandalism, such as abusive language, unexplained page blanking or page moves, have a consistent enough signature to trigger abusefilters. Other types are easy to detect by algorithms such as the machine-learning models that power ClueBot_NG and ORES, or the copyright infringement detection API. Other types of vandalism such as personal threats, libel, slander, disinformation may require human judgement to identify and address.

Project size

On larger projects, there are often enough editors who self-select into patrolling work (with or without the patroller userright) that they are able to provide near-real-time coverage of recent changes on a consistent basis. Projects with fewer active editors may not be able to ensure real-time review—however, if the volume of edits is correspondingly small, edit review may be a matter of a couple editors performing a daily or weekly 'batch' review of recent changes and catching the majority of recent vandalism that way.

Elevated user rights

A project with at least a few active editors with user rights such as rollbacker, administrator, and checkuser will be better able to identify and address many forms of vandalism efficiently.

Content model

The typical forms of vandalism, and the mechanisms for detecting and addressing vandalism, are different for projects like Wikipedia that host mostly unstructured, longform text, compared with media file uploads (Commons) or structured data (WikiData). The underlying architecture of the platform affords and constrains how patrolling works—for example, multi-content revisions on WikiData allow editors to view easily see what part of a WikiData item was edited directly from RecentChanges, a feature that is only partially supported on Wikipedias (via section editing tags in revision comments).

Specialized tools

There is no canonical list of all specialized tools that editors have developed and deployed to support patrolling. MediaWiki is an open platform and individual editors (and whole editing communities) have created a complex ecology of innovative software tools and other sociotechnical mechanisms to make their work easier and more effective. The tools listed here are the ones that interview participants shared with me, as well as other tools I came across during my review of the related work.

Many of these tools work in concert with one another (e.g. a bot may update an on-wiki report or noticeboard page). Some of them aren't particularly technical at all—e.g. specialized forum pages for reporting suspicious edits and requesting admin assistance.

Bots

Some Wikipedias, including English, have anti-vandal bots that automatically revert suspicious edits. Other Wikipedias (per local policy) don't let bots revert edits, but do let them flag edits for human review.

ClueBot_NG

On-wiki reports and triage pages

These pages contain regularly-updated lists of articles (or individual revisions) that are organized in a prioritized fashion to facilitate shared awareness or collaborative backlog grooming by groups of editors working independently. The Vandalism Checklist groups unpatrolled recent edits into batches that individual editors can claim (this avoids duplication of patrolling work). Most edited articles provides a list of the articles with the highest recent edit count—useful for focusing patrollers' attention on topics that are receiving a lot of attention due to external events (e.g. breaking news) and therefore may be more vulnerable to vandalism, or for which a spike in activity might be harder to explain and therefore worth investigating. These pages are almost always maintained by bots. Since bots require more active supervision than many other kinds of software tools, and because cross-wiki bot approval is hard to attain, the majority of these reports only exist on a single wiki, although different wikis may have bots that substantially duplicate the same functionality with different codebases and different maintainers.

Gadgets, userscripts, and extensions

Gadgets and Extensions (available to all users on a wiki, if the wiki allows it) and userscripts (enabled on a per-user basis) are a common type of tool for patrolling. These tools are good for automating tedious multi-step manual workflows, and providing live or near-live triage feeds or dashboards. Some of these (like RTRC) are enabled across multiple Wikimedia projects. Others are only available, or only fully functional, on a single project (like Twinkle and PageCuration) because they were designed to suit the needs of that project, and broader implementation would require substantial localization or other code refactoring.

Assisted editing programs

These are generally cross-platform desktop applications that allow users to view and act on live streams or batches of revisions. They authenticate with the individual's user account, and make edits to Wikipedia on that user's behalf, via the MediaWiki API. They often duplicate the functionality of standard MediaWiki feeds or interfaces (like Special: pages) but provide additional metadata. Huggle, for example, shows the number of talkpage warnings an editor has received alongside their edit in the patroller edit-review interface. These tools generally provide a lot of useful filters and query functionality, as well as standard edit-level patrolling actions (even actions, like deleting pages, that are only available to administrators). Some may provide the ability to perform batch actions across multiple revisions or pages simultaneously. Like gadgets and extensions, each of these applications are often only available for one or a few Wikipedias--partially due to the investment required to translate all documentation and interface text, and partially due to the investment required to make all namespace names, character sets, template titles and parameters etc. fully configurable rather than hard-coded.

On-wiki noticeboards

Many Wikipedias feature dedicated noticeboards that are closely monitored by Administrators. Editors who notice vandalism in progress can use these noticeboards to request Admin support in quickly blocking or banning vandals, deleting unwanted content, or protecting target pages.

Adminstrators' Noticeboard/Incidents.

External communication channels

Public mailing lists and IRC channels provide mechanisms for real-time reporting of vandalism and other time-sensitive issues for which users with elevated privileges (admins, checkusers, oversighters, stewards) need to be aware or involved. Private mailing lists and IRC channels—generally only available to users who hold a specific userright—allow this group of users to maintain awareness of and share information about particular kinds of recent activity (such as suspicious edits associated with sockpuppetry, in the case of Checkusers). Private channels that serve both roles (awareness and information sharing) are often shared with IRC bots that post notifications of recent events (edits, log actions). In some cases, channel users with the appropriate privileges can perform actions on Wikipedia from within the channel by passing commands to one of the bots. Both kinds of channel are especially important for smaller Wikipedias, which may not have enough local admins to ensure prompt response to requests for assistance.

Web applications

These applications are generally hosted on WMF labs. Many of them function as dashboards of one sort or another: feeds of recent changes, triaged (back)logs, or interfaces for looking up aggregated metadata about a user or page. XTools and Global user contribs both provide essential anti-vandalism functionality, allowing anyone to query a given user's recent and historical properties and activities by Wikimedia project, namespace or other relevant criteria.

Threat model

None of the six principal factors listed above are equally distributed across projects, or across time. Therefore, it is not possible to develop a single threat model for within-project patrolling that fits all Wikimedia projects.

However, it is useful to model threats to larger projects and smaller projects separately (assuming a very rough correspondence between number of registered editors and administrators, articles, daily edits, and daily views). For example, the size of the Wikipedia in terms of active editors (#4 above) has a big impact on #5 (elevated user rights) and #6 (availability of specialized tools). The current research doesn't allow for a sharp distinction between 'large' and 'small' projects, so these definitions will be left vague for now. Suffice it to say, English Wikipedia is a large project, while Greek Wikipedia is (according to one interviewee, who is an admin on that Wikipedia), a small project. In further research, it would be useful to attempt to develop a consistent and coherent set of criteria that can be used to differentiate between small and large (and medium sized?) Wikipedias, as these categories relate to patrolling workflows and threat models.

Wikimedia Commons and WikiData, while both large projects, have their own distinct threat model due to the type of content they host and the unique way that content is surfaced across the Wikimedia ecosystem. Since the focus of the current project is to investigate patrolling on Wikipedia(s), my literature review and interviews did not focus on the workflows of people patrolling primarily or entirely within these projects. The threat model for patrolling work that covers one or more Wikipedias as well as Commons and WikiData is discussed in the next section: Patrolling Across Wikimedia projects.

Large Wikipedias

Larger projects, and especially English Wikipedia, have a rich ecology of specialized tools that, taken together, help preventing, detecting, and addressing most forms of vandalism. Large projects generally also benefit from many eyes, and a large number of editors with elevated userrights active at any given time. However, large Wikipedias are also more inviting targets for some forms of vandalism: they have a lot of exposure (many articles, many readers, high search engine rankings). So the threat model for large projects focuses on persistent, strong, sophisticated, and strategically motivated vandalism. This vandalism can range from persistent disruption-for-disruption's-sake to externally-coordinated long-term disinformation campaigns run by well resourced interested parties such as ideologically-motivated interest groups, corporations, or even potentially nation states.

Sockpuppets and IP-hopping. Vandals who are invested in disrupting Wikipedia create multiple accounts and spread their edits among them, to avoid detection, avoid sanction for rule breaking or to create the illusion of good-faith collaboration or consensus. Vandals can also use VPNs and proxies to change their IP address multiple times within the same session (and obscure their geographic location), making it very difficult to track their edits using standard tools like the Special:Contributions page.
Sleeper accounts. Editors may create accounts and then let them lay inactive for a while (potentially after making a small number of innocuous edits) to avoid certain patrolling mechanisms that call attention to activity by very new accounts and/or accounts with very few edits. After a period of time, the editor begins using this (now more-legitimate-looking) account to make edits that they intended to make.
Account hacking. There are hundreds of thousands of Wikipedia accounts that have never edited, or that haven't made edits in many years. If these accounts are no longer monitored by their creators and don't have secure passwords, they are susceptible to being hacked, in which case they have the same advantages for a vandal as sleeper accounts. Malicious actors have also in the past hacked the accounts of administrators and other editors with elevated userrights. Some userrights, on some Wikipedias, have activity or time-based expirations, which limits the potential effectiveness of this approach. However, I do not know how many inactive and unmonitored administrator accounts exist across the Wikimedia ecosystem, or what the state of account hack monitoring or reporting infrastructure looks like on different wikis.
Meat puppets and tag-teams. Multiple editors working in concert (and coordinating their activities on other social media platforms, through private forums or messaging services, or even face to face) can spread edits among themselves to avoid detection (similar to sockpuppets) and present the illusion of collaboration. They can also take part in the same deliberative discussions—either sowing confusion or making supporting statements to give the impression of a robust consensus.
Brigading. Malicious actors on external forums can also organize large brigades to descend on a Wikipedia article, discussion, or topic simultaneously with a shared goal. The goal may be simply to disrupt Wikipedia (slowing down decision-making, forcing vandal-fighters to work longer and harder), knowing that most of the damage they do will eventually be undone. The goal may also be to overwhelm patrolling workflows or distract attention in order to allow other concurrent activities to occur unnoticed.

Small Wikipedias

Smaller Wikipedias generally have fewer articles, and fewer edits by new editors and IP addresses, which reduces the overall volume of things that need to be patrolled. On the other hand, smaller Wikipedia projects are likely to have access to fewer specialized patrolling tools, fewer active editors, fewer (or no) active editors with elevated userrights, and fewer subject matter experts. In some cases, since a great deal of the Movement communication forums and process documentation (the stuff on Meta and MediaWiki.org) is only available in English (and other large global languages), a smaller Wikipedia is more likely to have fewer editors who are able to access and communicate with people outside of their Wikipedia. This can reduce awareness of effective patrolling tools, and create barriers to access to global noticeboards (such as the Steward request board on Meta).

Major bots and assistive editing programs do not work with many projects. Huggle, for example, only works on English Wikipedia. Much of Twinkle’s functionality was written with English Wikipedia in mind, and localisation may be difficult or impossible on other languages. Others, like LiveRC, are implemented across multiple projects (and can also be enabled as a userscript on additional projects, although I did not test this myself). ClueBot_NG and ORES-based anti-vandal bots must be built around locally-trained models, and developed and maintained by editors who know how to program (and presumably, are also fluent in the local language and members in good standing of the local project).
Smaller Wikipedias tend to have fewer local tool-builders and too-maintainers. Fewer volunteers on a project has who can build software means less software will be built for that project, even if there is an unmet need. In addition, many vital vandal-fighting tools are unmaintained or under-maintained, even on large Wikipedias. On large Wikipedias, it may be possible to find a new maintainer to pick up where a departing tool-builder left off. Smaller projects are more vulnerable to a single-point-of-failure mode where someone maintaining a critical local vandal-fighting gadget or bot decides to stop maintaining the tool, but no volunteer with sufficient programming expertise is available to take on ongoing maintenance.

Smaller projects may lack sufficient local editors with elevated userrights or subject matter expertise--or even simply lack enough editorial eyes--to defend against subtler forms of vandalism, even though the lower overall number of contributions and contributors on these projects make the overall patrolling workload much lighter, on average.

Smaller projects are less well equipped to deal with coordinated high-volume external attacks, and may need to reach out to Stewards and Global CheckUsers, so they have less control on the timing or outcome of the intervention.

Smaller Wikipedias have a higher risk of being hijacked by insiders: cabals of established editors (with or without elevated userrights) who through coordinated action can make changes to project rules or content that allow them to suppress other viewpoints, hound other editors, or otherwise prioritize their own content preferences or point of view. This phenomenon has been reported to me by one of my interviewees, and there have been extensive reports of this phenomenon on Croatian Wikipedia.

Effective AbuseFilters are difficult to develop, as they often require programming knowledge or experience with regular expressions. Although some AbuseFilters are global, these tend to be more abstract filters are less likely to catch vandalism that is identified primarily by language cues. I do not know how many projects create their own custom AbuseFilters.
Smaller wikis may become targets of vandalism by editors who have been blocked or banned from larger wikis, and who are motivated to continue vandalising and are looking for opportunities to do so with less scrutiny. This is covered in more detail in the next section Patrolling across Wikimedia projects.
Lack of access to local reporting and remediation systems. There may not be local rapid-response noticeboards (like AN/I on English Wikipedia) available on smaller wikis, or a sufficient number of users with elevated userrights to staff those noticeboards. A regular editor who needs support dealing with vandalism or other timely issues, may simply need to know who to reach out to. Global noticeboards set up to support small Wikipedias with this problem are discussed in the next section.

Patrolling across Wikimedia projects

Although many Wikimedia projects, even smaller projects, have an effective set of mechanisms for dealing with the majority of expected threats on their particular project, there are still structural vulnerabilities in the sociotechnical architecture of the Wikimedia project ecosystem that create attack vectors for malicious actors. The most important of these, which affects both large and small projects, is the lack of mechanisms for monitoring and countering vandalism that takes place across multiple projects (over both short and long timescales).

It is easy for readers and editors to move between projects. Wikimedia projects are densely interlinked. A reader can easily access different language versions of the same article in a single click. Furthermore, individual Wikipedias also directly embed content that is hosted on WikiData and Wikimedia Commons. Accounts are global by default, and the reading and editing interfaces are highly standardized across projects. New mobile microcontribution workflows available through the Wikipedia App allow editors to contribute image captions (on Commons) and article descriptions (on WikiData) from within the context of a Wikipedia article.

To summarize, while many reading, search, and contribution workflows have been effectively globalized, patrolling tools and mechanisms for monitoring changes across projects, identifying and addressing vandalism, and dealing with persistent or coordinated disruptive behavior have not kept up. This mismatch can create information asymmetries and power imbalances between vandals and vandal fighters, where the vandals hold a distinct advantage. Many editors are primarily focused on a particular Wikipedia. Most editors only have elevated privileges that allow them to efficiently deal with vandalism (such as patroller, rollbacker, and checkuser) on a single Wikipedia. Most anti-vandal tools only work with one Wikipedia at a time. Most sanctions (warnings, blocks, bans) are specific to a particular Wikipedia.

Taken together, these factors make it easier for vandals to avoid detection and sanction--especially persistent and coordinated vandals. Make it harder to identify long-term trends or emerging patterns of suspicious behavior that occur across projects, and they make it harder for the project ecosystem as a whole to evolve or design more effective mechansims for addressing cross-wiki vandalism.

Current approaches

Unlike the case of single projects (see Patrolling fast and slow above), there are very few tools built into the MediaWiki platform that support cross-project patrolling. To address this gap, movement volunteers have developed several innovations tools, techniques, and projects for performing cross-wiki patrolling and vandal fighting.

Standard or default mechanisms

Community-created and managed mechanisms

Threat model

Despite the substantial efforts of dedicated volunteers, effective cross-wiki governance, monitoring, patrolling, reporting, and adjudication mechanisms remain scarce, and there are a relatively small number of individuals who have the interest in and ability to perform moderation and patrolling activities across wikis. The lack of any dedicated, centralized, and consistently maintained tools combined with an over-reliance on self-organization and individual volunteer initiative to maintain the tools and process that exist, makes these cross-wiki processes both less effective and more time-consuming than they could be.

Wikipedias

Persistent or high-volume vandalism occurring on an article in one Wikipedia is invisible to patrollers who are monitoring the linked article (or other articles in the same topic) on any of the other Wikipedias.
Most user and range blocks, bans, and page locks are local, but vandals can easily move to related articles on other projects if they are prevented from vandalizing locally.
Steward Request noticeboard is not fully internationalized: instructions on how to submit requests are not available in all languages, and Stewards themselves do not speak all potential languages.
Submitting a Steward Request is a high-touch process for the submitter; triaging and resolving these requests through the noticeboard page (seeking clarification and contextual information, performing background research, communicating with stakeholders across multiple wikis, reviewing local and global policies, etc.) is time-consuming for the Stewards themselves.

WikiData and Wikimedia Commons

Content hosted on WikiData and Wikimedia Commons is not only linked from Wikipedia articles, but often transcluded into or surfaced through Wikipedias. Vandals making edits to this transcluded content may face less scrutiny on the Wikipedias where the content shows up. An example of this is the 2019 SEM campaign by the company The North Face.^[1]
Microcontributions can be made to Wikimedia Commons and WikiData by editors who have never visited those projects, through the Wikipedia mobile app. It is unclear how these microcontributions are patrolled locally.

Recommendations

Design interventions

Some of the recommended design interventions below are best implemented as standard tools (i.e. new default MediaWiki extensions). Others may take the form of standalone applications, published datasets, or APIs that community volunteers can build tools and workflows on top of.

Cross-wiki watchlists

This feature would make it much easier for editors to practice slow patrolling across all the projects they're interested in; not just the one they edit most. It would also make it easier for Stewards, Global Checkusers, and other cross-project patrollers to provide ongoing support to small Wikipedias that are dealing with persistent but predictable vandalism in particular topic areas.

Cross-wiki related changes

Many high-traffic Wikipedia articles link heavily to Commons media, WikiData items, and related articles on other (often smaller and less consistently monitored) projects. Using a single high traffic article as an entrypoint, a motivated vandal can make extensive changes to the related content that could have a substantial negative impact on the article itself and/or the topic it covers, and those changes would be invisible to someone monitoring the source. Cross-wiki related changes feeds would help address this attack vector, in addition to other practical uses—e.g. alerting editors watching article A on English Wikipedia that the corresponding article on French Wikipedia has recently been substantially updated, and therefore there may be new information that should be included in the local article.

Central incident databases

Currently, there is no (structured, comprehensive) central log of incidents related to vandalism, such as Checkuser requests, user blocks, range blocks, suspected sockpuppets, known proxies, etc. A great deal of ad hoc data sharing happens between Global patrollers on private mailing lists, IRC channels, and wikis, but this is inefficient for real-time cross-wiki threat detection and remediation and doesn't allow for any sort of practical historical analysis of patterns of vandalism. Providing a mechanism for capturing and looking up metadata related to confirmed or suspected vandalism across different projects will make it easier for these editors to support all projects, and smaller projects in particular.

Social media inbound traffic reports

One established pattern of coordinated disinformation campaigns is the phenomenon of 'brigading', or organizing an intervention on one platform (e.g. Reddit, Discord, mailing lists) to impact a different platform. Furthermore, sites like YouTube and Facebook already follow a practice of inserting links to Wikipedia articles into controversial pieces of user-generated content in order to attempt to debunk disinformation—which has the unfortunate impact of directing the attention of bad actors to Wikipedia pages on controversial topics.

Wikimedia's non-public webrequest logs capture the domain-level source of all inbound traffic in near real-time. Surfacing the top N inbound links by recent clickthroughs from sites (like YouTube and Reddit) that frequently direct an influx of vandalism to Wikipedia—whether coordinated or uncoordinated—through real-time feeds or regularly-updated reports would help patrollers keep an eye on pages that are likely to be vandalized, and also help editors perform post-hoc review of pages that recently received a high volume of traffic from one of these sites. One interviewee mentioned that the top articles by edits database report was used in this way. Andrew West's popular pages report (also on English Wikipedia) is also used for this kind of monitoring, at least at a high level. Something like the Wikimedia Foundation's (no longer supported) Trending Edit service also has potential to assist in this kind of patrolling.

Research directions

Investigate potential zombie account behavior

As described above, I'm using the term zombie accounts to describe accounts that become active again after a long period of inactivity, and subsequently show a high level of editing activity and different patterns of editing behavior than previously. These are accounts that may have been hacked, and are no longer under the control of their original owner, and which (by virtue of their edit count, advanced age, or previously attained user rights) may fly under the radar of normal patrolling. The extent to which this attack vector is currently being exploited is not known, but deserves serious consideration.

Investigate patrolling on mobile microcontributions

New microcontribution workflows have been developed over the past year or so. Some of these workflows allow mobile-first or mobile-only editors to make contributions to Commons (image captions) and WikiData (article descriptions) without ever visiting those projects. These new workflows already yielded a substantial increase in the volume of contribution to those projects.^[2] Whether the projects have adapted their patrolling behaviors to account for this influx of new content is not known. Given that the content contributed through these workflows is surfaced to Wikipedia readers (and, presumably, search engines and other external structured data consumers), but difficult for Wikipedia editors to patrol, it is a potentially important attack vector for malicious actors interested in spreading disinformation.

Investigate extent of cross-wiki vandalism

Although the densely inter-linked nature of Wikimedia projects makes it easy for both registered and unregistered vandals to quickly hop from project to project (vandalizing as they go), the extent to which this is a common pattern among vandals has not been investigated. It should be possible to quantify the degree to which this phenomenon occurs, at least under certain circumstances—for example, reverted edits by the same IP address to different projects within a given, short period of time. The WikiAudit command-line application provides similar reporting functionality on a per-wiki basis (currently untested on non-English-language wikis). Developing a dataset of these incidents could facilitate the training of machine learning models that can identify potential cross-project vandals and direct patroller attention to the articles they have edited.

Investigate case studies of suspected disinformation campaigns

There have been many documented, intended, and suspected cases of attempts to insert disinformation into Wikipedia articles, often for political purposes or for profit. There is reason to believe that this kind of coordinated behavior would be more effective on smaller Wikipedias than large ones. However, there is substantially less research on the strategies used by malicious actors intent on disinformation on smaller Wikipedias than larger ones. Language barriers also present challenges to sharing details of these cases, as does the plain fact that there are substantially fewer potential research informants active on smaller projects. Ethnographic interviews and/or large-scale cross-project surveys could help identify the mechanisms by which these actors attempt to infiltrate projects (external platforms, communication channels, and attack vectors), as well as the type of content changes they make, and the projects and topics that are most vulnerable.

Investigate relationship between inbound social media pageview traffic and vandalism trends

When an article, or set of related articles, receive a great deal of traffic from social media sites like Facebook or YouTube (which use Wikipedia to fact check controversial UGC) or forums like Reddit (which has been used in the past to coordinate large-scale vandalism), and the article subsequently receives a high volume of edits from IPs or newly registered accounts, this may be a sign of coordinated vandalism. It may be possible to develop predictive models that can detect this type of activity using historical webrequest log and revision metadata. Models that don't rely on content-based features (e.g. the semantic content of words) to make predictions could be language-agnostic and applicable to most or all Wkipedias without the need to extensively train and tune the model on a per-wiki basis.

References

[1] ttps://www.nytimes.com/2019/05/30/business/north-face-wikipedia-leo-burnett.html

[2] ttps://github.com/wikimedia-research/Product-microcontributions-2019

[1]

[2]