Provide a hook for "being invoked cross origin"?

[domenic]

w3ctag/design-reviews#147 (comment) makes it clear that telling if you're in a method that's being invoked cross-origin is kind of complicated. This has also come up in a desire for blocking navigator.vibrate in cross-origin iframes.

I think it would be good if HTML provided an easy algorithm that could be used by spec authors to determine if they are being invoked cross-origin. That is, spec authors could write

1. If [this algorithm is being invoked cross-origin], abort these steps.

I think this would expand to the following, which is more precise than my above-linked version:

1. If this condition is being checked inside an operation, let settings be the [relevant settings object] of the object on which the operation is being invoked. Otherwise, if the condition is being checked inside a constructor, let settings be the [current settings object].
2. If settings has no [responsible document], return false. (It is impossible to invoke methods or constructors cross-origin inside a worker.)
3. Let context be settings's [responsible browsing context].
4. If context is a [top-level browsing context], return false.
5. Otherwise, context must have a [top-level browsing context] (i.e. an [ancestor browsing context] with no [parent browsing context]). Let topOrigin be that top-level browsing context's [Window]'s [relevant settings object]'s [origin].
6. Return false if settings's [origin] is [same-origin] with topOrigin.
7. Return true.

We would preface this with a note that it's only usable inside the synchronous portion of a method or constructor.

What do people think? I'm especially curious of @bzbarsky and @mikewest's opinion. Do we have more use cases for this sort of check? Maybe it should be a Web IDL annotation, either immediately or eventually, like [SecureContext] is?

[mikewest]

Some browsers are experimenting with a few restrictions on cross-origin script: https://github.com/WICG/interventions/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20cross-origin is a partial list. It seems like this concept is a reasonable one to define once and reuse.

I'm not sure it makes sense as an IDL attribute, as it's not clear that we'd have any standardized behavior. On the one hand, you have things like WICG/interventions#16 which modify the behavior of window.location such that it requires a user-gesture (though I think the experimental data shows that that will be harder to do without regression than we expected), on the other you have things like WICG/interventions#25 which aim to neuter an API entirely. It seems better to leave that up to the document's prose rather than trying to define a pre-made set of behaviors to stuff into IDL.

[annevk]

If settings has no [responsible document], return false. (It is impossible to invoke methods or constructors cross-origin inside a worker.)

Why? The worker can be instantiated from an <iframe> document that is cross-origin, no?

[bzbarsky]

I have three main comments, I think:

1. Defining this in terms of browsing contexts gets pretty weird when the responsible document is not fully active, right?
2. Calling this "invoked cross-origin" is a bit weird because the actual invocation is not in fact "cross-origin" in any sense, especially when the caller and the callee are both the same global. It's really more of a "invoked in a third-party context" kind of concept. @annevk is right that this confusion is probably leading to incorrect conclusions about the worker case, in which you can never be cross-origin in any meaningful sense, but can totally be "in a third-party context".
3. Which brings us to this question: if http://a loads an iframe from http://b which then loads an iframe from http://a, do we want API calls in that innermost frame to be considered "good" or "bad" in terms of the distinction we're trying to draw here? The proposed text would consider them "good", but there's a good argument for "bad".

I agree that there's not much point to an IDL attribute here.

[mikewest]

1. Is it possible for a nested browsing context to have a non-active parent?

2. I agree about the naming. I wonder if this boils down to a similar kind of thing to the clumsy "same-site" definition I need to clean up in https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00#section-2.1? It certainly seems similar.

3. I agree that A => B => A should not be considered "good". That's a mistake we made with X-Frame-Options that I'd like not to repeat.

[bzbarsky]

Is it possible for a nested browsing context to have a non-active parent?

Yes. See https://html.spec.whatwg.org/multipage/browsers.html#concept-document-salvageable

In addition to that, it's not really clear what https://html.spec.whatwg.org/multipage/browsers.html#a-browsing-context-is-discarded means in practice, which means that even if a document is not salvageable it's not clear whether the browsing contexts inside it really go away when it's navigated away from, in terms of reachability from their documents. If they do then Domenic's steps have a problem, because either "Let context be settings's [responsible browsing context]" returns null or something or "If settings has no [responsible document], return false" would return false or something along those lines.

As in, if things do get torn down, in whatever sense, you end up not being able to check against the top thing and have to deal with that problem. If they don't get torn down, then you can do the check, but it probably doesn't do what you want.

And in addition to all that, it's not clear to me what the APIs that use this sort of check should do if they are simply in an inactive document in a toplevel browsing context. Should it matter whether that inactive document is or is not same-origin with the active document?

[domenic]

I'm going to close this issue until we have some more concrete use cases, to make sure it generalizes correctly. So far we have the use case of blocking navigator.vibrate in cross origin iframes, but not much else.