Talk:Product Safety and Integrity

Recent changes on our talk pages

List of abbreviations: D Wikidata edit N This edit created a new page (also see list of new pages) m This is a minor edit b This edit was performed by a bot (±123) The page size changed by this number of bytes 7 May 2026       19:49  Talk:Product Safety and Integrity/Anti-abuse signals/Suggested Investigations 2 changes hist 0 [~2026-27525-07; Clump]   m    19:49 (cur | prev) −172 Clump talk contribs (Reverted edits by ~2026-27525-07 (talk) to last version by Nux) Tag: Rollback        19:21 (cur | prev) +172 ~2026-27525-07 talk (→C x to reyruiuuryr: new section) Tags: Reverted Mobile edit Mobile web edit New topic       10:42  Talk:Trust and Safety Product/Temporary Accounts 6 changes hist +147 [T4NeGMp7P4en; Gabrielcarmonatellez; ~2026-27554-20 (2×); Clump (2×)]        10:42 (cur | prev) −286 Clump talk contribs (remove spam/vandalism)   m    10:41 (cur | prev) −1 Clump talk contribs (Reverted edits by Gabrielcarmonatellez (talk) to last version by T4NeGMp7P4en) Tag: Rollback        06:44 (cur | prev) +1 Gabrielcarmonatellez talk contribs (→(top): Añadi contenido) Tags: Reverted Mobile edit Mobile web edit Advanced mobile edit        06:12 (cur | prev) +147 T4NeGMp7P4en talk contribs (→Invalid serial number: Reply) Tag: Reply        05:21 (cur | prev) +143 ~2026-27554-20 talk Tags: Mobile edit Mobile web edit New topic        05:20 (cur | prev) +143 ~2026-27554-20 talk (→Invalid serial number: Reply) Tags: Mobile edit Mobile web edit Reply 5 May 2026       00:18  Talk:Trust and Safety Product/Temporary Accounts diffhist +168 ~2026-27119-57 talk (→Invalid serial number: Reply) Tag: Reply 4 May 2026  N    18:15  Talk:Product Safety and Integrity/Detecting abusive content diffhist +43 SGrabarczuk (WMF) talk contribs (Created page with "{{Talk:Product Safety and Integrity/Intro}}")

phab:H453 & phab:tag/CheckUser-SuggestedInvestigations

Same question as Talk:Trust and Safety Product/Archive § phab:tag/CheckUser-UserInfoCard, but this time regarding the SuggestedInvestigations Phab project :) [cc @KHarlan (WMF) as last time] Best, ‍—‍a smart kitten_[meow] 20:40, 25 August 2025 (UTC)

For some odd reason the project you linked claims:

Sub-project of CheckUser

… but it isn't. Presumably it was mis-created? Jdforrester (WMF) (talk) 15:28, 26 August 2025 (UTC)

@Jdforrester (WMF) I think it might be an "unofficial" sub-project; in that it's a sub-component of the CheckUser extension, but (from a Phabricator perspective) was created independently to phab:tag/CheckUser. I can't speak to how it was meant to be created, but personally I think it's fine how it is - Phabricator subprojects can be a bit of a pain in my (albeit limited) experience 🤷 ‍—‍a smart kitten_[meow] 17:54, 26 August 2025 (UTC)

I've updated https://phabricator.wikimedia.org/H453#2518, thanks for the ping @A smart kitten KHarlan (WMF) (talk) 11:37, 27 August 2025 (UTC)

Use of the #PM tag on the PSI workboard

Just FYI, some of the tasks on this workboard currently seem to use the #PM Phabricator tag in a way that doesn't appear to match its defined scope (i.e., for tasks that are purely project management oriented). I'm not immediately sure what the best solution to this might be, but I thought I should leave this message to let folks know :) Best, ‍—‍a smart kitten_[meow] 15:52, 11 October 2025 (UTC)

pinging a couple of PSI people because I don't know whether this talk page is monitored: KHarlan (WMF), OKryva-WMF. ‍—‍a smart kitten_[meow] 06:19, 20 October 2025 (UTC)

We do monitor this page, I just didn't really know how to respond. I think if a task seems to be mis-tagged with PM, then the best way would be to comment on the specific task. KHarlan (WMF) (talk) 15:39, 22 October 2025 (UTC)

