An `Origin` Object

[mikewest]

Specification title

An Origin Object

Specification or proposal URL (if available)

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

Explainer URL (if available)

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

Proposal author(s)

@mikewest

MDN URL

No response

Caniuse.com URL

No response

Bugzilla URL

https://bugzilla.mozilla.org/show_bug.cgi?id=2001139

Mozillians who can provide input

@mozfreddyb @zcorpan

WebKit standards-position

WebKit/standards-positions#538

Other information

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

• There's some relationship to @annevk's URLHost proposal, 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.

[mozfreddyb]

CC @simon-friedberger, as this touches on previous discussions on how to expose the PSL to the web.

[simon-friedberger]

For reference:

• There is a Web Extension API under discussion for the public suffix list here: Proposal: Public Suffix API w3c/webextensions#676
• A web API for this has been requested here: Public Suffix API whatwg/url#528

The Web Extension API had some extended discussion around special cases like IP addresses and split-DNS but those are issues when using the public suffix list to determine if something is a valid TLD or for highlighting, not when checking two origins for same-site-ness. (On the other hand, determine if something is a valid TLD or for highlighting is not covered by this proposal.)

[simon-friedberger]

@mikewest Is it wise to include isSameSite() in this proposal? It seems your argument that "it requires an understanding of the Public Suffix List/registrable domains" still applies.

I cannot think of a lot of reasons to use this API. A site which wants to check postMessage origins should almost certainly use an OriginPattern or it risks errors in user agents with a different PSL version. This is useful for third-parties which cannot tell where site boundaries are (like user agents trying to highlight the important part of a domain or email servers trying to determine who should be signing a request) but should be unnecessary for the site itself.

It would be useful in some cases but then we should probably also include a formatShortOrigin or highlightOrigin to cover the rest of the PSL usage. (A generic "getSite" would probably be most broadly applicable.)

[mikewest]

Thanks for links to the PSL API proposals. I can certainly imagine something like that being useful, though I'll admit that I'm much more narrowly interested in explaining user agents' behaviors around security and privacy boundaries than I am in exposing the PSL itself. Knowing that two Origins (and/or URLs) are same-origin or same-site is directly helpful in that regard, and it's where the proposal here focuses.

@mikewest Is it wise to include isSameSite() in this proposal? It seems your argument that "it requires an understanding of the Public Suffix List/registrable domains" still applies.

What's the context in which I made that comment? Sorry, there are a few threads going. :)

I cannot think of a lot of reasons to use this API. A site which wants to check postMessage origins should almost certainly use an OriginPattern or it risks errors in user agents with a different PSL version. This is useful for third-parties which cannot tell where site boundaries are (like user agents trying to highlight the important part of a domain or email servers trying to determine who should be signing a request) but should be unnecessary for the site itself.

Beyond conceptual clarity (which IMO is important!), the core thing this enables is equality comparisons for opaque origins, which all serialize as null. "Is this sandboxed frame the same one that messaged me a minute ago? Or has it been sneakily navigated?" is a question that's pretty difficult to answer if we're only working with lossy serializations.

Also, you point to different PSL versions as risking errors: I think the clearest way to address those errors is to help developers understand the security boundaries in the user agent within which they're executing code, rather than the boundaries in tip-of-tree PSL (or, more likely, an 8 month old snapshot).

It would be useful in some cases but then we should probably also include a formatShortOrigin or highlightOrigin to cover the rest of the PSL usage. (A generic "getSite" would probably be most broadly applicable.)

For this use case, I'd prefer for us to find a way to help developers through something like the recommendations in https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/url_display_guidelines/url_display_guidelines.md. That would need to be a bit more complicated than "give me the site", but probably more closely matches the thing we'd like developers to do, given space limitations.

[simon-friedberger]

That line was from the explainer.

I am not strongly against having an "isSameSite" method on the Origin object. I don't think it hurts a lot as long as people have a good understanding of when to use it. But when to use it is unfortunately "as never as possible".

I cannot think of a lot of reasons to use this API. A site which wants to check postMessage origins should almost certainly use an OriginPattern or it risks errors in user agents with a different PSL version. This is useful for third-parties which cannot tell where site boundaries are (like user agents trying to highlight the important part of a domain or email servers trying to determine who should be signing a request) but should be unnecessary for the site itself.

Beyond conceptual clarity (which IMO is important!), the core thing this enables is equality comparisons for opaque origins, which all serialize as null. "Is this sandboxed frame the same one that messaged me a minute ago? Or has it been sneakily navigated?" is a question that's pretty difficult to answer if we're only working with lossy serializations.

It seems to me that developers should still be checking the Origin here not the Site, right? And shouldn't the site actually be checking "is this frame from the OriginPattern that I expect" instead of "is it the same as before"?

I may not be creative enough in trying to think of use-cases.

Also, you point to different PSL versions as risking errors: I think the clearest way to address those errors is to help developers understand the security boundaries in the user agent within which they're executing code, rather than the boundaries in tip-of-tree PSL (or, more likely, an 8 month old snapshot).

That depends on if the developer wants the behavior that they expect and used in tests or what the browser is currently doing, which might change tomorrow.

Unrelated: You should probably treat fingerprinting based on the PSL version somewhere.

[mikewest]

