Confluence does not retain/use uploaded SVG images

[Ԍｕｙ]

When inserting an SVG image into a Confluence page, the SVG preview and view in the editor look OK. However, on a subsequent *reload* of the page, the image comes out garbled. It seems like Confluence is replacing the SVG (crisp and small vector graphics) with a JPEG image (pixelated, compression artifacts in scaling, larger in size).

I suppose the image converter used does not know how to handle fonts correctly (in this case `font-family="sans-serif"`), and replaces text glyphs with boxes/squares (see image).

PS: The handling of Markdown syntax in Atlassian product sucks. It is highly inconsistent!

[Owen Wallis]

Hi everyone,

Thanks for your patience with this.

I’m the PM on the Media team. The fact that SVGs render text as squares has not been great.

I’m please to say we’ve started rolling out an initial fix.

As some of you have noticed we are rendering SVGs as image files.

This is as some SVG files can contain script tags, so are vulnerable to XSS cross site scripting.

Our security team has helped us look into some libraries which parse the files and strip dangerous code. But unfortunately they don’t meet our standards, and would put your instances at risk. I appreciate its unlikely one of your team members would try and take advantage of this risk vector, but it’s just not something our security team are happy with.

So, we need to keep rendering SVGs as image files.

What we’ve therefore done is added font support for Arial, Times and Courier. So essentially a serif, sans serif and mono font which all fonts should fall back to.

I’m really sorry but this is a forwards only fix. So SVG files previously uploaded will not benefit from this fix.

I’d like to keep this ticket open as it may be there are some unicode characters we’ve missed out.

So do let me know if there are any other font sets which would be useful and we’ll do our best to incorporate them.

All the best

Owen

[Ԍｕｙ]

Thanks @Owen Wallis for the much appreciated input.

In that sense, it would be appreciated if the fonts used were not Arial, Times (New Roman) and Courier (New), but rather fonts maybe from the Noto [0] bundle (they have a much wider coverage of Unicode glyphs). The licence should be suitable for your purpose.

Additionally, if SVGs will have to be rendered as pixel images, I'd appreciate it if they were done so in PNG format (not the lossy JPEG format with compression artifacts), as that will be much more suitable for the use case (these are not family snap shots).

Thanks in advance,

Guy

[0] https://en.wikipedia.org/wiki/Noto_fonts
(licensed under the SIL Open Font License)

[Owen Wallis]

Great feedback thank you. We'll take a look at Noto.

Agreed that SVGs are not family snap shots! PNG is more suitable so we'll take a look into that too.

Thanks

Owen

[Aleksandr Krymskiy]

@Owen Wallis Thank you very much for the explanation. I have a question: if the issue with keeping SVG without converting them to a flat-image format are script tags, wouldn't it be just simpler - not accepting SVGs that contain script-tags, etc. or stripping them immediately from the SVG XML upon upload?

Thanks,
Alex

[Owen Wallis]

Hi @Aleksandr Krymskiy

Thanks for the comment. Yes I did ask the same question to the team. The issue is any malformed script tags (which we would assume a hacker would try and use) would result in us failing to parse, i.e.

<   script
name =">" > </script>

If we just parsed for the word 'script' then genuine SVGs that had this word (i.e. please students read this script) would be penalised.

Also unfortunately <script> is not enough, you can have onclick, onthis, as handlers in the SVG elements.

Overall security were not comfortable with the risk this entailed.

[Ԍｕｙ]

That kind of issue sounds like there's a regular expression parser (rather than an XML/tag parser) in place, if it's that easily fooled.

For the kind of price tag one forks out on Atlassian stuff, I'd expect better ...

Things could be so much better if they were just done right.

[konstantin_petukhov]

@Owen Wallis You have a parser and renderer to convert the svg image to the raster. Why you cant cleanup the svg? You could at least render svg to svg instead of a bitmap thus getting rid of any scripts.

[Benjamin McCord]

I really feel like this should not be a difficult hurdle.  But I could be wrong.  Also, it is worth noting that according to mozilla's documentation if the svg is embedded as an <img> then scripting is disabled.  Of course, if a user opened the image directly this would still be an issue.  And its not clear if this applies to other browsers.  My approach would probably be to parse the SVG file and rebuild a filtered version.  I would use an actual DOM parser to do this.

[Influential Eliot]

Agreed with @Benjamin McCord on this.

All Jira applications should allow this, and if what Benjamin says is correct, then just allow admins to allow SVGs.

If there is still a concern, the put the onus on the owners. So do the following:

1. Provide an option to enable it (things like this should always be 'opt in' only) in general admin settings
2. Enforcibly remove anything in <script> tags
3. Attempt a couple of efficient measures to remove any badly formatted script entries
4. An option to either warn or disallow any SVG with the word 'script' anywhere in the code

Etc

If you have concerns about storing them on Jira cloud resources, then put safeguards around that and either ringfence them, or even say that if admins *do* enable the feature that they must provide an online store for them. Perhaps make a simple way to hook this up to SharePoint and Google Cloud, but don't make it onerous, y'know?

[Shannon S]

Hello Guy,

I've had a look into this, and it appears you are running into the following bug:

• CONFCLOUD-66798 Adding text to SVGs renders as rectangles on a second edit
  

I found an internal ticket linked to this one, and it looks like we've been able to replicate it on our end. 

There appears to not be a workaround for this, as Atlassian Cloud does not fully support SVG at this time. There may be an SVG add-on that could help you with this, or I would recommend using another format until the issue is resolved.

I understand this is not ideal, and I am hoping we can see a resolution to this in the near future.

Regarding the handling of markdown syntax, would you be able to raise a separate question regarding this? It's possible to insert Markdown using a macro. If it's not working for you, we'll need some specifics about what Markdown you were using, and where. By sharing this as another question, we can go more in-depth about it.

Thank you, and take care!

Shannon

[Aleksandr Krymskiy]

I am having the same issue after uploading SVGs generated from Visio. Can you add some sort of flag/setting preventing the "mangling" of SVG? I want to be able to provide a resizable diagram for the viewer, and there is no alternative format that is able to do this. I am unclear about the "Atlassian Cloud does not fully support SVG" - it does not need to support it - it just needs to not mess with it as recent web browsers are able to display SVG natively.

I am not able to see linked CONFCLOUD-66798 - would be curious to see more detail about the bug.

Thanks,
Alex

[Ԍｕｙ]

So, it clearly looks like Atlassian needs/should do something about it. Either by disallowing the use of SVGs up front, or by just not messing with them (converting them to a pretty stupid format for usually line drawings (JPEG) in the first place). Can it be so difficult? It's done all over the place, and especially for Confluence this would be quite useful. Especially for a product one must pay so much money for every month, and that has long recorded issues.

I also think that add-ons are not the right solution for something that should actually work straight out of the box already. Especially as most add-ons require (A) additional subscription fees and (B) make the situation even more messy with even more unrelated (3rd party) domains resources are pulled from. What a nightmare from a security and privacy perspective, also causing additional issues with 3rd party T&Cs as well as jurisdictions (for those that may e.g. have to deal with GDPR and such).