Distinguish Two Main SVG Types of Usage

[ghost]

Please: I hope this will be a simple suggestion that applies to all SVG specifications. As the developer of a web application that uses SVG to provide an interactive graphical UI, I am pulling my hair out because the notion that SVG is just about static images and "SVG files" is ubiquitous. This makes it hard to report errors, get support, or avoid paranoid fears of security (which I admit do relate to the naive use of SVG files as simple images), as the majority of people cannot grasp the difference.

It would help if there were two clear terms defined somewhere in the specs. to describe these broad scenarios. That is, (a) the use of SVG files to render an image, and (b) the use of inline svg tags, within an HTML document, to create graphical UIs.

Type (a) is referring to XML files containing SVG. Whether this also involves script/CSS could be considered a security risk as they are document files rather than simple image files. Type (b) will very likely involve script/CSS, as do the majority of HTML applications, and so should not be considered a risk in the same manner as (a).

Hopefully you can sympathize with the problem, even if you do not consider this to be the right solution. There could be more effort to promote SVG as a UI component rather than simply a tool for creating scalable static images. The technology is getting "bad press" that is often inappropriate.

[longsonr]

Don't we already do that here?

[ghost]

Hi Robert. That section is not addressing the same issue, and those categories would apply equally to the two scenarios that I mentioned. It's a big issue for me because of my "application" usage. I'm unclear as to how many other products fall into the same style of usage, but if you use Google for almost anything SVG-related then you'll be deluged by stuff about "SVG images" and "SVG files", thus pointing to a skew in its usage elsewhere.

Let me clarify my situation: my product (SVG-FTG) compiles a graphical application design (i.e. defined predominantly by using a mouse on a desktop screen) into a web application that involves HTML, inline SVG, CSS, and JavaScript. The inline SVG is used in the application UI, just as with HTML elements such as div, and so on. They have a common event mechanism and CSS styling, and so in this guise SVG is no less secure than the hosting HTML.

Unfortunately, some hosting sites ignore SVG completely, and when pressed they cite the security issues, but without being specific. As far as I'm aware, these issues relate to certain potential threats when an SVG file is naively accessed as an image file, thereby not appreciating that it is a document file rather than a normal image file (e.g. if an SVG file with malicious content is deployed as a CSS background image).

I can understand such sites being careful if you try to upload an SVG file as as image, but a significant number also disable inline SVG for no clear reason, other than possible ignorance.

Both of these scenarios (application UI versus separate file) can include the same range of SVG features, and so it's more about how that SVG is deployed. The issue is genuine but I'm open to other suggestions. It could be argued that it is one of education, but those ill-informed views seem entrenched, and it might even explain why this long-standing technology is nowhere near as accepted as HTML.

[tatarize]

There is clearly some ubiquity of using svg as a general vector file in a safe and consistent way. I use them for running a laser cutter but for security reasons, and simple practicality I would never permit scripts within them to run. However, the scripts are technically valid. If there were a firm line saying scripts in this particular svg are invalid and should not be run, one could check that a particular svg is flagged as having no references to external resources and no script execution or interactivity. If there were some methodology of quickly declaring that my particular svg is secure animated mode or static mode it might be entirely possible to declare that my use of SVG is limited and thus safe. If there was a flag for the svg object that, for example, would turn these options off or refuse to process the SVG at all if any non-strict element was found, one could even inline insecure svgs flagging their headers with the required mode and depending on the browser to prevent non-strict elements from executing.

[ghost]

I understand the reason for your comment, @tatarize but I think that's drifting away from my point. Irrespective of whether you allow/disallow/flag script/CSS inside SVG image files, there are valid uses of SVG that do not fall into this category, and where script/CSS are essential resources, but they are being penalised because of the naive view that "SVG is insecure".

In order to make this distinction clearer, I'm including a link to an example Web page that demonstrates the usage of SVG as a component of the UI: Timeline Example. This has two frames containing SVG content, but they are not "SVG image files"; they are cooperating parts of the UI that share their event handling and CSS along with traditional HTML elements.

[ghost]

I cannot be sure whether my point was appreciated or not because the only opinion given was actually unrelated. I have tried to explain the difference as best I can here, but I just want to add one more point, having just edited one of my answers on Quora after realising that all the other answers to the associated question equated SVG with "image file format" and "SVG files". Until you can break the ubiquitous association of SVG with image files then it will never be accepted as an equal contributor to Web UIs alongside HTML.

[ChiefMikeK]

XML resource images vs SVG

(－‸ლ) As a POSSIBLE work-around to your UI being rejected by hosts try and research on this Add a background image to shape in XML Android
This should work on a web page as well as in an android app?

:ship:

[ghost]

Sorry Mike, but this post has absolutely nothing to do with the subject that I raised.