@KHarlan (WMF) Ordinarily, I would raise something like this on the individual task(s); however, given that it seemed like this was the case for most/all of the tasks in question here, I thought that raising it in one (centralized) location might be better. AFAICS, it seems like the PSI workboard is currently using the #PM tag to mean (I assume) 'Product Manager', rather than what seems like its originally intended scope (project management). Apologies for the delayed reply! Best, ‍—‍a smart kitten_[meow] 13:56, 22 November 2025 (UTC)

CVE record descriptions feedback

As some feedback regarding the descriptions for Wikimedia-issued CVEs: in my opinion, in general, they could be improved. To use this recent CVE as an example:

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in The Wikimedia Foundation Mediawiki - ExternalGuidance allows Stored XSS.This issue affects Mediawiki - ExternalGuidance: from master before 1.39.

There are a few things that (IMO) could be improved with this description.

• The description doesn't specify anything about the XSS (other than it's a stored XSS). I'm not familiar with the usual level of detail that's included in CVE descriptions, but I feel like the description could potentially also state e.g. (a) that it's a system-message XSS (and maybe also what this implies -- e.g. that it can only be exploited by users who have the editinterface right), (b) what the vulnerable system message(s) were, & (c) maybe also the cause of the XSS (if known).
• The CVE description seems unclear on what the vulnerable & patched versions of the extension actually are:
  • The 'Top-level Version/Version Range' header under https://www.cve.org/CVERecord/UserGuide states that the format for the 'Product Status' can be "affected from <start version> <at, before, through> <end version>". However:
    • This CVE states that the affected versions of the extension are "from master before 1.39". This doesn't make sense to me -- "master" doesn't itself seem like a version of the extension; and in any event, the latest commit on the master branch would have come after MW 1.39, so (to me) "master" doesn't seem to make sense here as the 'start version'. This vulnerability also affects branches after REL1_39, so it doesn't seem like that should be the 'end version' here either.
    • I could be wrong here; but at a quick look, it seems like the vulnerable code may date back to the initial commit of the extension, which seems to predate MW 1.39 by some time. This makes it seem like the reference to 1.39 in this CVE is therefore not accurate. (REL1_39 may be the earliest branch of the extension that's being patched, but that isn't currently what the CVE description seems to be saying.)
  • While the CVE description does (purport to) say what the vulnerable versions of the extension are, it doesn't seem to say what the patched versions/commits of the extension are.
• The capitalisation of/spacing between words seems somewhat inconsistent. For me, this makes it a bit harder to read/mentally parse what's being said.
• The inclusion of the words "The Wikimedia Foundation" seem unnecessary - the extension is ExternalGuidance, not "The Wikimedia Foundation Mediawiki - ExternalGuidance" :p

With the disclaimer that I'm not familiar with what a typical CVE description looks like (and that I might have inadvertendly got some information wrong about the vuln here) -- from skim-reading the task & the patch, if I was writing this CVE description, I might have put something like (writing this off the top of my head):

A stored cross-site scripting (XSS) vulerability in the MediaWiki ExternalGuidance extension enabled users with the `editinterface` right to execute arbitrary JavaScript in some end-users' web browsers (without also needing the `editsitejs`/`editsitecss` rights), by overriding certain system messages which the ExternalGuidance extension inserted into the page as HTML. The vulnerable system messages were `externalguidance-machine-translation-heading` & `externalguidance-machine-translation-contribute`. This affects all versions of the ExternalGuidance extension prior to Git commits c7c51ca611 (master) / 22986d5fd1 (REL1_44) / c0a0d0e568 (REL1_43) / 3d6e2f673a (REL1_39).

Looking at an example CVE record from before the WMF became a CNA, it seems like - while not perfect - the information there is more clear & complete than in the records since the WMF started issuing its own CVEs.

Pinging @SBassett (WMF) because I don't know if this talk page is monitored, please pass this on if you're not the best person to receive this feedback! Let me know if I've worded this poorly and/or if there are any queries about anything I've said. Best, ‍—‍a smart kitten_[meow] 11:37, 21 October 2025 (UTC)

