In T427721#11970258, @Aklapper wrote:

Not a Community Wishlist wish, thus removing project tag

I've been a bit BOLD and

This looks to be done, since W340 is marked as done.

Oh wait, I see it's already live without any community notification. This is disappointing.

@HFan-WMF Since this feature has already attracted community attention, please post about it on the wiki (via Tech News at the very least?) before it goes live. Thanks.

In T422438#11927576, @Amdrel wrote:

I was able to reproduce this with a local development setup of Mediawiki with UploadWizard installed.

The question that pops up in my mind is "do we have a situation where differentiating between AI vs LLM in software as a icon is useful?"

@Dreamy_Jazz I think an important question to ask is at what stage do y'all expect to trigger this? Do we want to prevent the file from reaching WMF servers at all? (in which case we should trigger it before the UploadStash step) Or do we want to just prevent on-wiki uploads? (i.e., trigger it at the last step). My personal vote (from a usability POV) is for the former since that is early in the workflow, and it is easier for somebody to restart the flow completely.

The latest update should have fixed this specific problem, but there are still issues surrounding the fact that it does not detect the URLs on the page

@It_is_a_wonderful_world Does this still happen?

In T412010#11899555, @dipanjan_sengupta wrote:

@Reputation22 off topic question
was setting up the project in local following the steps in https://gitlab.wikimedia.org/cloudvps-repos/videocuttool/VideoCutTool

was doing these step---> Get OAuth2.0 Credentials

getting this error"Error
Requests from your IP have been blocked, please see https://wikitech.wikimedia.org/wiki/Beta/Blocked for more information.

raised ticket ...will the issue be solved this way?

In T393436#11891991, @Jdlrobson-WMF wrote:

@Soda surveys need to be configured per project. I don't think a significant reader-facing disruption on non-Wikipedia/Wikisource wikis is waiting to happen. It would require someone to intentionally want to run a survey on Wikisource at which point issues would surface very quickly in their testing (which is a requirement of any backport).

Another use case for this is in {{sfn}}s, where we include a link to a different citation that also unceremoniously dumps the readers into the reference section. To mimic this behavior, in the same article:

• Click on a [2]
• Click on the link inside the reference (ReferenceTooltip will show the citation inline as a nested popup, Reference Previews will dump you into the references)

Like it or not, we still very much have an unblockables problem that communities refuse to solve (or at least solve at a very slow rate). This seems like a good mechanism to deal with it especially in the context of talk pages

@Jdlrobson-WMF Any idea who we should talk to get this task resolved? In its current state, this is a significant reader-facing disruption on non-Wikipedia/Wikisource wikis waiting to happen whenever the next QuickSurvey is sent out.

In T424846#11871854, @Soda wrote:

https://global-search.toolforge.org/?q=agufrom&namespaces=2%2C4%2C8&title=%28Gadgets-definition%7C.*%5C.%28js%7Ccss%7Cjson%29%29 SPIhelper maybe? I can throw a user agent at the multitude of Spihelper forks on enwiki if that would help

https://global-search.toolforge.org/?q=agufrom&namespaces=2%2C4%2C8&title=%28Gadgets-definition%7C.*%5C.%28js%7Ccss%7Cjson%29%29 SPIhelper maybe? I can throw a user agent at the multitude of Spihelper forks on enwiki if that would help

I will check!

User:GeneralNotability/mark-locked.js is the one that is popular with English Wikipedia administrators.

cc @Ladsgroup this might be something in your wheelhouse since I remember seeing you post about this on wikitech-l.

Notified the wiki at: https://test.wikipedia.org/wiki/Wikipedia:Village_pump#c-Sohom_Datta-20260421035400-Changes_to_electionadmin_userright

I'm in team "we shouldn't do this". The wikipage.content hook, to my understanding, was typically used for "this content loaded is either a preview or loaded user-gen content from a different page". PageTriage does not do any previewing for the most part and so would be abusing the hook itself (imo). If we really do need to signal to outside scripts, every time anything gets loaded we should ideally use a custom hook.

In T423962#11842201, @Bugreporter wrote:

See T290808: Users with no NDA can access confidential information at testwiki's SecurePoll instance (CVE-2021-46148). Before this is done we need a technical way to enforce the target user be in https://meta.wikimedia.org/wiki/Access_to_nonpublic_personal_data_policy/Noticeboard.

