An `Origin` Object

[mikewest]

WebKittens

@annevk

Title of the proposal

An Origin Object

URL to the spec

https://mikewest.github.io/origin-api/

URL to the spec's repository

https://github.com/mikewest/origin-api/

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

w3ctag/design-reviews#1130

Mozilla standards-positions issue URL

mozilla/standards-positions#1280

WebKit Bugzilla URL

No response

Radar URL

No response

Description

• This grew out of a conversation at Consider some more narrow _origin_ matching mechanism? whatwg/urlpattern#275.

• There's some relationship to @annevk's Expose a URLHost class to JavaScript whatwg/url#288, though I think that aims to solve a distinct problem.

• This would be, I think, the first place we'd directly expose the "same-site" concept in a way that enabled comparison.

[mikewest]

(@lukewarlow: regarding venue, my expectation is that this would fold into HTML (see whatwg/html#11534) and that it's small enough to do so without a stop in WICG. If that turns out to be incorrect, I'll certainly find a better place for the discussion than my personal repo. :) )

[lukewarlow]

Yeah I expect it's fine just did a rough approximation of labels I think are correct for now :)

[othermaciej]

Some random thoughts:

• Could you explain the use cases more? The explanation in the repo readme was thin. It said it could help avoid security vulnerabilities but wasn’t entirely clear what kind or whether that requires all the surface provided here.

• Seems like if this is added to the platform, it should perhaps go into the URL spec (maybe along with the definition of origins currently in HTML) rather than into HTML? Not sure.

• It’s odd that this only interacts with URLs serialized as strings and not with the URL object as defined in the URL standard. Even fromURL takes a string, not a URL.

• A URL object with everything but host port and scheme empty could represent an origin. Maybe methods could be added to URL to do things like same-origin or same-site checks, if that is the important use case. Maybe those methods could be added to URL? Any comments on alternate designs like that?

[mikewest]

Thanks for your thoughts, @othermaciej:

• Could you explain the use cases more? The explanation in the repo readme was thin. It said it could help avoid security vulnerabilities but wasn’t entirely clear what kind or whether that requires all the surface provided here.

The core problem I see is that the platform exposes only serializations of origins, pushing developers towards string comparisons that can be challenging to perform in the same way the browser will. This shows up most critically when handling MessageEvent objects, but developers write lots of code making security and behavioral decisions based on examining origin-like strings; there's value in paving a safe path here.

• Seems like if this is added to the platform, it should perhaps go into the URL spec (maybe along with the definition of origins currently in HTML) rather than into HTML? Not sure.

If we define this object, we should do so in the context of defining the concepts it wraps (origin, site, etc). That currently mostly lives in HTML (with some pieces in URL and Fetch), but it could be perfectly reasonable for it to live elsewhere. @annevk likely has a stronger opinion here than I do.

• It’s odd that this only interacts with URLs serialized as strings and not with the URL object as defined in the URL standard. Even fromURL takes a string, not a URL.

I read https://url.spec.whatwg.org/#url-apis-elsewhere as suggesting that USVString is preferred to URL in IDL specifications. I don't have a strong preference one way or the other, but I do see value in having a string-to-origin parser that accepts common divergence from origin serialization (e.g. a trailing /).

• A URL object with everything but host port and scheme empty could represent an origin. Maybe methods could be added to URL to do things like same-origin or same-site checks, if that is the important use case. Maybe those methods could be added to URL? Any comments on alternate designs like that?

I think isSameOrigin()/isSameSite() methods hanging off of URL could take care of a substantial chunk of what I'm after here for tuple origins (and we should probably add them). For me, it makes more sense to talk about both "same-origin" and "same-site" in the context of origins than URLs, but that's mostly aesthetic.

That said, I don't think URL can reasonably handle opaque origin comparison, and it seems like we'd have to stretch a bit to get them to do so. That's a niche use case, but one that seems impossible to correctly handle without some new thing. whatwg/urlpattern#275 (comment) suggested exposing match methods wherever we expose a serialized origin, which could be an alternative worth exploring.

I'm also interested in figuring out what a broader "partition" concept might look like, which @annevk has pointed towards in whatwg/url#288 (comment) and whatwg/urlpattern#275 (comment). My feeling is that that concept would require an Origin as part of its composition, but I'm certainly open to other interpretations.

[annevk]

Thanks for sharing this idea! Opaque origins certainly make the case for having something that is distinct from URLs. Having something immutable is nice as well. But those reasons don't justify many other aspects of the proposal. I filed these issues as a start:

• Do we need stringification and toJSON()? mikewest/origin-api#7
• Parser motivation mikewest/origin-api#8
• Does Origin sufficiently improve the situation for the main use case? mikewest/origin-api#9

[mikewest]

Thanks for your feedback, here and in those issues. Looking forward to continuing the conversation there.