ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

SVG Support in Media Library

December 18, 2018 · 14:22 · Daniel Hendricks
Description

Automattic's war on SVG is madness in an era of high DPR displays. It's not difficult to fix with the Safe SVG plugin (or with code, if you prefer), however, I feel like the ability to upload SVGs should be a stock feature.

Voters
+41 more
Tags
Difficulty: Hard
Request: Add feature
Discussion
Dominiq

Holy truth my friend! As for me it coul'd be also known as end of .png era! SVG always look better, Always if needed had to upload them manually and hardcode from link.

Peter B

I am not sure if that was a good idea. I mean SVGs are great i really like them, but the issue is that they are not images but structured data files with a plethora of possible security issues. So i only display such SVGs that i have built personally or inspected each and every letter of it. But never allow any user to upload their own SVG which i can not trust.

Daniel Hendricks

"ClassicPress is a modified and enhanced version of WordPress that serves the business website market."

  1. Name me a Fortune 500 web site that doesn't use SVG.
  2. I have thousands of SVGs that I have created. If you have a place that I can send them, I challenge you to find a security threat.

I rescind this petition.

Dominiq

@Peter B: If You don't want allow user to upload svg, make it by permission, i mean more like everybody puts own logo to theme, Often vector logo is converted to .png in this case instead of svg. If library don't support .svg You must replace header in child theme and hard code in template this .svg then it shows...

Dominiq

Also cutting logos to pixels for retina formats are work for dummies instead of one scallable vector graphic

Tim Kaye

@Daniel Hendricks: I am not sure you understand how these petitions work. They don't "belong" to the person that started them. Once created, they become a proposal that others, who are sufficiently interested, my comment upon. So you can't "rescind" a petition. Other people can continue to comment on this one and/or vote for it as they wish.

I don't understand why you would want to rescind it anyway. Surely you don't expect every proposal you make to be accepted unconditionally by everyone who comments. ClassicPress is committed to a transparent decision-making process. That means that people are free to disagree with one another just as much as they are free to agree with one another.

Daniel Hendricks

@Tim Kaye -

<blockquote>Once created, they become a proposal that others, who are sufficiently interested, my comment upon. So you can't "rescind" a petition.</blockquote>

I understand that. Everyone is free to continue to discuss the disadvantages of native SVG support. Perhaps I should have said that I am backing out of the debate rather than rescind. The value of vectors is not a debate in my mind. I understand that opinions vary.

<blockquote>I don't understand why you would want to rescind it anyway. Surely you don't expect every proposal you make to be accepted unconditionally by everyone who comments.</blockquote>

If the group doesn't like SVGs, that's fine (you certainly are not alone). However, asking for native support from folks who feel that PNG/JPG are good enough and don't see value in SVG is an exercise in futility. It's almost 2019, we have devices with ever-increasing resolution and there is a continued push for lean & accelerated mobile pages, but you are free to continue to solely use raster images.

Fortunately, rasters are already supported and Ma.tt agrees with you. It was worth a shot, the Safe SVG plugin (and others) continue to be very solid options, and of course, it's not difficult to link to unsupported file types outside of Media Library.

Tim Kaye

@Daniel Hendricks: I still don't think you get it. You write, for example:
>If the group doesn't like SVGs, that's fine (you certainly are not alone).

Who says "the group" doesn't like SVGs? On this thread, you have one commenter who has expressed disagreement with your suggestion, and one commenter who clearly agrees with you. You also have 11 votes for this petition, one of which is from me.

Like you, I use a ton of SVGs on my sites, and I make them all myself, so there is no danger involved. Like you, I think it's ridiculous that I have to install a plugin or write code to enable me to upload and use them. I do, however, recognize that Peter B has raised a legitimate concern. And the ClassicPress committee has already taken a vote that we will pursue a security-first approach. But it is possible to reconcile all this.

The security concern with SVGs is essentially that they may contain javascript, which could potentially be malicious. But so can ZIP files, and we already allow administrators to upload them routinely when they install themes and plugins (not to mention WP or ClassicPress itself).

So I would modify this petition so that SVGs are supported by default when uploaded by administrators (i.e. tie this to the manage_options capability). That way, there is no enhanced risk, while people like you and I can upload and use SVGs to our heart's content without the need for a plugin.

Daniel Hendricks

<blockquote>So I would modify this petition so that SVGs are supported by default when uploaded by administrators (i.e. tie this to the manage_options capability).</blockquote>

