Clarify cross-origin resources

[alanwaketan]

When the spec refers cross-origin resources, are we talking about response or request origin?
For example, in resource_timing_cross_origin_redirect_chain.html, the resource loaded in frameContext was requested from a cross-origin site but then the respond is from the same-origin site. Should we treat the resource as cross-origin or same-origin? The test itself suggests the former. However, I didn't see any spec language defining this.

[annevk]

To define this properly requires integration with Fetch. Basically once a response (including a redirect) is not same origin with respect to the request's origin, the request's origin is tainted. When that happens each response (including that response) needs to have the opt-in header, otherwise the eventual response is considered cross-origin.

[alanwaketan]

Thanks Anne for clarification. Let's say if multiple redirects happen, what origins are required in TAO? Also do we need TAO for each intermediate response?

Let's say:
A.com -> B.com -> C.com

1. C.com has TAO B.com, B.com has TAO A.com, is this the only case that goes through?
2. Or as long as C.com has TAO A.com, it will go through?

[alanwaketan]

May I ask why resource_TAO_cross_origin_redirect_chain.html would pass? The last redirect doesn't have TAO. Can you clarify where the TAO needs to be present in the chain?

[annevk]

If multiple redirects happen, the origin gets tainted and will be send out as "null". C should see "null" and reply accordingly. It shouldn't see B.com. And yes, each response in the chain needs to have TAO, unless there are some same-origin responses and it hasn't gone cross-origin yet.

(The tests may well be incorrect.)

[alanwaketan]

Thanks Anne for the clarification and sorry for late response.

I would like to give examples to see if I fully understand everything. Let's say we have a main frame in A.com, and some redirections happen within its child frame. How could the main frame get accesses to the child frame's timing information in each example?

Example 1.
B.com (TAO) => A.com (TAO) => A.com (TAO)
Yes.

Example 2.
B.com (TAO) => A.com (TAO) => A.com
No.

Example 3.
A.com => A.com => B.com (TAO) => A.com (TAO)
Yes.

Example 4.
B.com => C.com (TAO)
No.

Example 5.
B.com => A.com
No.

[annevk]

Those look correct to me.

[toddreifsteck]

@yoavweiss Why does this require Fetch integration? This seems to be a critical privacy issue. Can't this be monkey texted in? Pulling to L2 for consideration.

[yoavweiss]

Similarly to #152 (comment), we'd need to use Fetch Response objects for this and need Fetch Response objects to contain that information. Monkey patching this doesn't seem like the right way to go, outside the context of a larger rebase on top of Fetch.

[yoavweiss]

Happy to add the above example to the spec, as well as make sure the tests in web-platform-tests/wpt#13518 cover all those scenarios and make that an L2 blocker. The wider scope definition is something that will happen in #152 as part of L3.

[yoavweiss]

Closed by #196. It did not add explicit examples but the (handwavy) language there should make the above clearer.

[yoavweiss]

#196 didn't really close this one. #197 will

[yoavweiss]

On the last call, we decided to postpone this alignment to L3, as it most probably requires implementation changes.

[yoavweiss]

Closing as #197 was merged