I am -1 on this change. I think the current setup works well and I don't think this adds anything to the ecosystem. I know @annevk disagrees, but that's where we're at.

In short I don't think adding this server-side configuration knob adds anything. We already have good signals on the client side and this just adds potential confusion and opportunity for conflict.

Given the arguments presented so far, we are not interested in implementing this in Chrome.

@domenic can you clarify

this just adds potential confusion

Is there a way to remove this confusion by changing something?

No, I think the existence of the goal parameter causes confusion compared to the existing mechanisms of selecting classic vs. module script, and as such we should not introduce it into browsers in any way. (I.e. we should treat it like any other unknown parameter.)

@domenic

Then, do you feel it is not desirable for a server to be able to guard its content to be restricted to one goal of JS? Which seems to be part of @allenwb 's review in bmeck/I-D#1

Right, I don't think that's necessary, or at least we haven't seen any developer demand for it yet.

If we made this goal parameter authoritative (and reject when it's wrong) browsers could more easily add optimizations throughout the loading pipeline as they no longer need out-of-band information as to what the type of the resource is.

That's reasonably compelling. Are there any implementers interested in using that signal?

Actually, it's not necessary to reject when it's wrong, since the browser can just de-opt if it turns out to be incorrect.

A hard fail seems like better developer ergonomics. And also better for users as the de-opt won't happen with deployed code and therefore user resources are not wasted.

Allowing code to be executed with the wrong goal sounds like a potential security risk.

For tests, we'll need:

• Goal parameter with empty value
• Goal parameter with weird casing for parameter name
• Goal parameter with weird casing for parameter value
• Goal parameter with whitespace around parameter value (e.g., =" module")
• Potentially also some MIME type tests, such as goal="\s\c\r\i\p\t", especially if we make these tests reusable in some way for Node.js

The language in the PR will also need to be cleaned up a bit, but would be good to hear from @whatwg/modules what they think about this first.

I tried to think through the security argument. It seems that if you only have text/javascript;goal=module scripts and you enforce that through a MIME type you can be positive they can only be executed on the same origin (or origins you opted into with CORS) the moment all clients relevant to you have implemented this change.

Another thing to test:

• Goal parameter specified on a non-JavaScript MIME type.

@annevk Put up a PR for tests. Is there anything else to do for now?

@bmeck great, thanks. At this point we need to wait for implementers and the folks from @whatwg/modules to weigh in.

Firefox supports making this change.

@travisleithead @Constellation?

@annevk to unblock this should I do anything? It has been over 1 month since I saw the comment that Firefox supports this, do I need to PR an implementation to them before this can be merged?

@bmeck per https://whatwg.org/working-mode we need two interested implementers. There's also a bunch of other changes that need to be made, but I was waiting for more folks to reply before doing a more thorough review.

Maybe @whatwg/security is more interested in this than @whatwg/modules?

To be clear the proposal here is to add a goal parameter to JavaScript MIME types so you can state your script is a classic or module script. If the parameter is present, the browser would enforce its value and refuse to interpret a module script loaded from <script src=modulescript> for instance.

Unfortunately this didn't go anywhere and it would be too late to add restrictions retroactively. And https://tools.ietf.org/html/draft-ietf-dispatch-javascript-mjs#section-6.1.1 doesn't seem to pursue this parameter anymore, so closing.