Re: [w3c/webcomponents] HTML, CSS, and JSON modules shouldn't solely rely on MIME type to change parsing behavior (#839)

> > What if someone was not even aware of CSP? Or someone had limitation on server configurations they can change? Again, most websites don't deploy CSP correctly
> 
> This is still something I say is kinda weak. Ideally new features should be developed in tandem with their available security policies which have strong defaults.
> 
> The fact CSP is misused is because of complexities with the policies. Things like hashes and stuff are difficult to set up and get right. I feel that this could be resolved by having stricter defaults (e.g. not allowing JSON modules by default) and safer configuration that doesn't encourage unsecure things.

What is the mechanism by which JSON modules will be allowed then? If CSP, that would contradict your earlier statement that "I think there may be some confusion, I'm only proposing `*.json application/json` be applied as an assertion, it does not actually change the type".

If CSP directives indeed affect whether JSON module is enabled or not, then my earlier observation that CSP directives affecting how the served content is parsed (or not parsed), meaning that depending on CSP directives you may have on a website, the content may start executing where you were not expecting to execute withstands, and is not an acceptable solution to the problem at hand.

> So if they're going to do this mapping automatically anyway why not allow them to configure it in the browser for their sites rather than adding pre-processing steps.
> 
> This is what my proposal does, it doesn't make browsers understand extensions. Instead it gives a way to make assertions about expected properties of resources (just content-type above but I think more is necessary for a concrete proposal) and means that people can be confident that content received is what is expected.

If your proposed mechanism to *make browsers understand extensions* is CSP, then that's not an acceptable solution as I have repeatedly stated.

In fact, any solution that involves out-of-bound definitions of types is unacceptable. The type of content that gets loaded by `import` statement must be defined in the same resource where `import` statement appears. This is precisely the core security issue we're trying to resolve here. We don't want anything but the very resource which has `import` statement to define how the fetched resource is processed, not in its header, not in some kind of site-wide configuration, or how in some other HTML / JS document which loads it.

That's a hard & absolute requirement for any solution to this problem.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/839#issuecomment-555367471