Support for HTML media type

[pichiste]

Hi there,

This adds support for individual HTML files as a media type, and is aimed at the use case of interactive artworks. Currently artists are using/hijacking the SVG component to embed interactive pieces. Having an HTML media type would simplify the process and make it clearer to the user. It's a close copy of the SVG component by @andrevenancio.

[andrevenancio]

Nice one I had this on my todo list. But needs @crzypatchwork to give it a green light. Because this is Pandora's box open 😂🙌🏻❤️

[pichiste]

Pandora's box indeed!

[andrevenancio]

Give me some time until Brazil wakes up and I'll ask if I can merge this. It seems a better option that SVG embeds.

[pichiste]

Thanks!! 🙏 I don't think there are any new security concerns, more just a usability thing really.

[mrdoob]

I was worried yesterday that people were able to embed other websites inside SVGs.
But I'm glad to see that removing allow-same-origin solved that.

Security-wise, I'm now more confident about supporting html 🤓

[mrdoob]

Also, I don't think this is too different from what SVGs foreignObject already allows the developer to do.
So I don't see it much as opening pandora's box but rather to stop abusing SVGs 😁

[spite]

Related: what do we want to do about permissions that require https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Policy (e.g. Camera, Orientation, XR)?

Edit: more concretely, i think that if those were allowed, they should probably be disabled on the main feed and only allowed in the objkt page.

[mrdoob]

@spite One step at a time? 😁

[spite]

@mrdoob of course. but i don't think ignoring the overall security is the right call if it can be considered at the same time. specially if one thing doesn't exclude the other. better to be safe than sorry

[mrdoob]

As far as I understand...
None of these features are allowed unless we add, say... allow="camera; fullscreen" to the iframe.

[nickdima]

Together with security we should consider also the immutability aspect. What if you call an external script in the HTML page that's later modified?
Even if hicetnunc will have some security measures in place, once these HTML NFTs are on the blockchain you never know how other websites/apps will handle them.

[pichiste]

@spite @mrdoob Yup it does block the features by default, so they'd have to be selectively enabled with allow. I guess it would just be a matter of pairing down the feature list to one that makes sense at some point?

My wishlist 😅

accelerometer
autoplay
camera
fullscreen
gyroscope
magnetometer
microphone
xr-spatial-tracking (!!!)

Would love to just see basic HTML working first though!

[mrdoob]

@nickdima The iframe only has sandbox="allow-scripts". It can't access external urls.

[nickdima]

@nickdima The iframe only has sandbox="allow-scripts". It can't access external urls.

Yeah what I was thinking is that the responsibility is given to whoever loads that HTML NFT and mistakes might be made. Imagine a new marketplace loads this NFTs and they "forget" to sandbox the iframe.

[pichiste]

@nickdima @mrdoob Hm just tested and it looks like sandbox can't prevent the iframe from requesting random web resources once scripts are enabled.

I'm not convinced that external resources should be prevented though... If someone opens the direct link, they are at the same risk as visiting any webpage, no?

If we really need it to be standalone, a few possible solutions:

• Injecting a Content Security meta tag upon upload, as suggested here.
• Wrapping the HTML file in an iframe upon upload, so you are already getting a sandboxed iframe.
• Upon upload, fetching all external resources and injecting them inline into the main doc.

These would happen on the frontend though so not sure how secure they really are...

With regard to this PR though, the SVG element works the same as this, so it's not introducing a new vulnerability.

[pichiste]

@nickdima The iframe only has sandbox="allow-scripts". It can't access external urls.

Yeah what I was thinking is that the responsibility is given to whoever loads that HTML NFT and mistakes might be made. Imagine a new marketplace loads this NFTs and they "forget" to sandbox the iframe.

Fair point!

[pichiste]

Testing this out, the CSP meta tag feels like the best solution. Simply injecting this into <head> upon upload:

<meta http-equiv="Content-Security-Policy" content="default-src 'self';">

Thoughts?

[mrdoob]

@pichiste Is it possible to remove the meta tag afterwards with JS? 😬

[mrdoob]

Is so... maybe double iframe would be the easiest/safest...

[pichiste]

@mrdoob Good call!

I just tested and it looks like fortunately the CSP policy takes effect on load, so it doesn't matter if it gets removed in the js.

Another thing about the double iframes is that things like the feature policy mentioned above would potentially need to be baked into the inner iframe, though maybe its safer in some ways?

[pichiste]

Ok, I've gone ahead and implemented the CSP meta tag solution. Basically these utility functions are used to inject the following meta tag into both the HTML preview and uploaded HTML file:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'unsafe-inline'; style-src 'unsafe-inline'">

I think that covers external sources concern.

Anything else?

[andrevenancio]

merged this to develop. but will not release just yet. need to double check with @crzypatchwork

[pichiste]

Awesome thanks!! I guess one last thing before releasing would be to make sure the author/creator query param name matches between the templates and vector/html iframe embeds.

Excited to see this live!