In T420833#12242859, @LucasWerkmeister wrote:

I imagine plenty of people have noticed, but what are they supposed to do about it? (Other than try to get the LLM bubble to pop already, I suppose.)

In T420833#12241167, @Hakimi97 wrote:

have been using LLM to identify security vulnerabilities

In T420833#12240963, @LucasWerkmeister wrote:

Also, for the HTTP basic auth idea, see T420833#12082393.

In T420833#12240092, @Novem_Linguae wrote:

It's probably harder than it looks to solve this due to wanting to keep beta cluster pretty similar to prod, and due to bots being able to disguise themselves so well.

In T40946#12213170, @Amire80 wrote:

If anyone can give me sample SVGs that use Hebrew text, I can test.

here's another edit not propagating to PCS (but this time without a page move)

I'm not sure I understand exactly what results you're trying to get. maybe https://en.wikipedia.org/w/index.php?search=%22Student+newspapers%22+%22reliable%22+-intitle%3A%2F%5EArticles%2F&title=Special%3ASearch&profile=advanced&fulltext=1&ns4=1

confirmed with 50586-beta-2026-05-12

the hardware in last paragraph should work with Debian:
https://www.asus.com/uk/accessories/streaming-kits/video-capture-streaming/tuf-gaming-capture-box-cu4k30/

In T425197#11882011, @SomeRandomDeveloper wrote:

it changes the protocol to PROTO_CURRENT before redirecting, but maybe PROTO_CURRENT is http for some reason?

In T425114#11880200, @matmarex wrote:

It looks to me like your university's machines are configured to reject cookies for en.wikipedia.org for some reason. You might have to raise this problem with their IT admins. Perhaps we could handle it more gracefully in MediaWiki, but the root of the problem seems to lie on the browser's side.

In T422559#11796709, @taavi wrote:

Seems like mx-in*.wikimedia.org do not like these emails for whatever reason

see also T393124: Use full month name in date

retargeted the link to bypass redirect so this is less visible to readers now. https://en.wikipedia.org/wiki/special:diff/1343912188

this is still cached/reproducible 20+ hours after page move. I even did locally in OS settings clear data for the app, didn't help.

cc @Dbrant

https://wikitech.wikimedia.org/wiki/Incidents/2025-02-28_www.wikipedia.org_redirect

see also previous XSS was fixed: https://github.com/StarCitizenTools/mediawiki-extensions-ShortDescription/commit/bc4fdbaeb1dff127fb6d08c0d385b64aa128c8f8

unclear to me why this was filed publicly? the github link is embargoed I guess, 404 for me.

In T413376#11639023, @Gopavasanth wrote:

Could you please share any reference or guidance on how to properly fetch the latest deployment details?

In T413376#11639020, @Gopavasanth wrote:

@bd808 fixed it! https://github.com/indictechcom/TranslateTagger/pull/23/changes Good to go?

fetching github from client JS isn't permitted and anyway it doesn't make sense.

In T415237#11612824, @Wargo wrote:

Most important may be the button to export pad to MediaWiki, even with some history attributions.

In T415237#11606312, @doctaxon wrote:

We have Commons. Isn't it a gigantic database too?

maybe of interest I stumbled on this also tonight.

In T415237#11604318, @Volans wrote:

I've looked at it and having a solution that will slowly go over the existing pads older than X and delete [optionally archiving too] them is very easy and will take a day or two to implement.

your NY times links are all Unable to load URL. for cbc I get a response sourced from wayback instead of zotero and VE is broken with We couldn't make a citation for you. Try another source or create one manually.

It's like the results if I ran the queries 3 or 4 days ago. Is the database not been updated since 1/14/26?

In T81605#11530397, @cmooney wrote:

As a further test I wiped my cache, started a packet capture and did a dig for 'en.wikimedia.org'.

originally added in T354679: Add dumps mirror for data1.usrdm1.scatter.red

In T198138#11436334, @Physikerwelt wrote:

I still don't understand what would be the best way to clone a git repo from within an potentially unsecure labs instance.

new key, same problem. f95b48c236e08bf8f7a9e482e4382aec0b9f1bd7

In P71784#287826, @jeremyb wrote:

looks like there 6 removals not replaced with something approximately the same.

if they only include those with at least 1% of responses for a block and they're always adding new data then maybe something dropped below 1%.

In P71784#287826, @jeremyb wrote:

looks like there 6 removals not replaced with something approximately the same.

if they only include those with at least 1% of responses for a block and they're always adding new data then maybe something dropped below 1%.

looks like there 6 removals not replaced with something approximately the same.

https://www.nytimes.com/interactive/2023/upshot/extremely-detailed-nyc-neighborhood-map.html

@awight @Jdforrester-WMF is this still stalled? where is the best place to track how much is done and what's still needed?

looks good to me. I saw no banner there and then added Wikitech to an active campaign and then removed Wikitech from campaign and was still seeing it and then didn't see it and then deleted impressiondiet from session data locally in my browser and then saw it again (not in allocation but still within the 10 minute caching period) then waited for 10 minutes to expire and deleted impressiondata again and then it really doesn't appear. then did another test to see what shows in allocation, turned same campaign on for Wikitech and showed up immediately in allocation and then removed Wikitech from campaign and disappeared immediately from allocation.

Looks like this is set at https://gerrit.wikimedia.org/g/mediawiki/extensions/UploadWizard/+/d0572ccc8f27d024d012f5a94051ef6eebe9c1d6/UploadWizard.config.php#568

found T376509 while investigating 429 for https://upload.wikimedia.org/wikipedia/commons/thumb/7/74/Feedback_form_Odia_Wikipedia_outreach.pdf/page1-180px-Feedback_form_Odia_Wikipedia_outreach.pdf.jpg

sure, of course, I just thought we were trying to unify without that? (or else docs were confusing)

@Kitabc12345 also I'm wondering if there's been any local discussion about https://en.wikipedia.org/wiki/Banner_blindness ? (no article on this topic in zh yet)

In T375253#10163560, @Kitabc12345 wrote:

privacy concerns with relevant APIs

is this UBN? high for now.

copying over comment from other task:

put this on hold for now. Will come back if I have a more solid plan for how I would use it regularly.

this is moot now, event is in less than 2 days, closing. I'll write something up soon in case someone wants to reuse my methods.

I found this form. didn't try it yet. https://toolsadmin.wikimedia.org/profile/settings/change_password/

@Ejegg is there any possibility of a compromise where the default preview does this but if a user needs to share with community members they can add a query string param that makes clear that they really for sure understand what they're not allowed to include for privacy policy? &confirmedPrivacyPolicyFollowed=1 not a huge deal for me right now since I learned why it's there but maybe other CN admins (or me in the future) need to share more with ordinary users.

I believe https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/Edit/Wikicurious_beat_talkpg_en is ready to ship. wgCategories only, talk page only, no array or regex, wrapped in a https://en.wikipedia.org/wiki/Immediately_invoked_function_expression

There's some low hanging fruit I found to move some to regex. see counts at P68997. that's just from removing /\b\d+(nd|rd|th)?\b/ from titles. aka numbers.