Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[svg-native] What should the file extension be? #664

Open
litherum opened this issue Apr 16, 2019 · 14 comments
Open

[svg-native] What should the file extension be? #664

litherum opened this issue Apr 16, 2019 · 14 comments

Comments

@litherum
Copy link
Contributor

Should the file extension be .svg? Or something more specific?

@AmeliaBR
Copy link
Contributor

#266 is related (request for a separate MIME type that behaves like other image types re security)

MIME types and file extensions don't have to go hand-in-hand, of course. Having a separate file extension would make it easier for server configuration. But it's less useful for compatibility, since existing software wouldn't recognize it as SVG.

@jarek-foksa
Copy link

jarek-foksa commented Apr 16, 2019

The initial draft was proposing .svn extension, which I find rather confusing since Subversion is still quite popular. If a custom extension is used, I would opt for something like .svgn or .nsvg.

@dirkschulze
Copy link
Contributor

I strongly suggest keeping .svg. SVG Native is 100% compatible to SVG and there is no need to exclude SVG Native from the dozens of SVG viewers that exist today and might not get updated anymore to be able to open the new file extension as well.

When it comes to the MIME type the same may apply but on the server side. It took years to get image/svg on the list of supported MIME types for Apache. SVG Native might not be in the situation where it gets added at all. Authors might use image/svg right from the beginning to avoid these problems.

I have a lot of scepticism about a new MIME type.

@svgeesus
Copy link
Contributor

I strongly suggest keeping .svg.

That has a strong downside. Existing servers will serve it as image/svg+xml, which means that browsers will render it differently (in the case of features not supported by SVG Native) compared to an SVG Native renderer. We don't want that (see #665)

@dirkschulze
Copy link
Contributor

@svgeesus We already agreed that a valid SVG Native documents will always look the same in a SVG Native viewer as in a full SVG renderer. If the document is not valid to the subset the behavior is unspecified anyway. Therefore, I don’t see a benefit of a new MIME type but rather the problem of SVG Native not being supported in many many years! Keep in mind that it doesn’t only take time to get the support into the source code of server software but significantly longer to servers directly.

@BigBadaboom
Copy link
Contributor

BigBadaboom commented Apr 18, 2019

I know the difficulty of getting a new mime type etc, but just one comment re this...

One of the use cases for this might be things like avatars for websites etc. Currently SVG is not typically allowed in these cases due to the perceived risk of SVG's scripting and interactivity. If there isn't a mime type to put in a file input accept attribute, those sites will probably continue to reject all SVG formats, even though SVG Native would be safe.

@dirkschulze
Copy link
Contributor

@BigBadaboom that is a good point. What holds you up to still add SVG features to that document? Or the renderer to be a full-SVG-renderer able to process this SVG file?

On the other hand, the MIME type maybe a way to enforce an SVG parser/renderer to go to a more strict mode if it would have one. It requires the whole industry to agree to fall back to the strict mode and not simply use the full-SVG parser to be effective though.

That said, SVG used in an <img> element in HTML, <image> in SVG or as CSS image already has a lot of requirements and restrictions that make it suitable to use the SVG as avatar on social platforms. The industry already agreed and implemented those restrictions specifically aiming the privacy and tracking concerns of social media platforms and the users and we still are not allowed to use SVG images. SVG Native is not adding more security IMO.

@dirkschulze
Copy link
Contributor

Another question, can we even keep .svg if we change the MIME type? IIRC all platforms allow to bind an extension to a MIME type. I don't think an extension is supposed to have more than one MIME type.

@jarek-foksa
Copy link

jarek-foksa commented Apr 19, 2019

Also, should there be an another extension for compressed SVG Native documents? If so, then the possible options could look like this:

New extension, new mime type

Extension Mime type Compression Format
.svg image/svg+xml No SVG
.svgz image/svg+xml Yes SVG
.svgn image/svgn No SVG Native
.svgnz image/svgn Yes SVG Native

New extension, old mime type

Extension Mime type Compression Format
.svg image/svg+xml No SVG
.svgz image/svg+xml Yes SVG
.svgn image/svg+xml No SVG Native
.svgnz image/svg+xml Yes SVG Native

Old extension, old mime type

Extension Mime type Compression Format
.svg image/svg+xml No SVG or SVG Native
.svgz image/svg+xml Yes SVG or SVG Native

@BigBadaboom
Copy link
Contributor

@dirkschulze

What holds you up to still add SVG features to that document?

