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

> > 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".
> 
> It is allowed if it passes the policy, the type is still entirely determined by the `Content-Type` header.

Again, this is precisely what's insecure about the currently proposed model of HTML, CSS, & JSON modules. We can't rely on `Content-Type` to decide the processing mode.

> Note that is is true that it changes **if it is parsed** but it does **not change how** it is parsed.

Ugh... disputing about what words mean what is the least productive we do in our industry. I can get academic and start using random jargons in ECMA or HTML standards but that's not gonna help anyone so let's not do that.

> The entry point determines what to do with the resource, the `Content-Type` distinguishes how to process that resource for that particular goal. It's just a case that things like `<link rel="stylesheet">` only support one type (in this case `text/css`).

This in turn is only partially true, and that's why we had to make things like [CORB](https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md).

> `import` only tells us to load it as a "module" it doesn't specify the type of module to load. The security implications are important to consider but this is a matter of ensuring resources are what you expect them to be (and people expect `.json` to be `text/json`) so instead of enforcing at every site why not enforce universal expectations (universal within a site at least) universally?

Because that's worse security surface. Now, eacb script deployed on a script must rely on some universal rules that may or may not change in the future to enforce such a policy. The author of each importer script has no way of enforcing what kind of module will be loaded.

> > That's a hard & absolute requirement for any solution to this problem.
> 
> But you're defining the problem to be that developers need to have the parse type at import-site. That's circular, the problem isn't that, it's that we don't want upgrade from JSON->Javascript unexpectedly, the solution of placing the declaration at every call site is just one way of doing so.

?? I'm saying that the importer must define what kind of module it's importing. There is nothing circular about it.

-- 
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-555390754