search

w3ctag / design-reviews

W3C specs and API reviews
Creative Commons Zero v1.0 Universal
322 stars 55 forks source link

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

Closed AdaRoseCannon closed 1 year ago

AdaRoseCannon commented 1 year ago

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.

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):

Thank you,

Ada Rose Cannon, Immersive Web co-chair.

AdaRoseCannon commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

have you considered restricting this to secure contexts?

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

plinss commented 1 year ago

And must all models be loaded from secure contexts?

cabanier commented 1 year ago

And must all models be loaded from secure contexts?

You mean, disallow mixed mode? Yes.

cynthia commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

annevk commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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: https://github.com/immersive-web/model-element/issues/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).