Wondering if that tool could be hosted on Wikimedia Cloud Services / Toolforge instead?

Unfortunately using WMCS/Toolforge won't work. WMCS policy 4.5 explicitly forbids using it to proxy traffic to other servers. Hosting it there would be a policy violation (DVRTed recently asked for permission and was denied).

And this isn't just one script that's affected. Several of my scripts no longer work, and I'm constantly testing new ones. Having to submit a whitelist request for every endpoint during developement isn't workable.

These changes to the CSP need to be reverted.

@Jdforrester-WMF That is not a workable solution for script developers. Waiting on whitelisting means that it would be no longer possible to have a good idea and test and iterate quickly.

In T419234#11681810, @Polygnotus wrote:

@Jdforrester-WMF That is not a workable solution for script developers. Waiting on whitelisting means that it would be no longer possible to have a good idea and test and iterate quickly.

I am not involved in this work, I'm just helping out by connecting this task that clearly needs a decision on whether or not, and if so how, third party domains can be accessed to the task that will make that decision.

@Jdforrester-WMF Do you happen to know who I should contact?

I think that hosting on toolforge could be a good medium-term solution as many other applications need to fetch website contents or access open-souece LLMs

Maybe 4.5 can be clarified to only exclude clearly unencyclopedic and malicious usage liek running "running Tor nodes, peer-to-peer network services"

4.5 Using WMCS as a network proxy

Do not use WMCS Projects to proxy or relay traffic for other servers. Examples of such activities include running Tor nodes, peer-to-peer network services, or VPNs to other networks. In other words, all network connections must originate from or terminate at WMCS.

https://wikitech.wikimedia.org/wiki/Wikitech:Cloud_Services_Terms_of_use#4.5_Using_WMCS_as_a_network_proxy

In T419234#11681825, @Polygnotus wrote:

@Jdforrester-WMF Do you happen to know who I should contact?

This is the correct venue for these kinds of requests. I'll check privately to make sure that the relevant teams respond.

Toolforge is not usable, that is a giant barrier to entry.

Improving the WMCS policy to allow proxying is not a good idea because it opens the WMF up to problems in case someone does something stupid. And this is again a giant barrier to entry.

This change to the CSP should just be reverted. It is a knee-jerk reaction to a PEBKAC problem.

For script developers neither is a workable solution.

@Polygnotus thanks for you comment. On the second though I think that you're right and toolforge is not a good solution.

I've been "advised" that the CSP changes were being considered in any event, the recent incident merely accelerated the timeline.

https://gerrit.wikimedia.org/g/operations/puppet/+/e14a8dba5cc577ffc528276adad9161944c83d1f Seems to suggest this is a temporary measure, if I am parsing it correctly. Is that true, and if so when will these changes be reverted? @sbassett

Seems to suggest this is a temporary measure, if I am parsing it correctly. Is that true, and if so when will these changes be reverted?

I don't believe we have a clear timeline on that, but in the interim, we do want to proactively support domains that are a part of critical user javascript workflows.

To describe the two mitigations we put in place yesterday, I'll share here what I just posted on the Meta talk page:

• Requiring re-authentication for changes to site-wide JS. Right now, that is a fairly clunky approach that requires a full re-login. We will devote development resources to streamline that.
• We disallowed many external domains from being connected to via CSP. But we also allowed many, so as not to disrupt current user activity, based on an analysis we had been doing around the use of existing user scripts. Prior to this change, all third-party domains were allowed.

We had actually planned to publicly discuss and roll out this CSP policy over the next couple weeks anyway -- which clearly would have been more ideal for both the community and WMF -- but we have published it now, and are monitoring for any reports of breakage that we should help fix.

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.

@EMill-WMF But that creates a giant barrier for user script developers. And this is only one userscript, quite a few of mine are broken. For example my AI proofreader scripts, my Apertus scripts, my AI editsummary script, my AI source verification script et cetera.

204.44.103.108 (my VPS)
Anthropic (Claude)
OpenAI (ChatGPT)
Google (Google Gemini)
PublicAI

And these are just a handful I can think of off the top of my head.