Just to document my findings:

• The election-admin group appears to have been added in T209892 back during when MediaWiki-extensions-SecurePoll was in much worse shape, in that context, removing any way to grant the right makes sense (over PII-exposure concerns)
• However, SecurePoll's code has come a long way since then, such that election-admin is given to admins without NDA access on enwiki. To my understanding, SecurePoll now only displays PII if a user has a group with securepoll-view-voter-pii. Editing and creating a poll should be fine for NDA users.
• The securepoll-create-poll userright in admin comes from this commit of 2014 vintage added without any associated phab task or local discussion.

In T197137#11834802, @Nux wrote:

Instead of adding more and more stuff CSP you should have focused on blocking whole categories of attacks. Like discuss removing wss with community and block it completely. Discuss removing eval and block it completely. That would add layers because that would block whole category of attacks. Current CSP is not that so it is mostly useless.

I can still reproduce the underlying problem of Openseadragon flickering, even in safemode. I haven't been able to reproduce the "Failed to initialize OpenSeadragon; no image found" message (also, that message typically means "ProofreadPage was not able to find any image associated with the current page and the frontend is running in circles"). I don't think either is due to the SRE incident (since moving the image around/triggering the OSD plane causes the image to pop back in, which would not have been possible if SRE hadn't sent the image in the first place).

In T197137#11824002, @Od1n wrote:

Indeed, there are the edits using the JS API, and most of what is discussed here doesn't guard against them, although it's the most straightforward way of worm propagation. Adding safeguard steps to web edits (i.e., the regular form) adds little to no security if we don't guard against the primary attack vector.

In T197137#11820797, @stjn wrote:

Status quo ante should just be returned given that this 'incident' is frankly the stupidest example of shooting yourself in a foot and then calling the cops on a random passerby. The fact that a month later @sbassett haven't at least personally improved the stop-gap solution, never mind personally apologised for forcing everyone to jump through hoops to edit sitewide JS, is a sign that there is something fundamentally rotten in how entire security team handled this 'incident' of their own making. And no one in the team clearly cares about the impact of their decisions.

In T422312#11797423, @Pine wrote:

In T422312#11788994, @Soda wrote:

This already occurs by proposing changes on talk pages in the context of larger wikis for interface administrator && asking for a 2O for the CU tool. I doubt we need extra mediawiki-side barriers for this kind of interaction.

Is there a technical limitation that would prevent someone from using the CU tool if they didn't have approval from a second CU? I believe that there is no such technical limitation, although probably WMF and/or the audit committee actively monitor for anomalous use of the CU tool. If they don't then I could address that in a second, and probably private, security ticket. Given potential sensitivity on how CU usage is monitored, please please don't discuss details of this in this public ticket, but I can follow up in private with WMF if needed.

(oh wait, y'all already figured this out, a few messages ago :)

@Novem_Linguae I got nerd-sniped onto this. The project is basically an off-the-shelf PHP 8.2 container that serves the website from the tool directory. The important directory for refill.toolforge.org is /data/project/refill/public_html/ng, which contains the compiled frontend. When you go to refill.toolforge.org, you're redirected to /data/project/refill/public_html/index.php, which then redirects to the ng/ directory, which then serves the frontend by loading /data/project/refill/public_html/ng/index.html. The rest, I think, can probably be safely ignored for the purposes of updating the frontend.

Noting that I've made the following changes to mark-locked now, which should mitigate the problem a fair bit by reducing the number of such calls to one per page load instead of N, where N is the number of users, and assign the request a unique user agent, which should bump it to a higher rate limit tier.

In T420280#11789145, @daniel wrote:

In T420280#11788465, @matmarex wrote:

@daniel That should not be needed for ForeignApi.js – if that request fails for any reason, then it just assumes that it needs to use a centralauthtoken.

But it counts against the anon rate limit, causing all API requests from the same IP to get blocked.

So, if you are a wiki power user and your are using a gadget that makes heavy use of cross-wiki requests, your requests won't get blocked - but API access for anyone sharing your IP address will be!

This already occurs by proposing changes on talk pages in the context of larger wikis for interface administrator && asking for a 2O for the CU tool. I doubt we need extra mediawiki-side barriers for this kind of interaction.

For context, I ended up hitting a 429 after just using an incognito tab to search for a string while idling on my main account for a fair bit of time.

In T421929#11780368, @Raymond_Ndibe wrote:

@Soda You can now see all your logs using --since to adjust how far in the past the logs should be gotten from. By default this is 1hr, which explains why you couldn't see anything.

The reason you noticed this when you did toolforge jobs logs crawljob -f and not prior (probably) was that we deployed a patch that enforces the 1h start time for streamed logs (-f). This was already the case for non streamed logs, but this patch enabled it for streamed logs (as well as other things).

The patch in question is to support --since and --until params. We likely need to do a better job of explaining what the defaults are, since that's not immediately clear.

@Reedy I would just drop that test as well, it is testing for the existence of the sanitizer, which is no longer needed because the CSS field does not do anything useful anymore

Not from my end. To my understanding the on-wiki stuff is either invalid or has been moved to sanitized-css subpages.

If it helps, crawljob is a celery container that health-checks URLs, I can invoke it from the web UI of the tool and it appears that the job works fine.

@UOzurumba, had a few folks complain that this broke workflows/caused confusion, despite being announced in tech news. I think adding a CTA like "Administrators should copy over indef block reasons to [[MediaWiki:Ipbreason-indef-dropdown]] as well" would have been good in this context. (I feel like the text was good at explaining the text, but maybe did a bit of a bad job explaining that there was an action that needed to be taken!)

Closing since the blocking task has been fixed!

This should be fixed and on all wikisources~!

Per comment above, task status should be invalid.

The tool is behind OAuth2 now; in theory, unintended requests should drop off a cliff. I'll keep monitoring :)

Copying this in from Discord, I figured out what the problem was. In my code, I was asking for "basic" rights from the server, but since I had an authonly grant, instead of granting me at least "authonly" permissions, it instead granted me a null scope, which caused a prod error when I tried to request anything with it. I've implemented a fix by asking specifically for the authonly scope in my initial request, but there is probably a fix here somewhere that needs to be made to the extension to show an error/a mismatch instead of going up in flames.

In T419903#11719778, @Samwalton9-WMF wrote:

In T419903#11719512, @Mvolz wrote:

I quickly had a look to see if we can find out where the extra traffic is coming from and it seems to be toolforge, specifically https://link-dispenser.toolforge.org/

Tagging @Soda - is this unusual level of activity or kind of of activity for your tool? (I.e. is this potentially abuse from a user? Or just normal activity?)

Regardless of the activity of the source, perhaps it would be a good idea for link-dispenser to have some internal list of known-good sources that it doesn't bother checking?

responsiveurls coming back empty in imageinfo doesn't seem related to this? As I mentioned in that ticket, the whole responsiveurls structure has vanished; this isn't "1.5" can't be found (which could be related to the thing that you mention) -- but rather the structure does not exist at all.

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ProofreadPage/+/1254981 does not solve the underlying issue here of the API shape being wrong. The response ProofreadPage gets back is:

{
    "batchcomplete": "",
    "query": {
        "pageids": [
            "-1"
        ],
        "pages": {
            "-1": {
                "ns": 6,
                "title": "File:Aus der Bai von Paranagu\u00e1.pdf",
                "missing": "",
                "known": "",
                "imagerepository": "shared",
                "imageinfo": [
                    {
                        "thumburl": "https://upload.wikimedia.org/wikipedia/commons/thumb/b/b5/Aus_der_Bai_von_Paranagu%C3%A1.pdf/page127-947px-Aus_der_Bai_von_Paranagu%C3%A1.pdf.jpg",
                        "thumbwidth": 1280,
                        "thumbheight": 1971,
                        "url": "https://upload.wikimedia.org/wikipedia/commons/b/b5/Aus_der_Bai_von_Paranagu%C3%A1.pdf",
                        "descriptionurl": "https://commons.wikimedia.org/wiki/File:Aus_der_Bai_von_Paranagu%C3%A1.pdf",
                        "descriptionshorturl": "https://commons.wikimedia.org/w/index.php?curid=68580012"
                    }
                ]
            }
        }
    }
}

In T418181#11724202, @Jdforrester-WMF wrote:

1.5x images are being dropped from reading mode srcSets as they're unused by browsers. It seems that PRP is re-using these in an unsupported fashion: https://gerrit.wikimedia.org/g/mediawiki/extensions/ProofreadPage/+/c99e956ec49636708757b006329d1116615899af/modules/page.editinsequence/OpenseadragonController.js

That would be T418181. It appears that "we" ProofreadPage is using the API correctly, but the imageinfo API is not responding with the correct structure for responsive URLs anymore?

More breakages got reported at https://discord.com/channels/221049808784326656/1024122449035526205/1483863001533649077 so no.

In T197137#11711102, @Novem_Linguae wrote:

In T197137#11682962, @Niepodkoloryzowany wrote:

In T197137#11680953, @stjn wrote:

There is zero reason why these 2FA checks can't happen pre-edit.

From what I see, some additional 2FA check has been implemented. Before editing a js gadget on RuWP, I had to confirm it's me. For the next hour or so, however, I had no 2FA checks before any edits.

Does anyone know if these re-auths are being applied to API edits? If not, then I am concerned that we are hardening the wrong thing. The March 2026 userscript incident used API editing, I think.

I think this kind of elevated security for browser editing will only protect against some very uncommon cases (little brother sneaking on to your laptop? Trojan horse remote controlling your mouse?)

@Prototyperspective Can you post a screenshot of how it looks in the default state for you ? For me there is a clear way to disable it using the appearance menu either below (or right above in the user tray).

In T418428#11665297, @Amire80 wrote:

In T418428#11665265, @Soda wrote:

the lack of people complaining about how to turn it off in Help desk, social media, or Teahouse, I feel like, is a strong indicator of the contrary to your characterization here. I agree that the UI could be clearer, but that is hardly a reason enough to override community consensus based on a small-scale experiment in this context (lacking any pushback from readers)

This kind of ignores all the people who expressed their dislike of it on Village pump (technical). I was not the first and the last of them; people keep adding negative comments about it on today, March 2. It's not "consensus".

The comparison to Vector 2022, which robertsky made in the Village pump (technical), is also not entirely valid, because that change affected all pages, and this one affects only several thousands.

In T418428#11664986, @Amire80 wrote:

In T418428#11663995, @Soda wrote:

Ideally, it shouldn't appear at all.

Please find consensus for this statement. Current consensus on English Wikipedia is contrary to what you claim and you have been told so. Thanks.

... And someone responded that the currently deployed version is not quite what the consensus was. The consensus was to have a "reasonably prominent button to disable it", and this is quite questionable. And User:S Marshall, who summarized the previous consensus, wrote in the later discussion: "I'd like to apologise wholeheartedly to the community for my role in this. :( I'm appalled."

So it's not exactly the consensus.

In T418428#11653077, @Amire80 wrote:

Now that I see that it's not on all pages, I guess it's not the most urgent thing.

But still, "Birthday mode (Baby Globe) / Disabled / Enabled", even if it's close to the animation and not deep in the sidebar, is very inconvenient. I find this animation extremely disturbing when I'm just trying to read an article. Other sites usually do it with an X button.

Copying over what I mentioned in my +2, TLDR, while the basic functionality is unbroken, there is still a fair bit of functionality that remains broken that will need fixing.

What are the "thumb steps" incantations exactly ?

cause/escalate edit wars.

More than this, there is a propensity to cause (to borrow a terminology used in the call, "a newbie biting machine") -- where multiple newbies get served the same erroneous suggestions, act on it, and then get reverted by increasingly irate experienced volunteers

Yep, no worries, just wanted to note something that I found confusing!

@LGoto Sorry for the confusion! In previous years, we've typically gotten a bit more leeway on the end time. It'll be nice to specify timezones or use zonestamp going forward (for what it's worth, I think it was technically 26th AoE when I submitted? :)

While I don't disagree with the direction, I'm a bit confused about the current patch being merged in its current :( Shouldn't we be i18n-ing that string ?

I can't see those tasks. I assume they're security-restricted :( A public/NDA-restricted calendar/tracking task of some kind would be nice tbh!

General feedback, can we/do we have a timetable of (upcoming) security fix deployment windows and supplemental releases on wikitech? I keep missing these and finding out about them through phab comments :(

Based on the conversation on the page, I'm going to say that there isn't sufficient consensus at this time to implement this change.

Based on a talk with folks on Mod-Tools last week, not gonna go forward with the patch unless there is community interest (since properly implementing CommunityConfigurations will require some amount of rethinking of the deletion module as well)