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

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

Thanks @mikewest for the ping. The TAG is in favor of the direction here, with the following additional thoughts to consider.

The point is well-taken that same-site is hard/impossible to get exactly right outside of the browser, so it seems reasonable to expose it. We'd strongly recommend considering the addition of `isSameOrigin()` and `isSameSite()` to `URL` as a simpler possible alternative approach that still achieves that goal. The main question is whether this alternative gives up too much by not improving handling of opaque URLs.

To that end, as a next step in developing the proposal, following through on the line of thought explored in https://github.com/mikewest/origin-api/blob/main/README.md#what-about-existing-origin-getters seems important. We understand the problem with the status quo of all opaque origins serializing to `"null"`, but as the explainer points out, it's important that the platform be able to give out `Origin` objects directly. If the only way they can be created is from the serialized origin strings currently available from the platform, their usefulness is limited:

```js
let previousSender = null;
window.addEventListener('message', e => {
  const sender = Origin.parse(e.origin);

  // Since we're always minting new Origin objects, this check will
  // fail if two messages in a row are received from an opaque origin even if it's
  // the same one. Information about whether they're the same was lost since
  // the string passed to `Origin.parse` is always just "null" if opaque.
  if (previousSender && sender.isSameOrigin(previousSender)) {
    console.log("Got two messages in a row from the same sender");
  }

 previousSender = sender;
});
```
This is much safer than resolving to a `"null" === "null"` check that'd always be true, but the goal of "allow[ing] for `isSameOrigin()` comparisons that developers could use to establish a sender's consistency over time" is not fully realized here.

So it'd be good to flesh out the details of what else would be needed. At a minimum it seems like we'd need an `Origin` getter on the `message` event object, and a way to get the page's current `Origin`, equivalent to `window.origin` but returning the object. Are there other places that a getter for the new `Origin` object would be needed? How will these be named to distinguish them from the string-based getters?

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

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