Thanks for the comment, @A smart kitten. Regarding the CVE descriptions, those are auto-generated from various inputs into the CVE vulnogram tool (the official tool Mitre provides CNAs to request and publish their own CVEs). The inputs include a short title (often just the Phab task title), the vulnerability's official CWE and CAPEC descriptions (as set via dropdown menus) and the versions we manually enter. I believe this is the encouraged best practice for Mitre CNAs as CVE descriptions should be discrete and standardized as much as possible. I would agree though that we should be more careful as an organization about versions and not include master/main going forward, as those aren't technically release branches. SBassett (WMF) (talk) 14:17, 21 October 2025 (UTC)

@SBassett (WMF) Thanks for the reply! Regarding the CVE descriptions, those are auto-generated from various inputs into the CVE vulnogram tool (the official tool Mitre provides CNAs to request and publish their own CVEs). Huh, okay. Thanks for the info. (Is this the Vulnogram tool? If so, maybe I'm missing something but from playing around with it a little, it seems like the description can be edited after being auto-generated from the provided values. I can't speak to how standardised Mitre say the descriptions should be - I'd defer to you on that - but then, to me, I guess my concern here might be with the comprehensibility & completeness of the CVE descriptions that Vulnogram auto-generates for MediaWiki/MW extensions. Looking at [1] & [2], if I'm interpreting them correctly, it seems like there might [hopefully] be some leeway given on exactly how the descriptions are phrased.)

(In case you're interested -- for fun, I filled in the Vulnogram form as I might've done it if I was the one recording this CVE [based on what I know about this specific XSS], & pasted the resulting JSON to phab:P84207.)

I would agree though that we should be more careful as an organization about versions and not include master/main going forward, as those aren't technically release branches. Thanks :) ‍—‍a smart kitten_[meow] 18:19, 21 October 2025 (UTC)

@A smart kitten - Yes, that's the tool, and yes the CVE description is a free text field. But I'd argue that, generally, we want to keep descriptions minimal and defined in terms of standards like CAPEC/CWE. If MediaWiki operators require more details, they can review the relevant Phab bugs (most of which should be public) and gerrit commits, as those contain far more information, but likely too much detail for most MediaWiki operators who just want their systems patched with the latest security updates. SBassett (WMF) (talk) 18:52, 21 October 2025 (UTC)

@SBassett (WMF) Fair enough, though IMO there may still be some room for the current free-text descriptions to be improved slightly in terms of understandability while still keeping them minimal. Either way, thanks for hearing me out on the feedback :) Best, ‍—‍a smart kitten_[meow] 19:02, 21 October 2025 (UTC)

Two-step verification for regular users? Really?

While I assume you have the best of intentions, I’d like to point out a rather serious issue with the new login requirement introduced here: two-step verification when signing in from an unknown device.

This new step only applies to users who have registered an email address — which, at least on the Swedish Wikipedia, has always been optional. The result is that some long-time editors with old, inactive email addresses — myself included — are now locked out of their accounts, even though they still remember their passwords.

To put it plainly, this is:

Illogical. Why apply it to non-admin accounts when anyone can edit Wikipedia anyway? What exactly are we “protecting” here? Checking the identity of someone who doesn’t need verified identity feels… unnecessary. And honestly, users could hardly be blamed for feeling like this turns Wikipedia into another Google — spying on them for no reason.

Illegal (in the EU!). When Wikipedia collects email addresses, it’s presented as an optional feature to help recover your account “if you forget your login details.” As of now the same data is being used for the opposite purpose: to deny access to users who remember their credentials. Under the EU GDPR, personal data may only be used for the specific purpose for which it was collected. Using it for something else violates Article 5(1)(b) — the “purpose limitation” principle. In short: if you collect my email to help me log in, you can’t later use it to lock me out. DHammarberg2 (talk) 20:48, 3 November 2025 (UTC)

@DHammarberg2: The reason this feature is implemented is for security purposes, which protect your account in case someone has stolen your password. If you're unable to log in to your account, you can contact the Trust and Safety team at ca@wikimedia.org to ask for their help. SCP-2000 (talk) 18:16, 13 November 2025 (UTC)

@SCP-2000: I suppose the next logical question is whether 2FA as described in the document applies only to the WMF ecosystem (and is optional for non-WMF wikis) or will be forced by MediaWiki core starting with 1.46 or whatever future version where this goes into effect. In the latter case, some wiki admins might want to consider other options for their wiki engine. Tactica (talk) 02:35, 19 November 2025 (UTC)