Thanks for your feedback, @simon-friedberger!

That line was from the explainer.

Got it, thanks! My intent with that claim was to suggest that writing a "same-site" check in userland is possible, but difficult, as the understanding of the PSL it represents needs to match the user agent's understanding, which is only indirectly exposed. I could probably do a better job of making that point.

Still, I see that claim as justifying adding a site comparison mechanism to the platform, as it removes the risk that developers and browsers will disagree about an important boundary.

I am not strongly against having an "isSameSite" method on the Origin object. I don't think it hurts a lot as long as people have a good understanding of when to use it. But when to use it is unfortunately "as never as possible".

Sure, as long as we agree that the scope of "as possible" is shrinking as we use the "site" concept in more and more places in ways that have privacy and security implications. :)

Beyond conceptual clarity (which IMO is important!), the core thing this enables is equality comparisons for opaque origins, which all serialize as null. "Is this sandboxed frame the same one that messaged me a minute ago? Or has it been sneakily navigated?" is a question that's pretty difficult to answer if we're only working with lossy serializations.

It seems to me that developers should still be checking the Origin here not the Site, right? And shouldn't the site actually be checking "is this frame from the OriginPattern that I expect" instead of "is it the same as before"?

For <iframe sandbox> (and documents which sandbox themselves via CSP (and data: documents (and etc))) the origin is opaque. Today, we have a lossy serialization of all such origin as the string "null", which means that distinguishing senders and comparing them is difficult.

That is, "is this frame from the origin that I expect" is an impossible question to answer in this scenario given the tools we give developers.

Also, you point to different PSL versions as risking errors: I think the clearest way to address those errors is to help developers understand the security boundaries in the user agent within which they're executing code, rather than the boundaries in tip-of-tree PSL (or, more likely, an 8 month old snapshot).

That depends on if the developer wants the behavior that they expect and used in tests or what the browser is currently doing, which might change tomorrow.

I agree with you that there are some questions here, but the latter seems more critical since it's what determines the behavior developers will actually experience.

Unrelated: You should probably treat fingerprinting based on the PSL version somewhere.

For Chromium, at least, the PSL version is tied to the browser version. You're right that it exposes information about the browser which is worth calling out, but it doesn't seem different in kind from any other newly-exposed or newly-deprecated API or behavior in that respect.

Does Mozilla distribute PSL updates out of band from browser updates?

[simon-friedberger]

Does Mozilla distribute PSL updates out of band from browser updates?

No, we do not. We had this option but we never enabled it and recently removed the code for it. There is no code (or spec), explicitly, for handling PSL updates so it was considered too risky to do that without at least a browser restart.

Sure, as long as we agree that the scope of "as possible" is shrinking as we use the "site" concept in more and more places in ways that have privacy and security implications. :)

That seems fair, but now I would like to know how and why it is growing. And I would like to encourage the use of Origin over Site as much as possible.

I agree with you that there are some questions here, but the latter seems more critical since it's what determines the behavior developers will actually experience.

Again, besides the privacy concerns I am not against it, but I think the reasoning for it is still weak. The PSL is a heuristic and it behaves differently in different browsers and differently yesterday, today and tomorrow. The cases where a developer needs the exact same behavior as the browser should be negligible.

Unrelated: You should probably treat fingerprinting based on the PSL version somewhere.

For Chromium, at least, the PSL version is tied to the browser version. You're right that it exposes information about the browser which is worth calling out, but it doesn't seem different in kind from any other newly-exposed or newly-deprecated API or behavior in that respect.

There might still be plenty of browser updates which a website cannot readily detect as a change in web features or at least not in an automated way. Since the PSL is public it is easy to query a few origins to determine the current version.

[mikewest]

Thanks again for your feedback!

Sure, as long as we agree that the scope of "as possible" is shrinking as we use the "site" concept in more and more places in ways that have privacy and security implications. :)

That seems fair, but now I would like to know how and why it is growing. And I would like to encourage the use of Origin over Site as much as possible.

I agree with you that we should generally aim to hold boundaries at the origin when possible.

Here, I'm thinking of things like samesite cookies, sec-fetch-site, the storage partitioning work generally, site-level process isolation, CORP: same-site, etc. We've generally adopted it as a privacy boundary, and its impact on storage partitioning/spectre bleeds into a security boundary.

I agree with you that there are some questions here, but the latter seems more critical since it's what determines the behavior developers will actually experience.

Again, besides the privacy concerns I am not against it, but I think the reasoning for it is still weak. The PSL is a heuristic and it behaves differently in different browsers and differently yesterday, today and tomorrow. The cases where a developer needs the exact same behavior as the browser should be negligible.

I think it's valuable for developers to be able to make decisions with an understanding of how the browser in which they're executing code will behave. I agree

For Chromium, at least, the PSL version is tied to the browser version. You're right that it exposes information about the browser which is worth calling out, but it doesn't seem different in kind from any other newly-exposed or newly-deprecated API or behavior in that respect.

There might still be plenty of browser updates which a website cannot readily detect as a change in web features or at least not in an automated way. Since the PSL is public it is easy to query a few origins to determine the current version.

Certainly possible. I've added a note to the monkey-patch spec in mikewest/origin-api@865e720. Thanks for calling it out!