CORS Requirement for 3rd party sources in <model> tag

[AdaRoseCannon]

Wotcher TAG!

I'm requesting the TAG express an opinion on a dispute related to: Whether the model tag should require CORS for 3rd party sources.

• Name: Model Element
• Specification URL: spec url
• Explainer
• GitHub issue (if you prefer feedback filed there): [url]
• Primary contacts: AdaRoseCannon, marcoscaceres, cabanier
• The group where the work on this specification is: Immersive Web
• Relevant time constraints or deadlines: Not urgent

We recommend the explainer to be in Markdown.

Explanation of the issue that we'd like the TAG's opinion on:

Model is like a media element, other media elements like <img>, <video> and <audio> can play without CORS but there seems to be a pattern for newer APIs to require it like <script type="module"> vs <script>.

Links to the positions of each side in the dispute, this was amicably discussed at TPAC 2022

What steps have already been taken to come to an agreement: Discussion weighing security issues with benefits to users. Couldn't really settle on best answer and thought if the requiring CORS is the modern way of doing it then that that is what we should go with.

We'd prefer the TAG provide feedback as (please select one):

• leave a comment in the following GitHub issue: Require CORS for all <model>-initiated fetches immersive-web/model-element#56
• leave review feedback as a comment in this issue and @-notify [github usernames]
• open a new issue in our GitHub repo with the feedback

Thank you,

Ada Rose Cannon, Immersive Web co-chair.

[AdaRoseCannon]

In this case 'conflict' is a strong term it's more of a we aren't sure of the approach preferred in new Web APIs these days.

[torgo]

Hi @AdaRoseCannon can we expect a review request for the Model element itself? It would seem to make more sense to review this in that context or review both things together?

[torgo]

Our initial view is that CORS should probably be required. If we were adding img, video, audio to the platform today CORS would likely be required. Also: have you considered restricting this to secure contexts?

[cabanier]

Our initial view is that CORS should probably be required. If we were adding img, video, audio to the platform today CORS would likely be required. Also: have you considered restricting this to secure contexts?

What is the reason to require it?

[cabanier]

have you considered restricting this to secure contexts?

Yes, <model> should only work on secure contexts.

[plinss]

And must all models be loaded from secure contexts?

[cabanier]

And must all models be loaded from secure contexts?

You mean, disallow mixed mode? Yes.

[cynthia]

What is the reason to require it?

CORS is fundamental to the web's security model.

Having yet another special case for fetching content on the web would require re-inventing the security foundations that fetch already provides. On top of that, if one thinks about the long term maintainability - having yet another fetch-like feels like adding technical debt to the platform, especially given that the user benefits from what we can see aren't particularly strong.

[cabanier]

@cynthia please don't close an issue that is in mid-discussion especially with a non-answer.
Why is CORS needed since it requires process isolation?

[plinss]

@cabanier The issue was closed by consensus of the TAG.

The answer is that CORS is the de-facto default security mechanism of the web and there is string consensus among several groups (including the TAG) that all new mechanisms that fetch external resources should use it by default. If something new is going to be added to the platform and wants to opt-out of CORS, we feel the onus should be to justify that position.

[torgo]

@cabanier we discussed in the TAG call today and came to consensus to close as you were seeking TAG opinion in this issue. You're welcome to continue to discuss in your issue on the topic however from the TAG PoV we've closed this request. Minutes of our discussion are here.

[cabanier]

Thanks for clarifying your position.
It's strange that the TAG is ok throwing out such a fundamental part of the web.
This will add an additional burden and restrictions on authors that want to use the model element for no real reason.

Minutes of our discussion are here.

That discussion doesn't match with what the is trying to achieve. It also states that @annevk agreed that CORS was needed which isn't true.

[plinss]

Non-CORS resources aren't so much a 'fundamental part of the web' as legacy behavior that was implemented before all the security risks were fully understood. We unfortunately need to continue to support those to avoid breaking much of the existing content, but we'd deprecate them if we could. If we were to add image, video, audio, and script elements to the web today, we'd require CORS for those too.

[cabanier]

What is the security risk of not having CORS on the model element?

[annevk]

To be clear, while I said CORS strictly speaking wasn't needed, creating an exception does necessitate a bunch of work, including probably creating a new mode to fetch these resources as well as ensuring requests for these resources do not go beyond what we allow CORS fetches to do. And then accepting the ongoing maintenance cost of that. It's a lot simpler to stick with the CORS sandbox so I tend to agree with the TAG we should just do CORS here.

There might also be problems with service workers. To get the same kind of isolation as iframe has the server serving the model would also have to run the service worker, which strikes me as not the kind of thing a web developer would expect. They would expect 3D models to be similar to images or style sheets.

[cabanier]

And then accepting the ongoing maintenance cost of that

As @plinss mentioned, we have to do that anyway for legacy technologies like "image, video, audio, and script elements" .

There might also be problems with service workers. To get the same kind of isolation as iframe has the server serving the model would also have to run the service worker, which strikes me as not the kind of thing a web developer would expect.

It's the same isolation as <img> or <video>. Why would it be like <iframe>?

They would expect 3D models to be similar to images or style sheets.

Indeed. If the author wants access to the contents of the model, cors is needed. If it's rendered by the browser/compositor and no pixel access is allowed, cors is not needed. As you say, authors would expect 3D models to be similar to images.

[annevk]

As @plinss mentioned, we have to do that anyway for legacy technologies like "image, video, audio, and script elements" .

No, those are very different.

If it's the same as those you'd have to use CORS as otherwise attackers can get at the data way too easily.

[cabanier]

As @plinss mentioned, we have to do that anyway for legacy technologies like "image, video, audio, and script elements" .
No, those are very different.
If it's the same as those you'd have to use CORS as otherwise attackers can get at the data way too easily.

How are those very different?
if a model is not fetched with CORS, the site will not have access to its contents, just like images and video.
The site might get the model size or the length of the main animation but otherwise won't get more information (unless the model was fetched with CORS).

Sorry to be so stubborn but I would really like to know what this security risk is...

[annevk]

You are forgetting about Spectre. And (C)ORB. We went over this already in the other thread. (That's why I asked there if it was going to be iframe-like.)

[cabanier]

You are forgetting about Spectre. And (C)ORB.

Do those not apply to images and video? In a way, model should be safer (at least in vr) because it requires out of process rendering.

We went over this already in the other thread. (That's why I asked there if it was going to be iframe-like.)

Sorry, I must have missed that thread. Can you point me to it?
No, in my idea of <model> in non-cors mode, it's not going to be like an iframe. It will eventually be like svg in an image.

[plinss]

I also said:

If something new is going to be added to the platform and wants to opt-out of CORS, we feel the onus should be to justify that position.

I have yet to see any justification.

The TAG also has this guidance: https://w3ctag.github.io/design-principles/#leave-the-web-better. Just because something bad was done in the past, is not justification for repeating the same mistake. Should a future effort happen to deprecate non-CORS fetches, this would add an additional burden on that effort.

Let me also point out: immersive-web/model-element#58. The spec isn't yet fully baked and there is already discussion of exposing model data. If this should ship without CORS, and at any point in the future models are allowed to render into a canvas, then the canvas needs to be tainted, putting an additional burden on implementers and creating issues for authors.

Furthermore, this issue has been closed, and I have yet to see anything justifying re-opening it. Please either provide justification for the TAG to re-evaluate this decision, or accept the decision as-is.

If the Immersive Web WG wants to discuss ignoring the TAG's advice, please do so in your own repo (and be prepared for pushback).