pub.dev API reference should support embedded base64 encoded image in data: url

[espresso3389]

I understand there's a discussion about images on API reference (such as #502).

My understanding is that we should upload the image to somewhere and document should embed the URL for it.

But if we do that, VS Code extension does not show the image on popup (it's another problem)

Video.mp4

So, my workaround for this is embedding the image using ![image](data:image/svg+xml;base64,....

https://github.com/espresso3389/pdfrx/blob/master/packages/pdfrx_engine/lib/src/pdfrx_api.dart#L416

As you can see it shown in the VS Code like this:

Only the problem is that it is not shown on pub.dev's API reference:

So, it would be better if pub.dev should have support for such embedded images.

[espresso3389]

Related: Dart-Code/Dart-Code#5609

[sigurdm]

We should probably support this.

@isoos do you know at which point the data url gets filtered out?

[isoos]

do you know at which point the data url gets filtered out?

I haven't checked what dartdoc does, but pub-dev has an _UnsafeUrlFilter in markdown.dart which removes this as (1) it has a scheme (data:) but it is not considered "trusted" (http, https, mailto). I think we should consider supporting it if otherwise we don't see any known attack vector using the data: url in images.

[sigurdm]

Good point, we should probably do some research on the possible security implications.

I think that we could allow data: urls for images without too much issues. I don't know if our html-sanitizer allows to distinguish between allowed schemes for images and for other links.

Some related discussion here: mganss/HtmlSanitizer#187 not sure how conclusive that is.

[isoos]

Some related discussion here: mganss/HtmlSanitizer#187 not sure how conclusive that is.

They only link/mention issues in older browsers (and that comment is already old enough from 2019).
Gemini thinks it is safe to use data: urls now: https://g.co/gemini/share/a983d86a5d90

[sigurdm]

Yeah - I agree, it sounds like we should just allow them.

[isoos]

I have implemented parts of it in pub-dev (dart-lang/pub-dev#8880), but it would also need a similar update in package:sanitize_html.

However, the more I think about it, the less I like the idea. The linked issue's link mentions that "[VSCode] intentionally don't support inline svgs due to the extra attack surface they introduce. You can use svg images but these will not be interactive."

I can take educated guesses here, but without really understanding why it is a security risk to include such images in VSCode, maybe it is better to not support data: URLs with them either. It would also make the future image proxying harder, and it makes the page sizes too large both in the source and then in the generated documentation.

There was also a push for allowing video content inside <img> URLs, which could make the situation with data: URLs much worse: whatwg/html#7141

[espresso3389]

However, the more I think about it, the less I like the idea. The linked issue's link mentions that "[VSCode] intentionally don't support inline svgs due to the extra attack surface they introduce. You can use svg images but these will not be interactive."

The reason background the decision is that SVG file can contain JavaScript codes and it "might" be able to access some of VSCode things. VSCode have so many extensions and they could not count all of the possibilities caused by combinations of SVG files and extensions.

For pub.dev, I don't know how serious the riks is. But the attack surface is apparently smaller than VSCode.

So SVG may not be allowed. But normal images should be acceptable I think. (except the size issue)

[isoos]

For pub.dev, I don't know how serious the riks is.

Note: pub.dev cannot allow any unvetted third-party Javascript, as it may be an attack vector in impersonation.

And in this specific case, I think it is a considerable risk:

• We have a Content-Security-Policy that allows script being executed from pub.dev (self), however, we don't allow embedded scripts (unsafe-inline is not in the allowed items), so it could be exempted.
• However, while I couldn't find a direct source, Gemini said "A script within an SVG file, when loaded in a browser, will be treated as coming from the same origin as the embedding HTML page, not as an inline script". Which implicates that we would be at risk.

We could try to single out SVG files and put them on a deny-list, because they can contain script content, but that wouldn't really help for @espresso3389 either, and if another image format also has the capability, we would be late to put it on the deny list.

With that, I think the safest route us not allowing any data: URL for the time being.

[sigurdm]

According to https://stackoverflow.com/a/73156416/4809566 svgs inside img tags do not support embedded scripting.

[sigurdm]

https://news.ycombinator.com/item?id=39080265 has more details. Scripts might not be the only concern. Also linked data from the svg. We should indeed be careful in what we allow here.