I would go with option C, that a new security model is required for handling executable code within pods.
Solid has already abandoned the single origin trust model completely by replacing CORS with an alternative authentication and authorisation system.
It’s JavaScript that is the issue, not HTML, and there are well established methods of sanitising HTML that can be applied both in read and write of HTML to eliminate untrusted code.
I would go further, that the vision of the read-write web now extends to JavaScript, and we need to provide a safe way to host executable code within a pod. There’s a long history of tackling this problem in other environments, including with executable permissions for files, opt-in trust of remote files, and sandboxing. You already note CSP too.
At the moment solidos in particular does nearly none of this (I think even IFrames are rather permissive), and historically that’s been fine because there’s not a huge number of apps, we trust them, and as far as I know none of them have written executable code to a pod yet.
We’re already started moving away from that with client IDs, which I understand will allow finer grained control over what data each app can access, and by extension what data executable code running on a pod might be able to access.
I’d read the examples provided as potential threats that don’t have mitigation yet.
It does look like blacklisting js and IFrames would prevent all of these?
Whitelisting specific features would likely be difficult (though not impossible), but probably a first step that can happen now already is informed consent - an app shouldn’t write executable code to a pod without explaining what capabilities it is using (and why?)