Provide cross-origin rootBounds and rootMargin with frame-level opt-in

[ojanvafai]

In order to avoid leaking information about the parent page, IntersectionObserver doesn't allow rootBounds and rootOrigin when used from inside a cross-origin frame. As a result, libraries that run as a top-level script, but embed a cross-origin frame are having difficulty deploying.

We should add a frame-level opt-in so that this information can be exposed if the parent page is OK with it. We could do this via FeaturePolicy, embedded CSP, or a new attribute on iframe.

@szager-chromium

[clelland]

I don't know if CSP makes sense for this, it seems like a good fit for Feature Policy though. I opened w3c/webappsec-permissions-policy#132 for an actual feature proposal there.

The factor I would consider, if deciding between FP and a new iframe attribute, is how it should behave in deeply nested frames.

Specifically, is there a situation where the top-level frame would disable this for an embedded frame A (so that A can't read it's bounds), but A embeds B embeds C, and B wants to allow C to read its bounds in B?

The feature policy model is that, once turned off in a frame, a nested frame cannot turn the feature back on for itself or its own descendants. If this feature is always just about "what can I do relative to my immediate parent", and not about "what can I do with the page/user/browsing experience as a whole", then a new attribute might be a better fit at the moment.