Does the privacy test need a same origin-domain or a same origin check?

[rakuco]

In other words, do we need to check for https://html.spec.whatwg.org/multipage/browsers.html#same-origin or https://html.spec.whatwg.org/multipage/browsers.html#same-origin-domain?

AFAICS the latter (which we currently use) just takes document.document into consideration compared to the "same origin" check.

I am not informed enough to know which to choose, so this is an honest question. Looking at https://dontcallmedom.github.io/webdex/s.html, "same origin-domain" is used by fewer specs, and https://bugs.chromium.org/p/chromium/issues/detail?id=1027191#c6 says "Specs use 'same origin' in pretty much all cases except where forced to otherwise for compat reasons. On particular, any modern spec is likely to not use 'same origin-domain' at all".

[kenchris]

Me neither to be honest, which is why I followed the advice to do as other spec do and do the same as generic sensors :-)

But with what you write above, it seems that we should just use "same origin"

[rakuco]

Yeah, I was trying to do some digging but only found out "same origin-domain" was introduced with w3c/sensors#206, w3c/sensors#213 and w3c/sensors#267 but there was no discussion about why it was preferred over just "same origin".

See also: whatwg/html#3747 (comment) and whatwg/html#2757 (comment)

It might be worth filing an HTML spec issue to double check, or find someone who can help clarify which one should be chosen here.

[kenchris]

@cynthia @marcoscaceres would anyone of you two know / understand the difference between these two (same origin vs same origin domain), or know who would be the best to answer that?

[marcoscaceres]

Half joking... ChatGPT knows the HTML spec. If it wasn't down right now, I would ask it for an explanation 😂

Wait, the difference is in the algorithm (as those two concepts - same origin and same origin domain - are both just algorithms). There is even an example table in HTML:

So, looking at the third example in the table, "same origin domain" doesn't seem to take the port into consideration, but the domain must be the same:

("https", "example.org", 314, "example.org") | ("https", "example.org", 420, "example.org")

I think that's it! 🤞

(You can call me MarcosGPT from now on)

[marcoscaceres]

Just as bit more clarification, have a look a little bit further up in the html spec where it turn URLs into tuples origins:

A tuple consists of:

A scheme (an ASCII string).
A host (a host).
A port (null or a 16-bit unsigned integer).
A domain (null or a domain). Null unless stated otherwise.

[kenchris]

Thanks @marcoscaceres MarcosGPT :-) That indeed seems like a minor difference, and we probably should take that into consideration. As the same-origin domain is considered legacy/interopt, I don't see any reason why not to use same-origin instead.

[kenchris]

A domain (null or a domain). Null unless stated otherwise.

Yes that is pretty much the part that I didn't follow. You will always have a domain when you have a document, so I guess that might break it for using this in workers as that would not have a document

[rakuco]

I did take a look at the concepts and algorithms when filing this issue as well. What's not clear to me is whether "same origin-domain" is really something that should be phased out in specs and whether there's any case where it actually makes sense to use it rather than "same origin".

In any case, looking at https://developer.mozilla.org/en-US/docs/Web/API/Document/domain#setting_the_domain and https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#changing_origin it does look like we should be using "same origin" instead.

[marcoscaceres]

If two knowledgeable (and extremely talented!) browser engineers are confused by what it written in that spec, then that's clearly a spec bug. I'd strongly encourage you to file a bug on HTML.

Clearly the editors of the HTML spec knew these two things would be super confusing, as they added the example table to help a bit... it might be good to just point them to the text that is troubling you above.

[marcoscaceres]

Here is what ChatGPT said 🤣:

Kenneth and Raphael went to sea,
To learn about web security.
They learned about two concepts new,
Called "same origin" and "same origin-domain" too.

They found that when two URLs,
Have the same scheme, host, and port as well,
They're considered "same origin" true,
And that's all you need to know, it's true!

But if you want to check if two,
Origins have the same domain too,
Then "same origin-domain" you'll use,
And run an algorithm to prove the truth.

Kenneth and Raphael were happy to learn,
These concepts are useful, they could discern.
Now they'll use them to build websites,
With security that's rock-solid, and that's great!

[arskama]

It seems to be that we all agree that "same origin" is more suitable than "same origin-domain".
Furthermore more hints are showing that implementations are getting away from "same origin-domain" usage:

https://html.spec.whatwg.org/multipage/browsers.html#relaxing-the-same-origin-restriction
https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/weborigin/security_origin.h;l=313;drc=933be5e5db24585647edcd7f507ba2d48c5757c8

As @rakuco pointed out also earlier, "same origin-domain" is used by fewer specs.

If no one really goes against it, I would propose the change from "same origin-domain" to "same origin"