Page MenuHomePhabricator

Adopt process (or migrations) to ensure tools and scripts acessing "external" resources not unduly impacted by CSP changes.
Open, Needs TriagePublic

Description

The CSP policy is now effectively live, and 2 scripts have already been listed as requiring migration.

Please adopt a formal process for allowing external websites to be whitelisted.

Event Timeline

This is not what we want, see T419234. @ShakespeareFan00 please close this ticket.

I am not closing this ticket, I am trying to work within what was 'deemed' a necessary tightening of the CSP, given recent incidents.

If you think the CSP changes are overly broad, then please add your reasoning so that other devs can evaluate what the objections (and possible mitigations are).

@ShakespeareFan00 I have, but on T419234. Probably a bad idea to duplicate my reasoning here.

@ShakespeareFan00, @Polygnotus

I'd suggest renaming this task to something like "Support user scripts accessing external data". the current title frames whitelisting as *the* solution, while the right approach is still being discussed.

ShakespeareFan00 renamed this task from Adopt process for whitelisting external (non WMF) sites that can be trusted. to Adopt process (or migrations) to ensure tools and scripts not unduly impacted by CSP changes..Mar 6 2026, 3:07 PM
ShakespeareFan00 renamed this task from Adopt process (or migrations) to ensure tools and scripts not unduly impacted by CSP changes. to Adopt process (or migrations) to ensure tools and scripts acessing "external" resources not unduly impacted by CSP changes..

This is not what we want

Who is we exactly / who do you represent in this statement?

I shared some broader thoughts on https://phabricator.wikimedia.org/T419234#11682841 - from that:

Both restrictions are temporary in that we expect them to keep changing over the near future, but they're also not things we plan to undo and revert to the prior status quo, which was a very high-risk state that people had nonetheless gotten used to living in.

Our goal with the CSP we deployed was to not disrupt legit existing user scripts, so we are going to be very attentive to allowlisting breakages like this.

We will allowlist publicai-proxy.alaexis.workers.dev, along with a couple other issues that have been reported. We hope to get that done today.

That said, we don't plan to create a formal process to allowlist new domains. Our goal right now is to allowlist domains used by existing user scripts, to avoid disruption. And that allowlist still allows for a lot of developer flexibility (and of course, some risk). We'll handle requests on a case-by-case basis, but a formal process would set expectations around this list continuing to grow in unexpected directions, that we do not think we can safely support.

@Aklapper Those who make and use scripts on Wikipedia that load external resources.

@EMill-WMF - Would you be willing to consider asking for community input on how to sensibly implement IIIF access, consistent with the revised CSP goals?

...and helping those script developers who now suddenly have a bunch of scripts that no longer work.

@Polygnotus: And you spoke to all of them, and represent their opinion? I have doubts.

I think it's quite likely that many scripts have been affected. I understand that Wikipedia:WikiShield (an anti-vandalism tool with 70 active users) also no longer works, @LuniZunie - please confirm

Yep, it broke multiple things, it's usable but I'm getting hundreds of errors in the console. Most of these things were media files I was querying from my website, so I've been moving those over to use raw.githubusercontent.com, but there are other things, such as sound-effects-media.bbcrewind.co.uk that I can't move over.

That said, we don't plan to create a formal process to allowlist new domains. Our goal right now is to allowlist domains used by existing user scripts, to avoid disruption. And that allowlist still allows for a lot of developer flexibility (and of course, some risk). We'll handle requests on a case-by-case basis, but a formal process would set expectations around this list continuing to grow in unexpected directions, that we do not think we can safely support.

Does that include https://tools-static.wmflabs.org/? Seems like a bit of a no-brainer since it's a WMF-controlled domain, and but I'm getting errors from my pageswap script when it tries to load https://tools-static.wmflabs.org/cdnjs/ajax/libs/select2/4.0.13/css/select2.min.css. Should I open a separate ticket for that?

Does that include https://tools-static.wmflabs.org/? Seems like a bit of a no-brainer since it's a WMF-controlled domain, and but I'm getting errors from my pageswap script when it tries to load https://tools-static.wmflabs.org/cdnjs/ajax/libs/select2/4.0.13/css/select2.min.css. Should I open a separate ticket for that?

Please file a task for that yes, because we have *.wmflabs.org on the allowlist already, so you should not be getting CSP errors for tools-static.wmflabs.org.