To further this and Dominiq's point, perhaps enabling/disabling this ability could be a <a href="https://petitions.classicpress.net/posts/136/new-settings-submenu-security">Security</a> setting (checkbox?), maybe with a possibility to allow by role and/or capability.

As far as the risk of JavaScript being included, perhaps part of the implementation could be to cleanse them on upload.

Point being, I feel like there are options, with no need to throw the baby out with the bathwater. As another example, there is always the risk that users may upload copyrighted images off of Getty or GIS, resulting in a very unpleasant letter from their attorneys. It shouldn't mean that all images should be banned entirely (?).

Tim Kaye

>To further this and Dominiq's point, perhaps enabling/disabling this ability could be a Security setting (checkbox?), maybe with a possibility to allow by role and/or capability.

That's one option. Others would be to provide a filter or use a constant on the wp-config.php file, so that the capability could be extended to other roles or users very explicitly and by someone who presumably knew what s/he was doing. I'm not sure which of these options would be best.

>As far as the risk of JavaScript being included, perhaps part of the implementation could be to cleanse them on upload.

I certainly wouldn't want that. Many of my SVGs have javascript included deliberately, and I wouldn't want that removed.

Daniel Hendricks

<blockquote>I certainly wouldn't want that. Many of my SVGs have javascript included deliberately, and I wouldn't want that removed.</blockquote>

But like everything else mentioned (including your note about constants), perhaps it could be an option just like ALLOW_UNFILTERED_UPLOADS provides.

Fabian Wolf

So, something like ALLOW_SVG_UPLOADS ..

Tim Kaye

Yes to both of those suggestions!

James Nylen

I'm voting for this petition because correctly implemented SVG support is something I'd really like to see, but in this case there are very good reasons why WordPress has not adopted SVG uploads. Required reading before doing anything here: https://core.trac.wordpress.org/ticket/24251

SVGs are not just images, they are full-blown XML applications, with all the capabilities and risks that implies.

> 1. Name me a Fortune 500 web site that doesn't use SVG.
> 2. I have thousands of SVGs that I have created. If you have a place that I can send them, I challenge you to find a security threat.

This is missing the point due to lack of understanding of the issues involved.

