Disallow external JavaScripts at svwiki
Open, Stalled, LowPublic
Actions

Assigned To

None

Authored By

	Nirmos
	Jun 7 2020, 10:53 PM

Description

Hi, I'm one of the interface admins at svwiki. I'd like to have CSP enforced at svwiki, or at least prevent external scripts from running, if full on CSP enforcement is deemed too controversial or too early. I'm not 100% sure how CSP configuration works. Is it possible to enforce prevention of external scripts while keeping everything else report-only? If so, then that might be a good start if people feel like blocking non-script external resources does more harm than help.

At Swedish Wikipedia I have rewritten several gadgets (like Geonotice, Namespace-sensitiveEdittools and collapsibleTables) to not use javascript: URIs and onClick attributes, although I understand that that's not necessary yet. In October 2018 when the console warnings appeared I removed Wikiminiatlas as an available gadget and explained why on the village pump. No one complained about this, and I think this was the only gadget that broke the defined policies.

Event Timeline

Nirmos created this task.Jun 7 2020, 10:53 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 7 2020, 10:53 PM

Is it possible to enforce prevention of external scripts while keeping everything else report-only?

What do you mean by everything else?

In T254698#6200231, @Reedy wrote:

Is it possible to enforce prevention of external scripts while keeping everything else report-only?

What do you mean by everything else?

The other types of resources, like styles, images, frames, fonts, etc.

Krenair subscribed.Jun 7 2020, 11:51 PM

RhinosF1 subscribed.Jun 8 2020, 6:11 AM

MarcoAurelio moved this task from Backlog to Analysis / under discussion on the Wikimedia-Site-requests board.Jun 8 2020, 4:58 PM

i guess this needs secteam vetting

DannyS712 subscribed.Jun 22 2020, 2:28 PM

The Security-Team's position on this is that we'd like to wait a bit longer until we can develop a more cohesive and generalized means of deploying enforcing CSPs across a majority/all of the projects, largely to avoid the potential for 900+ separate CSP configs. If this particular issue is not an emergency, which it does not appear to be, then we'd prefer to wait. Also, it's important to note that CSP, while powerful and beneficial in many ways, isn't a foolproof security measure.

Urbanecm changed the task status from Open to Stalled.Aug 20 2020, 11:20 AM

Urbanecm triaged this task as Low priority.

Mstyles edited projects, added SecTeam-Processed; removed Security-Team.Oct 13 2021, 7:25 PM

@sbassett: Has some progress been made on a plan for CSP in the last two years that could be shared? (Asking as tasks shouldn't be stalled for good.)

NguoiDungKhongDinhDanh subscribed.Jul 2 2022, 6:28 PM

In T254698#8046020, @Aklapper wrote:

@sbassett: Has some progress been made on a plan for CSP in the last two years that could be shared? (Asking as tasks shouldn't be stalled for good.)

Sadly, this work has not been (re-)prioritized since @Bawolff's departure from the WMF. And we would very likely need to wait for a new director of security to be hired so as to re-evaluate this effort and help prioritize it. The main issue that I see is that there is a decent amount of existing work to wade through and understand exactly what is critical to getting enforcing CSP minimally supported within Wikimedia production. I would guess the biggest blocker is probably implementing user allow lists so that folks who heavily use userJS and gadgets wouldn't have their workflows immediately broken in several ways with no easy means of fixing them. I'd imagine that if we did allow certain projects to enable enforcing CSP right now, this and other issues could block many folks from even using various wikis with the workflows to which they've become accustomed.

Disallow external JavaScripts at svwikiOpen, Stalled, LowPublicActions

Description

Event Timeline

Disallow external JavaScripts at svwiki
Open, Stalled, LowPublic
Actions