Review different cross-domain import mechanisms and their security models

[tantek]

During #TC39 73 I’ve learned about ES Modules Attributes being proposed to address security concerns when importing JSON modules: ES Module Attributes. Filing this design issue for the TAG to more broadly consider various web-based cross-domain import mechanisms like HTML Modules (334), CSS Modules (405), and ES Modules. Specifically I request the TAG analyze and provide clarity on the exact security model or models and hopefully some degree of consistency and explicit architectural design across these mechanisms.

See the following related issues and efforts:

• webcomponents: HTML, CSS, and JSON modules shouldn't solely rely on MIME type to change parsing behavior #839
• Dynamic Import Host Adjustment presentation Dec 2019 (Explainer)

From a web author, developer, publisher perspective, a more consistent and understandable security model across these would help with easier understanding and better chance of conveying author intent. Thanks for your consideration!

(Originally published at: https://tantek.com/2019/339/b1/cross-domain-import-mechanisms-security)

[hober]

See also w3ctag/design-reviews#375 (JSON modules)

[kenchris]

Related: https://github.com/tc39/proposal-module-attributes

[hober]

@cynthia, do you think you could also take a look at this one?

[hober]

I request the TAG analyze and provide clarity on the exact security model or models and hopefully some degree of consistency and explicit architectural design across these mechanisms.

I think we should take this up as an issue on our Design Principles document, so I propose transferring this issue to that repo. Thoughts?

[plinss]

Yes, transfer to the design principles repo

[dbaron]

Yes, sounds good to me as well. This was briefly discussed in Breakout B today; minutes should be posted on Wednesday after the plenary.

[hober]

Transferring. I'll take the action to write a PR for this.

[dbaron]

Here are the minutes I mentioned from Breakout B on Monday.

[hober]

I think we should wait for the ES Module Attributes and JSON modules proposal to advance to Stage 3. At that point, we should do a design review of it, and evaluate if we need to add a principle here.

[hober]

I wrote:

I think we should wait for the ES Module Attributes and JSON modules proposal to advance to Stage 3.

It's Stage 3 now.

At that point, we should do a design review of it,

Done: w3ctag/design-reviews#535

and evaluate if we need to add a principle here.

Personally, I think this issue is well in hand and we don't need to add a principle here.

[cynthia]

@hober and I discussed this during the "Cork" "F2F.

Looking at the issue at hand, while this is indeed a pretty high-impact problem generally the principles is based on specific antipatterns we have seen in API designs. For this we only have one case, so it feels like this should be treated as a design review problem and see if there are any best practices to extract from the outcome of it, which could potentially be a future principle. But for the time being, it feels a bit preemptive to write a separate section at this point.

[hober]

Resolved to close this in the breakout 11/12 summary session today.