Feel free to open a ticket to describe what broke and how you were using it. But just to be clear, our goal isn't to allow infinite developer flexibility here in pulling dynamically from third-party hosts (and we're not going to allowlist IP addresses, for instance, which change hands even more fluidly than domain names).

There are real security considerations that will be balanced here, and we have been (and will be continuing to) devoting significant resources from our security and safety team to find ways to limit this risk while allowing as much developer flexibility as possible.

We are now supporting publicai-proxy.alaexis.workers.dev within the enforcing CSP, which hopefully unblocks this issue. (relevant config patch)

Thanks for the quick turnaround. I'm happy to confirm that the tool works now... partially. I forgot that I also made calls to Anthropic and OpenAI. Since @Polygnotus also mentioned them, I think it would be good to whitelist them too.

As I wrote in the parent task, this works as a short-term solution but we do need to find a true solution that doesn't introduce unnecessary friction for script developers

specifically api.anthropic.com and api.openai.com

And Anthropic (Claude) and PublicAI

api.publicai.co (see the documentation here https://platform.publicai.co/docs)

@sbassett , could you whitelist the Anthropic, OpenAI and PublicAI endpoints? There are more scripts that stooped working, see https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_AI_Tools#c-Phlsph7-20260308103900-AI_scripts_not_working_anymore_following_CSP_changes

Hello everyone, some of my user scripts are among the victims to the recent CSP changes. Are there concrete security concerns that stand in the way of whitelisting the official Anthropic, OpenAI and PublicAI endpoints?

In T419234#11685400, @Alaexis wrote:

@sbassett , could you whitelist the Anthropic, OpenAI and PublicAI endpoints? There are more scripts that stooped working, see https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_AI_Tools#c-Phlsph7-20260308103900-AI_scripts_not_working_anymore_following_CSP_changes

Yes, we should be able to open these (and other affected domains) up via the new enforcing CSP sometime tomorrow.

In T419234#11685443, @Phlsph7 wrote:

Hello everyone, some of my user scripts are among the victims to the recent CSP changes. Are there concrete security concerns that stand in the way of whitelisting the official Anthropic, OpenAI and PublicAI endpoints?

Would you be able to file a separate bug for under this task hierarchy related to any domains that are being blocked within your user javascript? Thanks.

In T419234#11685443, @Phlsph7 wrote:

Hello everyone, some of my user scripts are among the victims to the recent CSP changes. Are there concrete security concerns that stand in the way of whitelisting the official Anthropic, OpenAI and PublicAI endpoints?

Would you be able to file a separate bug for under this task hierarchy related to any domains that are being blocked within your user javascript? Thanks.

My scripts use the OpenAI endpoint ("https://api.openai.com/v1/chat/completions"), so whitelisting the endpoints should also fix my scripts. I'll check if your planned changes solve the problem. If they don't, I'll file a separate bug.

Change #1249348 had a related patch set uploaded (by SBassett; author: SBassett):

[operations/puppet@production] Allow-list some additional domains to the currently enforcing CSP

https://gerrit.wikimedia.org/r/1249348

This also affects loading user scripts from any localhost port. That is a key point for anyone trying to develop a user script in any reasonable manner.

This is especially true if someone, for example, works most efficiently on something like Neovim (me).

In T419234#11689035, @IPOfAFlower wrote:

This also affects loading user scripts from any localhost port. That is a key point for anyone trying to develop a user script in any reasonable manner.

Are you talking about ports for publicai-proxy.alaexis.workers.dev or for localhost? The latter should now be fixed via T419197.

Change #1249348 merged by Scott French:

[operations/puppet@production] Allow-list some additional domains to the currently enforcing CSP

https://gerrit.wikimedia.org/r/1249348

Hey all -

• api.anthropic.com
• api.openai.com
• api.publicai.co

should now be allowed within Wikimedia project CSP.

Thanks!

In T419234#11690294, @sbassett wrote:

Hey all -

• api.anthropic.com
• api.openai.com
• api.publicai.co

should now be allowed within Wikimedia project CSP.

Thanks for the changes. They also solve the problems with my scripts.