I would assume those sites wouldn't just trust the user and browser. I imagine they would at least run an SVG Native linter over the upload.

@svgeesus
Copy link
Contributor

Another question, can we even keep .svg if we change the MIME type?

Realistically no (in theory we could, but most servers map file extensions to MIME types 1:1 so this would be a very bad idea in practice).

The use case of getting SVG in places (forum and wordpress image uploads, etc) where it is currently banned (because it has script execution, external references, and interactivity) is a significant one in my opinion. And that argues for a new MIME type.

@css-meeting-bot
Copy link
Member

The SVG Working Group just discussed SVG Native file extension.

The full IRC log of that discussion <AmeliaBR> Topic: SVG Native file extension
<AmeliaBR> Github: https://github.com//issues/664
<AmeliaBR> Chris: to me, file extension and MIME type are intrically connected. Most servers map extensions to media type. Different extensions same media type is do-able, but what's the point?
<AmeliaBR> ... Given that there are servers that restrict the use of SVG (e.g., image uploads from user) because of security requirements, so a new extension & type is useful.
<AmeliaBR> ... The media type is more important. File extension is just a representation of that.
<AmeliaBR> Dirk: The downside of a new type/extension is that existing tools would not be able to open by default.
<AmeliaBR> ... But, we are designing a format for the future.
<AmeliaBR> Myles: Implementations can be divided & some don't currently support all of SVG, anyway.
<AmeliaBR> ... Browsers should render it anyway regardless of Mime type, right?
<AmeliaBR> Chris: Maybe, but it depends. Browsers do some sniffing, but won't do anything.
<AmeliaBR> Dirk: Browsers may not be the main issue, since they're likely to be early adopters.
<AmeliaBR> Amelia: It may also depend on what the new type is. If it's still a valid XML type, browsers may be able to handle it anyway. But desktop software is going to look at the extension.
<AmeliaBR> ... Might need education for authors: you may need to save as a different extension. Servers may need to respond based on HTTP headers.
<AmeliaBR> Sairus: Also worth considering whether we want to create a limited set & then expand it in the future. Would that be a different type?
<AmeliaBR> Myles: If we end up creating too many different subsets, I think we then lose any benefit from having a defined subset at all.
<AmeliaBR> Sairus: So we really want this to be the defined scope & then stick with that.
<AmeliaBR> Dirk: Myles also mentioned the possibility of a distinction internally, e.g., a version attribute.
<AmeliaBR> Chris: This is something we've dealt with before, in XML and in SVG. version attribute and profile attribute. And the end result is that it always gets ignored.
<AmeliaBR> Myles: Does that mean that you think a stronger enforcement at Mime type level is necessary.
<AmeliaBR> Chris: I don't know. Just pointing out the difficulties. Need strong implementer support.
<AmeliaBR> Myles: One use case: for the OS, we might want to open a full SVG file in browser, a native SVG file in image preview. So we'd need a different file extension to do that.
<AmeliaBR> Dirk: Are we leaning towards a decision here?
<AmeliaBR> ... From Adobe's perspective, we'd like a clear distinction. We don't care whether it's internal (attribute) or external (extension / MIME type).
<AmeliaBR> Sairus: I think we need to think more carefully about all the use cases.
<AmeliaBR> Dirk: Ok, leave the issue open for now.
<AmeliaBR> Amelia: It would help to write out, in the issue, the use cases & pros/cons for each.
<AmeliaBR> Myles: I'm not sure whether my use case also applies to Windows.
<AmeliaBR> Amelia: Yes, file associations to software are keyed on extensions. So you'd need different extensions to associate them with different viewers.
<AmeliaBR> Sairus: BTW, I spoke recently with some of the Microsoft team. Trying to get them engaged in this project.
<AmeliaBR> Myles: Ok, I'll ping them in the GitHub thread & see if we can get some input.

@litherum
Copy link
Contributor Author

litherum commented Apr 30, 2019

If the extension/mimetype is the same as SVG, then this format will be treated as Web content and opened with the browser when you double click on it, but if it's distinct, it can be treated differently. One of the goals of SVG Native is to work outside of the Web content, as a native image format.

@MilesMSCohen Do you have any thoughts?

@mro
Copy link

mro commented Jun 5, 2021

No renderer may naively trust neither mime nor extension – it has to be either strict (=safe) or trusting.

That's the decision to the consumer. Not the producer. So declaring safe via mime or extension isn't a security gain anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants