Re: [w3ctag/design-reviews] Incubation: An `Origin` Object (Issue #1130)

mikewest left a comment (w3ctag/design-reviews#1130)

Thanks for your feedback!

> Thanks [@mikewest](https://github.com/mikewest) for sharing this proposal! The TAG looked at this and had a few questions.
> 
> * In motivating the proposal, is there more that you can share about the practical developer need for UAs supporting this natively, vs encouraging use of a library? The explainer cites [PMForce: Systematically Analyzing postMessage Handlers at Scale](https://swag.cispa.saarland/papers/steffens2020pmforce.pdf) as evidence of need, but in that paper the authors suggest that this is perhaps less of an issue than prior research had suggested:
>
>   ...
>   
>   That said, they did find instances of flawed Origin checks, so it'd be reasonable to say there's still an issue to be solved here. Is the argument that by baking it into the platform, developers are more likely to reach for the built-in solution rather than manually writing the check, even if libraries are available?

The "same-origin" check is trivial to implement in userland (modulo opaque origins which are noted below). Folks make mistakes, but I don't think developers _require_ assistance, as the string serialization is non-lossy for tuple origins. Having an object representing the actual comparison (e.g. `isSameOrigin()`) is philosophically appealing, but not necessary.

`isSameSite()`, on the other hand, is ~impossible for something other than the browser to correctly represent to developers, given the delta between the PSL shipping in the user agent in which code is executing and the PSL shipping in the library the developer updated a year ago (or, if they're totally on top of things: today!).

These marginally more complex checks are also the places in which developers tend to make the clearest errors (e.g. [`const regex = /^https:\/\/.*.example.com$/;`](https://msrc.microsoft.com/blog/2025/08/postmessaged-and-compromised/#:~:text=const%20regex%20%3D%20/%5Ehttps%3A//.*.example.com%24/%3B) which looks right, but matches "https://maliciousexample.com". It's very easy to get these checks wrong. It would be ideal to pave a path for developers' common needs that was easier to hold correctly.

> * As an alternative to consider, what about adding `isSameOrigin()`, `isSameSite()`, and maybe `originToString()` to [URL](https://developer.mozilla.org/en-US/docs/Web/API/URL) instead of introducing a new `Origin` type? This does not preclude adding `OriginPattern`, which could take URLs, if there's a need for it.

I think adding `URL.isSameOrigin()` and `URL.isSameSite()` are quite reasonable to consider, perhaps also as part of @annevk's `URLHost` linked above for "schemelessly same-site" checks. I'm not sure I understand what `originToString()` would do, given `URL.origin`. That would handle a pretty substantial subset of what developers need.

>   * Something that alternative approach might leave out is handling for opaque origins. But if this is a critical part of the proposal, it would be helpful to have the explainer dig into that a bit more, discussing scenarios where it would be useful to compare opaque origins, and what that might look like in example code.

The second paragraph of https://github.com/mikewest/origin-api/blob/main/README.md#what-about-existing-origin-getters outlines the value here. I can add more detail there if it's helpful, but the core point is that all `<iframe sandbox>` documents (and `file:` and `data:` and etc.) look the same with regard to a `MessageEvent.origin` check because the serialization to "`null`" is lossy. The sharp edge is a frame that's navigated between calls to `postMessage()`; it's still an opaque origin, so it still serializes to `null`, but it's not the _same_ opaque origin.

Similarly, `<iframe srcdoc="<iframe sandbox>" sandbox>` and various other permutations of opened windows and frames and etc. will have trouble ensuring that the child frame and the parent frame are actually "same origin" if they're only working with a string.

> * The section [An Origin Object](https://github.com/mikewest/origin-api/?tab=readme-ov-file#an-origin-object) mentions Origin will have "a stringifier named `serialization`" but that isn't shown -- should that instead say `toString()`?

Thanks for pointing that out. It should read "named `toJSON()`." This is defined in the spec at https://mikewest.github.io/origin-api/#Origin-stringification-behavior. I updated the explainer in https://github.com/mikewest/origin-api/commit/0261efa9fc6bb77bec2b21935d08839c51ce7f88.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1130#issuecomment-3229508992
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1130/3229508992@github.com>