Consider making srcdoc optional and blob the default

[weizman]

Just a thought, but from a security perspective, I find srcdoc to be inferior to using a blob from a security perspective, even though they stand up to the same level of expectations from a functionality perspective.

It's not critical, but assuming we'd like to limit the amount of trust we put in the realm of the embedder (which I believe we should), srcdoc naturally exposes the contents of the iframe to any other entity that lives within that realm.

Practically, say you embed mcp-ui in a page where there are more entities you can't fully trust (ads, 3p scripts, deps, etc). Naturally, the way the web is designed, any entity living within the embedding realm, has the same access as others to the DOM, and in the case of srcdoc, this translates to the capability of being able to tell the contents of the embedded iframe, because its contents are dynamically bound to the contents of the srcdoc property (meaning, state of srcdoc reflects state of inner realm at runtime):

<iframe sandbox="" id="xxx" srcdoc="<p>secret</p>"></iframe>
<script> alert(xxx.srcdoc.includes('secret')) // true </script>

However, using a Blob URL instead, would result in a similar functionality (blob iframe are same origin iframes by nature just like srcdoc), but won't expose to all the contents of the embedded realm to others (when used right):

<iframe sandbox="" id="xxx" src="blob:UUID"></iframe>
<script> // script can't access blob iframe contents </script>

By (a) forming the blob and a URL to it, (b) creating an iframe[src=blob] and then (c) revoking the URL of the blob, you get the same effect when using srcdoc, but in such a way where the contents of the iframe are not accessible from outside.

The only problem with this approach, is that CSP can be configured to forbid blobs, whereas srcdoc cannot be forbidden via CSP, which is why I would propose adding an optional prop such as "useSrcDoc[false]" which can be actively set to true by users who use a blob-blocking CSP.

But the bottom line is that srcdoc is generally inferior to blobs from a security stance and therefore should be dropped or at least become a must-opt-in feature.

This of course must take into account the sensitivity level of the contents mcp-ui introduces via srcdoc, as it may be low enough for this to not really matter

[weizman]

I see you closed your attempt, so I won't properly review it just yet, but from a quick glance I do want to remind it is important you revoke the URL object as soon as the iframe loads, because if it continues to be unrevoked, any entity within the realm can fetch it by obtaining the value of the iframe's src attribute and simply fetching it, making this method equally bad as srcdoc.

[liady]

@weizman good catch. PR here - #80