There are multiple ways that JavaScript can be embedded into SVG files, some of them unexpected and very difficult to sanitize. (See https://github.com/darylldoyle/svg-sanitizer and https://wordpress.org/plugins/safe-svg/ and https://github.com/Blobfolio/svgeez for some attempts at solving this problem, but any such code needs to be carefully reviewed by a security expert before it may be included).

Only Administrator level users can be allowed to upload unsanitized SVG files. Otherwise, an Author level user who can upload files can craft a malicious SVG with code that will allow them to compromise other Administrator accounts (upgrade their own privileges on the site).

Ok, once the security issues with uploading SVGs at all are solved... how do we display them on a page? There are a lot of trade-offs to be made here too, and you'll either end up with a solution that doesn't work for everyone, or an explosion of options, with all-new code that needs to be tested and refined.

For one example, copying the SVG markup directly into the page is the way that preserves the most benefits of using SVG (remember, it's an application/document format, not an image format, and this lets you use CSS and JavaScript to manipulate the image contents). However, this can increase page size significantly.

There are other trade-offs to consider too. Again I'm all for including SVG support, and all of this is solvable given infinite time and skill, but it is a deceptively hard change.

James Nylen

Also:

> Automattic's war on SVG is madness in an era of high DPR displays

I am not sure where this came from, Automattic makes extensive use of SVG files in almost all their products, and WordPress uses them in several places too.

In general it is a good idea to do a bit of research about an idea before jumping to conclusions like this. Chances are, if there is an idea that seems obvious like this, someone has already proposed it to WordPress, and the best thing to do to move the discussion forward is to look into that history.

Greg Schoppe

I think there is some crossover between this proposal and the proposal for WebP support, since inserting inline SVGs into posts, in my mind, would be a part of a comprehensive push for SVG support.

James Nylen

> I think there is some crossover between this proposal and the proposal for WebP support

Agreed, in particular the idea to convert image embeds into shortcodes would open up a lot of flexibility for handling more complicated formats.

Link: https://petitions.classicpress.net/posts/151/support-for-webp-format

Viktor Nagornyy

If shortcodes for images are implemented, they still must show images in the visual tab. Similar to how Youtube links are displayed/embedded in the visual editor.

Greg Schoppe

YouTube is done slightly differently, with the Embed API, but it would need an interface like we currently have with galleries.

SamBrishes

+1 SVGs a really important. A permission-controlled upload (which is per default just enabled / set for administrators) would be enough. The admin can decide form himself (and the security for his own website), who can upload SVGs and who cannot.

But, just for technically uninformed people, it would be great to show a second notification (explaining about the security risk) if he tries to enable this permission for Subscribers / Default Users. I guess this role should never receive this ability (I mean, on which website are you able to upload SVGs, except Graphic / Design pages), but everyone should make this decision themselves.

Jesse

This proposal, and the overly angry comments, and the amount of up votes, are another embarrassing thread for ClassicPress and betray the immaturity and lack of consideration that is involved in the project thus far...

If you all want ClassicPress to be blacklisted from every web host out there, go ahead with adding this foolish feature.

> I mean SVGs are great i really like them, but the issue is that they are not images but structured data files with a plethora of possible security issues

This.

> Only Administrator level users can be allowed to upload unsanitized SVG files.

Not good enough, a CMS Core needs guaranteed security.

A quick Google search reveals every major CMS blocks SVG uploads by default and they have to be manually allowed:

https://www.drupal.org/project/drupal/issues/3028868

https://github.com/joomla/joomla-cms/issues/18373

https://community.magento.com/t5/Magento-2-x-Technical-Issues/svg-file-uploads-result-in-disallowed-file-type-message/td-p/75552

James Nylen

>This proposal, and the overly angry comments, and the amount of up votes, are another embarrassing thread for ClassicPress and betray the immaturity and lack of consideration that is involved in the project thus far...

You seem to be taking the opinions of a few people here as the opinion of the project as a whole. This is not the case, and situations like this one have already been carefully considered and planned for.

https://www.classicpress.net/democracy/#democracy-conduct says "Be good to one another, take criticism well and follow the democratic process", but https://www.classicpress.net/democracy/#democracy-exceptions says "Decisions and actions required to address security issues" are exempt from the democratic process.

In this case, the decision and action is that this isn't getting in until/unless the security issues can be definitively solved.

> > Only Administrator level users can be allowed to upload unsanitized SVG files.
>
> Not good enough, a CMS Core needs guaranteed security.

This point is worth discussing further. What is the difference between unfiltered_html, which administrators already have, and the ability to upload SVGs?

Jesse

@James My apologies, I know I'm arriving late. Based on the strong comments, it seemed like a strongly worded response was appropriate since nobody cited references. It does seem like many features are being hurried based on the input of just a few people received during a rather narrow time frame.

The exception rule in Democracy would seem to be designed to improve security such as reacting to zero day vulnerabilities -- not for new features?

> This point is worth discussing further. What is the difference between unfiltered_html, which administrators already have, and the ability to upload SVGs?

Personally I believe unfiltered_html should be deprecated. Adding raw PHP snippets is already disallowed in WordPress Core, even with that filter enabled, but for some reason raw Javascript is allowed. And things like iframe or embed should either be allowed for all Authors+, or none of them it seems. For example, many companies hire writers, who can't figure out why their embeds keep being deleted because its not explained well anywhere. If a user's role gets changed and they happen to open a previous post and click Save, the iframe added by a privileged Editor could be deleted. And now that page editors (etc) are becoming mainstream, it only adds to the confusion. In Gutenberg, for example, I believe there is a "raw HTML" block which allowed absolutely any code.

Also there is already an unfiltered_uploads filter to allow any MIME types, which is disabled by default and can be specified by web hosts.

Ref: https://wordpress.stackexchange.com/questions/202463/what-do-unfiltered-html-and-unfiltered-upload-actually-filter

So considering future compatibility with page builders and yes, even Gutenberg for those users who want to install it with ClassicPress, I'd suggest maybe:

  1. deprecating unfiltered_html (mostly effects Classic Editor)

  2. allowing add-on page builders to decide re: raw HTML blocks, etc which forces a reduction in security to be a conscious choice, of sorts...

  3. retaining support for unfiltered_uploads or instead, consider a replacement filter where web hosts can define a list of allowed file extensions

This present more consistent logic: that the Core CMS is secure by default but an Admin-level user can choose to enable raw HTML snippets by installing add-on plugins like a page builder or even a Shortcode manager plugin. And by default, a strict list of allowed MIME types, but an Admin-level user can either enable unfiltered uploads or their web host can choose to do so. From a web hosting perspective, dangerous file types are a bigger concern than raw HTML because their firewalls like ModSec etc can still analyze the raw HTML if needed but if a malware Flash file gets uploaded it's a bigger concern, so this logic would empower sysadmins to retain a bit more control over MIME type security...