It's probably worth testing SVG client-side rendering as an opt-in beta feature, to get wider testing as we improve the authoring tools to help with optimizing rendering or blacklisting problematic files.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T44725 Multimedia file format support (tracking) | |||
| Open | None | T138665 Support SVG interactivity and animation in media-viewer | |||
| Open | None | T5593 [Epic] SVG client side rendering | |||
| Open | None | T208578 SVG client side rendering for specific SVGs | |||
| Stalled | None | T134482 Beta feature for opt-in client side SVG rendering | |||
| Declined | None | T134455 Add experimental option for direct SVG output via srcset | |||
| In Progress | ssingh | T117618 Add restrictive CSP to upload.wikimedia.org | |||
| Open | None | T239065 Have final CSP policy for upload.wikimedia.org be in report-only mode for all projects | |||
| Open | None | T239066 Engage with users about enforced CSP policy on upload.wikimedia.org | |||
| Open | None | T239068 Set CSP to enforce across all of upload.wikimedia.org | |||
| Resolved | Bawolff | T239069 Give MW a .htaccess in the images directory to mirror Wikimedia's CSP settings |
Event Timeline
Comment Actions
This is currently stalled on WMF having reservations about adding CSP headers to file responses as they would add significantly to the byte count of traffic.. See T117618#10081491 and later.
Comment Actions
I don't really think CSP should stall this. CSP only affects direct views. If we're talking about rendering an SVG via an <img> tag, CSP doesn't change anything. Additionally, we already allow template styles to set an svg file as a background-image so setting via <img> wouldn't really be a change in security posture.
To be clear CSP is a very good idea to improve Wikimedia's security posture, but it would improve the status quo. It wouldn't affect <img> tags.