The woes of sanitizing SVGs
muffin.ink
The woes of sanitizing SVGs
1–10 of 118 posts
Re: The woes of sanitizing SVGs
#2This is, by the way, why Google Slides doesn't have SVG support even though there's a nearly 15 year old ticket requesting the feature.
Re: The woes of sanitizing SVGs
#3[flagged]
Re: The woes of sanitizing SVGs
#4My first thought is "support a tiny subset of svg that probably still covers 90% of real-world use cases".
I do feel that's there's two distinct types of svg - "bunch of paths with fills" and "clever dangerous stuff" where most real SVGs are of the former type.
Fully expect this to be shot down by someone that's thought about this problem for longer than the 120 seconds I just spent. :)
Re: The woes of sanitizing SVGs
#5My first thought is "support a tiny subset of svg that probably still covers 90% of real-world use cases". I do feel that's there's two distinct types of svg - "bunch of paths with fills" and "clever dangerous stuff" where most real SVGs are of the former type. Fully expect this to be shot down by someone that's thought about this problem for longer than the 120 seconds I just spent. :)
Fwiw I just thought the same, parse (don’t validate) the bits you like and recreate / reject the input.
Re: The woes of sanitizing SVGs
#6My first thought is "support a tiny subset of svg that probably still covers 90% of real-world use cases". I do feel that's there's two distinct types of svg - "bunch of paths with fills" and "clever dangerous stuff" where most real SVGs are of the former type. Fully expect this to be shot down by someone that's thought about this problem for longer than the 120 seconds I just spent. :)
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’
Re: The woes of sanitizing SVGs
#7It seems the reason they're inlined in the page at all is to measure things briefly like bounding boxes (not sure the full extent as it didn't cover that), before subsequent removal. I'm not familiar with Scratch and its use of user-submitted SVGs but I'd be curious to read more about what they're doing that required it be inlined specifically.
(This isn't a comment on the challenges in proper sanitization fwiw, as I've needed to do various of the same things myself)
Re: The woes of sanitizing SVGs
#8Is there a browser-friendly vector alternative?
Re: The woes of sanitizing SVGs
#9This is, by the way, why Google Slides doesn't have SVG support even though there's a nearly 15 year old ticket requesting the feature.
Re: The woes of sanitizing SVGs
#10My first thought is "support a tiny subset of svg that probably still covers 90% of real-world use cases". I do feel that's there's two distinct types of svg - "bunch of paths with fills" and "clever dangerous stuff" where most real SVGs are of the former type. Fully expect this to be shot down by someone that's thought about this problem for longer than the 120 seconds I just spent. :)
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 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.