Is "unit of related similar-origin browsing contexts" the right thing to use in the rootMargin / rootBounds restriction?

[mstange]

There are two issues here that were brought up when I talked to members of our DOM team at Mozilla:

• The word "related" is superfluous because the root and the target will always be in the same tab.
• Why did you choose "similar-origin" over "same-origin"? Is there a use case for allowing access between cross-origin documents which are similar origin? Could the same information be obtained with existing APIs or does this allow new information leaks?

[szager-chromium]

That phrase is standard spec-ese:

https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-similar-origin-browsing-contexts

Is there a better or more accurate way to say this?

[ojanvafai]

I think we were going for whether this frame is in the same origin as the top-level frame since if it is, then you have access to all the information in the top-level frame even if there's a cross-origin frame wedged between you.

I think we could also define this as being in the same origin as the parent frame.

I'm not really sure what's best here, but I'm hopeful we can still change Chrome's behavior here without breaking content if there's something we should be doing differently.

[szager-chromium]

If I remember correctly, the issue is whether there are any intervening frames between target and root that are from a different origin. In that case, we don't want to report root bounds.

[ojanvafai]

IIRC @bzbarsky had opinions on this. I don't have strong opinions on this. We should do whatever is most consistent with other things on the platform. No reason for IntersectionObserver to be a special snowflake.

[zetafunction]

Given the replies, it sounds like we really just want same origin, right? I think that matches what Chromium actually implements already.

However, if we want to be more strict and disallow intermediate frames that are cross-origin, then things might be more interesting from a compatibility standpoint.

[bzbarsky]

I'm not sure I have a strong opinion on this. As @ojanvafai points out, if you're same-origin with the top window you can already do window.top.whatever to get whatever you want out of it... So the real question is whether any information about those intervening frames is leaked. If it's not, then it doesn't matter what their origins are, seems to me.

[emilio]

This whole concept is gone from the HTML spec now, but this is still used in IntersectionObserver.

[mystor]

cc @annevk who did the BrowsingContextGroup spec changes

[annevk]

The new concept would be similar-origin window agent, which is roughly what that old concept corresponds to, minus its flaws (docgroup in Firefox, iirc). This would potentially allow certain same-site-but-cross-origin leaks, similar to document.domain and cookies. Is that really desirable?

A strict same-origin check on the origins of the documents involved would be more desirable I think. (As well as tests.)

@dtapuska if agent is chosen here that would mean that opting into a fresh agent would disable this API (if I'm understanding things correctly). We should add that to the list of things to test.

[dtapuska]

@annevk I agree, but I'd really need to understand why the restriction of the root margin is in place. And if so whether this should actually be a permission that is delegated. ie; someone might choose to delegate the rootMarginIntersectionPermission as well as a fresh agent to get something that is compatible to what they'd have today.

[annevk]

Given what @ojanvafai wrote the most sense would make a "same origin-domain" check, presumably. That is, if you have script access to each other bits can leak, otherwise they cannot. It would be good to get this fixed though because as written the security model is broken.

[rniwa]

@smfr