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

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

Thanks @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:

  > While an investigation of how we can adapt the postMessage API to make it secure and usable for developers in this work would not do it justice, we nonetheless want to highlight two observations that we hope to be influential for developers and standard authorities alike. First, most of the handlers that protect sensitive behavior implement origin checks correctly. Second, postMessage relays can undermine the security of correct origin checks.
  > ...
  > Contrary to previous analyses, we show that the majority of origin checks protecting sensitive behavior are implemented correctly; thus, no longer allow an attacker to bypass them.

  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?

- 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.
  - 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 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()`?

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

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