upvote
This is what happens when there isn't an adult in the room to reign things in, you get project overreach. SVGs should never have supported scripting. You want scripting in SVGs, fine, make it a different file format.

I can't imagine the cumulative number of man hours wasted on this problem when the vast majority of users were just looking for a way to make their logos look sharp.

reply
Or you can literally just manipulate your SVG through the DOM in an external JS script... I still have no idea what the original motivation behind scripts in SVGs was.
reply
While SVG is a web technology, for the longest time you had to install SVG support as a browser plug-in. I remember installing Adobe SVG viewer around 2000. It was used for interactive visualizations.

I'm don't remember precisely but I don't think you could script it from the DOM, I don't see how that could work if it's a plugin.

reply
I imagine it may have been attractive to those who liked Flash.
reply
I think it may have been the other way (ie attractive to those who didn't like flash) - SVG was seen as a potential flash replacement?
reply
OG actionscript was very similar to Javascript. It only started to diverge when type hints were introduced.
reply
AS2 was mostly following the direction of ES4 — so it wouldn’t have diverged if it hadn’t been abandoned.
reply
> SVGs should never have supported scripting.

I would even go further: HTML should never have supported scripting.

reply
... or third party requests. Scratch the H in HTML and internet tracking would have never happened.
reply
You could track people without links. You just couldn't go to other places without links.
reply
I think you're right but the lack of industry standard for this kind of thing kills it. People want to be able to take the output of whatever tool they use that exports SVG and put it in a browser. Which isn't an unfair request. But you wouldn't have a guarantee it wouldn't filter out the tool using some obscure SVG functionality.

I'd love to see an agreed standard like OpenGL vs OpenGL ES for SVG. SVG-ES. Everyone agrees on the static, non-scripted elements that should work.

reply
The way linked SVGs render from within img tags is basically perfect for SVG images (which as I understand is not standardized but is largely the same across browsers). External resources and scripting are blocked while still rendering nearly all SVGs correctly. And of course, any CSS is scoped to the SVG.

If someone formalizes this as a new format, please give it a new name! tvg tiny vector graphics? savg safe vector graphics?

And keep the scope as simple as possible so it actually ships! Don’t try implementing a binary format or something.

reply
Someone did this already and did call it tinyVG! https://tinyvg.tech/
reply
Maybe I'm missing something as I am not a frontend developer, but when you embed SVGs in an img tag as part of a Phoenix LiveView or even just a static component, you no longer get the ability to dynamically change paths/fills/colors with events coming from the server. Even if it's as simple as having a shape that you want to fill with a brand/highlight color, which at least for me is a common use case.
reply
deleted
reply
.rvg, Restricted Vector Graphics?
reply
deleted
reply
> My first thought is "support a tiny subset of svg that probably still covers 90% of real-world use cases".

It sounds like the linked post was about someone using a blacklist instead of a whitelist. It doesnt matter how tiny your subset is if you allow through stuff you don't recognize.

For the most part svg is safe. The dangerous parts are pretty obvious - script tag, image tag, feImage tag, attributes starting with on, embedding html in <foreignObject>, DTD tricks, namespace tricks, CSS that loads external stuff (keep in mind also presentational attributes. Its not just style attribute/tag).

The rest of it is pretty safe.

reply
W3C has been defining SVG Native, but it hasn't progressed much lately — mostly because there hasn't been any interest in it. SVG Native is a small subset of SVG 2.0 which doesn't support scripting, animations or any external references. https://svgwg.org/specs/svg-native/
reply
Seems like someone already implemented your idea. https://tinyvg.tech/
reply
Maybe we could use a subset of SVG or PDF?
reply
There's the SVG Tiny profile that some implementations use, like BIMI/VMCs.
reply
Fwiw I just thought the same, parse (don’t validate) the bits you like and recreate / reject the input.
reply
I would say that a proper sanitizer should remove any attribute that has /https?:/ in it. Maybe it should allow access to a subtree of a blessed domain you control, where stuff like textures is stored.
reply
I wonder if it would be best if this was at the browser level as some sort of new format. Otherwise surely it would be really slow/cumbersome to deal with these in ‘user space’
reply
This is what android does. It has its own vector asset format and android studio has an action for importing svgs.
reply
It always seems like any animated svg loses all of the animation after sanitizing
reply
A lot of SVG animation uses JS for some reason. It would be interesting to see if sanitisers strip CSS and SMIL animation, I don't see any security reasons to do so.
reply
There are 3 different methods of animating svgs so it probably depends.
reply
Yeah, I think that's the real answer.

Look at what Microsoft did with Excel--the dangerous stuff is behind a switch.

Thus, solution:

Add two bits to the tag.

SVG1 does not execute any sort of script.

SVG2 does not follow links.

SVG3 is actually SVG1 + SVG2 as these are bit flags, not numbers.

Additional bits are reserved for future use if any other issues are found.

The only real safety is in the engine, not by any sanitizer.

reply
Which is essentially already how it works. See https://svgwg.org/specs/integration/#secure-animated-mode
reply
What switch?
reply
You'd lose a lot of useful features, like SMIL animation.
reply
But you'd gain adoption. A fair trade.
reply
SVG Tiny PS (Portable Secure) is an attempt at this - https://www.ietf.org/archive/id/draft-svg-tiny-ps-abrotman-0...

Though I think it's still a draft, it does appear to be a requirement for BIMI - https://en.wikipedia.org/wiki/Brand_Indicators_for_Message_I...

reply
So if you are building something where you control every SVG ever produced and rendered then this is totally reasonable.

If you ever need to interface with other tools that generate SVG you now need to have a way of essentially transpiling SVG from the wild into your tamed SVGs. Oftentimes this is done by hand, by a software developer and designer (sometimes the same person).

And this is for basic functionality that your designers expect and have trivial controls for in their vector editors, like "add a drop shadow."

The article goes into some issues with sanitization itself, and except for <script> these are a bunch of reasonable things that someone might expect to work or not have issues with. Sandboxing rendering isn't an unreasonable approach if you're not writing the parser and renderer yourself.

reply