Open clelland opened 7 years ago
I thought we only updated step 2 of https://html.spec.whatwg.org/multipage/browsers.html#same-origin in https://w3c.github.io/webappsec-suborigins/#comparing-origins so step 1 (which is for opaque origins) will fire before it even hits our changes? Are we missing something?
https://w3c.github.io/webappsec-suborigins/#comparing-origins doesn't call into https://w3c.github.io/webappsec-suborigins/#comparing-physical-origins, so I don't think that's relevant.
I was looking at the same-physical-origin algorithms, and the spec text makes it look like they should accept any origin, but they implicitly require their inputs to be tuple origins.
Whether it could be hit in practice, I'm not certain -- I suppose that if a fetch were initiated by a script running in an opaque origin, then maybe https://w3c.github.io/webappsec-suborigins/#unsafe-credentials could cause same-physical-origin to be called with the request origin being opaque.
The "same physical origin" algorithm doesn't seem to be well defined when either input is an opaque origin; it refers to #physical-origin-concept, which can only be applied to tuple origins.
I suspect that an opaque origin should be same physical origin with itself, and not with any other origin, and that the spec should either
explicitly spell out the case for comparing opaque origins in 'same physical origin', or
change the definition of 'physical origin' to say that the physical origin of an opaque origin A is A.