Incumbent globals are mostly used for things like the origin of a postMessage, no?

When doing someWindow.postMessage(), the current realm inside the call will be that of someWindow, but the incumbent global is whatever code contains the postMessage call, no?

(In reply to Boris Zbarsky from comment #1)
> Incumbent globals are mostly used for things like the origin of a
> postMessage, no?
> 
> When doing someWindow.postMessage(), the current realm inside the call will
> be that of someWindow, but the incumbent global is whatever code contains
> the postMessage call, no?

When is that observable? In the same-origin case, the origins are indistinguishable. In the cross-origin case, the realm of the function is already that of the caller.

Bob also said in another bug:

> Won't we at least always need incumbent global for navigation?
> It's sometimes used to get the source browsing context.
> I can't see how iframe sandboxing would work if there were no distinction
> between the incumbent global and the current global.

I don't quite follow this. Can you explain in more detail Bob?

> In the cross-origin case, the realm of the function is already that of the
> caller.

Ah, because we vend per-origin functions for cross-origin access?

As long as the only thing the incumbent global is used for is its origin, I agree that it can be merged with the concept of current realm.  If the globals's document's URI ever gets examined directly, we can't do that, of course.

(In reply to Boris Zbarsky from comment #4)
> As long as the only thing the incumbent global is used for is its origin, I
> agree that it can be merged with the concept of current realm.  If the
> globals's document's URI ever gets examined directly, we can't do that, of
> course.

In that case, whether or not we can depends on whether any websites depend on it, right?

Sure, but I think it's safe to assume they do if anything actually does the base URI thing from incumbent globals...

(In reply to Bobby Holley (:bholley) from comment #3)
> Bob also said in another bug:
> 
> > Won't we at least always need incumbent global for navigation?
> > It's sometimes used to get the source browsing context.
> > I can't see how iframe sandboxing would work if there were no distinction
> > between the incumbent global and the current global.
> 
> I don't quite follow this. Can you explain in more detail Bob?

In the case of your example in the description, B is used to get the source browsing context for navigation, the browsing context being navigated is of course that of C.
This would come into play if B were to be sandboxed and unable to navigate C.

Sorry a bit of a rushed explanation there.

(In reply to Bob Owen from comment #7)
> In the case of your example in the description, B is used to get the source
> browsing context for navigation, the browsing context being navigated is of
> course that of C.

Right. I am proposing that the source browsing context is C in the same-origin case, and B in the cross-origin case.

> This would come into play if B were to be sandboxed and unable to navigate C.

You mean that B is sandboxed but both allow-same-origin and allow-scripts? In that case, it can equally just turn off its own sandboxing.

(In reply to Bobby Holley (:bholley) from comment #8)
> (In reply to Bob Owen from comment #7)
> > In the case of your example in the description, B is used to get the source
> > browsing context for navigation, the browsing context being navigated is of
> > course that of C.
> 
> Right. I am proposing that the source browsing context is C in the
> same-origin case, and B in the cross-origin case.

Ah, right hadn't realised this and didn't have time to read other comments last night.
So, no change in the cross-origin case then.

I just tried using GetCurrentGlobal in our location implementation.
I ran the sandboxed navigation by location tests and it was indeed only allow-same-origin tests that failed.

> > This would come into play if B were to be sandboxed and unable to navigate C.
> 
> You mean that B is sandboxed but both allow-same-origin and allow-scripts?
> In that case, it can equally just turn off its own sandboxing.

This would need making clear in the spec, I think.
It's possibly a good change as at the moment it gives you a false sense of security.

Just some random thoughts here ...

What about if the sandboxed iframe were for a cross origin document?
allow-same-origin and allow-scripts is legitimate in that case (see [1] & [2]).
Is there a way that script in a sandboxed cross-origin iframe could get hold of the location object from another window for the same origin?
Maybe not.

I assume we're OK for window.open() as the incumbent and realm globals would be the same there.
Again, if in the cross-origin case above, could a script get hold of another window object and call open on that?

Only other things I can think of from the Source Browsing Context side of things, is that is is used for some things other than navigation security.

It is used for the seamless iframe behaviour (although I'm not sure anyone has implemented this yet).
It is also used to set the referrer.

I'll need to go and read the spec to see if this change would cause problems.


[1] In examples here: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox
[2] In the note here: http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#attr-iframe-sandbox-allow-same-origin

(In reply to Bob Owen from comment #9)
> > You mean that B is sandboxed but both allow-same-origin and allow-scripts?
> > In that case, it can equally just turn off its own sandboxing.
> 
> This would need making clear in the spec, I think.
> It's possibly a good change as at the moment it gives you a false sense of
> security.

Well, the spec does have a big fat warning about it (as you mention), but there are also legitimate use cases (which you also mention).

I think the spec makes it pretty clear that allow-same-origin and allow-scripts means that you're not protected from any same-origin content.

> Just some random thoughts here ...
> 
> What about if the sandboxed iframe were for a cross origin document?
> allow-same-origin and allow-scripts is legitimate in that case (see [1] &
> [2]).
> Is there a way that script in a sandboxed cross-origin iframe could get hold
> of the location object from another window for the same origin?

It doesn't matter - in the cross-origin case, the realm is the caller's origin (see bug 20701). In the same-origin case, it doesn't matter by definition.

> I assume we're OK for window.open() as the incumbent and realm globals would
> be the same there.
> Again, if in the cross-origin case above, could a script get hold of another
> window object and call open on that?

See above.

> Only other things I can think of from the Source Browsing Context side of
> things, is that is is used for some things other than navigation security.
> 
> It is used for the seamless iframe behaviour (although I'm not sure anyone
> has implemented this yet).
> It is also used to set the referrer.
> 
> I'll need to go and read the spec to see if this change would cause problems.

It's important to remember that, even if this does change a referrer somewhere, it only matters for web-compat if all of UAs currently implement the spec behavior (which I expect is probably not the case).


The big win here, of course, would be to remove an unnecessary concept and simplify the spec. Hixie, what do you think?

(Note that I'll be on PTO for the next 10 days).

(In reply to Bobby Holley (:bholley) from comment #10)

> I think the spec makes it pretty clear that allow-same-origin and
> allow-scripts means that you're not protected from any same-origin content.

Yeah, I suppose, in the same-origin, case having a warning that the sandbox can be removed is enough and stating that, even without doing that, you could navigate any same-origin browsing context you can get hold of is secondary. 

> > What about if the sandboxed iframe were for a cross origin document?
> > allow-same-origin and allow-scripts is legitimate in that case (see [1] &
> > [2]).
> > Is there a way that script in a sandboxed cross-origin iframe could get hold
> > of the location object from another window for the same origin?
> 
> It doesn't matter - in the cross-origin case, the realm is the caller's
> origin (see bug 20701). In the same-origin case, it doesn't matter by
> definition.

Not quite, because the document in the iframe is cross-origin from its parent and so can't remove its sandbox.

I tried an example:
p.html served on 127.0.0.1:8001

   <iframe sandbox="allow-same-origin allow-scripts" src="http://127.0.0.1:8002/i1.html"></iframe>
   <iframe sandbox="allow-same-origin" src="http://127.0.0.1:8002/i2.html"></iframe>

i1.html served on 127.0.0.1:8002

   <script> parent[1].location.href = "http://example.com"; </script>

At least in gecko, the navigation currently fails, but works if I change to use the Current/Realm Global.
But i1.html could not remove its sandbox.

As the two documents still have to be same-origin, I'm not sure how much this change matters though.

> It's important to remember that, even if this does change a referrer
> somewhere, it only matters for web-compat if all of UAs currently implement
> the spec behavior (which I expect is probably not the case).

Right, we just need to be happy that, in the same-origin case, when you use otherwindow.location or otherwindow.open, making the (specced) referrer otherwindow.document.URL makes sense.

It doesn't sound that crazy to me.
 
> The big win here, of course, would be to remove an unnecessary concept and
> simplify the spec. Hixie, what do you think?

Sure, I'm not trying to argue against it necessarily, just thinking about what it might affect.
If we can make it work in a sensible way without this then I'm all for it.

> 
> (Note that I'll be on PTO for the next 10 days).

Hope you (have / have had) a great break. :-)

(In reply to Bob Owen from comment #11)

> At least in gecko, the navigation currently fails, but works if I change to
> use the Current/Realm Global.
> But i1.html could not remove its sandbox.
> 
> As the two documents still have to be same-origin, I'm not sure how much
> this change matters though.

Right. The other document could just as easily do parent[1].eval('location.href = "..."'), which would match the Realm Global behavior. This works even without allow-scripts.

(In reply to Bobby Holley (:bholley) from comment #12)

> > As the two documents still have to be same-origin, I'm not sure how much
> > this change matters though.
> 
> Right. The other document could just as easily do
> parent[1].eval('location.href = "..."'), which would match the Realm Global
> behavior. This works even without allow-scripts.

Ah, yes, I was forgetting that you can use eval to trump everything.
I was surprised that this worked without allow-scripts on the target of the eval though ... every day's a school day. :)

So, while this is a change in behaviour, it's superficial from a security point of view.

Ok. Let's see what Hixie thinks.

(In reply to Bobby Holley (:bholley) from comment #2)
>
> When is that observable? In the same-origin case, the origins are
> indistinguishable. In the cross-origin case, the realm of the function is
> already that of the caller.

Where is that specified? I couldn't find anything in the ES6 spec about origins.


I'm not really sure I understand the proposal here. Are you suggesting we keep the stack of script settings objects but change anywhere that uses the incumbent script settings object to using the current realm instead?

How would that work with things like

   setTimeout(window.open, ...)

...where you never re-enter the ES spec? (Right now, the WebIDL spec takes care of setting up the script settings stack in this case, IIRC.)

Also, if a windowA script calls windowB.open(), right now you're going to use windowA as the source browsing context (which is pretty important, e.g. to get the right referrer). Similarly, the logic in window.close() uses the incumbent script settings object, and wouldn't work right if it was based on the identity of window itself.

> Where is that specified?

In the proposed spec for bug 20701.

>...where you never re-enter the ES spec?

The function window.open still has Realm, and calling it sets it up as the current Realm, no?

You're correct that the source browsing context would need to be tracked separately, though.  In fact, anything apart from origin that's derived from the incumbent global would still need to be tracked.

(In reply to Ian 'Hixie' Hickson from comment #15)
> How would that work with things like
> 
>    setTimeout(window.open, ...)
> 
> ...where you never re-enter the ES spec? (Right now, the WebIDL spec takes
> care of setting up the script settings stack in this case, IIRC.)

What Boris said. Alternatively, we could leave the model closer to what it is right now (where we stash/restore the incumbent for WebIDL callbacks), but just change how we acquire the incumbent when the callback is passed to WebIDL.
 
> Also, if a windowA script calls windowB.open(), right now you're going to
> use windowA as the source browsing context (which is pretty important, e.g.
> to get the right referrer).

Well, this begs the question I'm really asking here. Taking the example in comment 0, does the web depend on the referrer being B rather than C? I'm skeptical that it does, given that it was only a year or so ago that we shipped Firefox with referrer based on the entry global [1].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=809290

(in reply to comment 16)

IMHO we shouldn't ever be deriving an origin from a global. Settings objects track the origin to use for security checks.

postMessage() technically derives it from the Document associated with the Window object on which it was invoked, which I guess is a global in a sense, but that's not really critical to the design. We could just as easily (if not logically) have put postMessage() on the Location object so you'd do locationObjectOfTarget.postMessage(), for instance, with no other global in sight.


I don't know if window.open has a Realm when used in the way above. I don't think the WebIDL spec reinvokes the ES6 spec's machinery to call native code callbacks, though, so I don't see why it would have one.

The referrer is just an example. There's lots of stuff tracked by the settings object.

(In reply to Ian 'Hixie' Hickson from comment #18)
> IMHO we shouldn't ever be deriving an origin from a global.

Can you elaborate? I'm happy to define things in terms of Documents (as the spec does), but it really doesn't matter. Every function, script, <script> element, object, etc has a Realm, and a Realm has a 1-to-1 correspondence with a global object.
 
> postMessage() technically derives it from the Document associated with the
> Window object on which it was invoked, which I guess is a global in a sense,
> but that's not really critical to the design. We could just as easily (if
> not logically) have put postMessage() on the Location object so you'd do
> locationObjectOfTarget.postMessage(), for instance, with no other global in
> sight.

Sure there is - the Location object is associated with a Window, which is a global. If it's exposed to script, it lives in a realm.

> I don't know if window.open has a Realm when used in the way above. I don't
> think the WebIDL spec reinvokes the ES6 spec's machinery to call native code
> callbacks, though, so I don't see why it would have one.

We control the specs, so we can change that. It's just a question of which model is better, given our constraints. I'm suggesting that having two ambient globals is better than three, unless our web-compat constraints dictate otherwise.

(In reply to Ian 'Hixie' Hickson from comment #19)
> The referrer is just an example. There's lots of stuff tracked by the
> settings object.

Right. And I'm asking whether anything would break if we based those things on the realm.

> I don't think the WebIDL spec reinvokes the ES6 spec's machinery to call native
> code callbacks

It does.  In particular, it calls http://people.mozilla.org/~jorendorff/es6-draft.html#sec-built-in-function-objects-call-thisargument-argumentslist (which is not clearly spelled out, but is absolutely required for sanity; see the recent public-script-coord thread on this).

More to the point, window.open is a Function object, and all Function objects in ES have a Realm.  The spec link above is just to where it gets set up as the current Realm when you call the function.

Bobby, technically an ES object does not have a Realm embedded in it, except for Function objects.  But of course at the point when an object is created there is a Realm from which we get the object's default prototype, and we can bake that into the object if we want...

> I'm happy to define things in terms of Documents (as the spec does)

I'm not.  It means we have to go special-casing things in Workers immediately.  Things defined in terms of a global, in ways that are agnostic to the type of global, only have to be defined once.

The whole Realm thing is kinda weird to me. JavaScript is an optional part of the platform, at least in theory; in principle there's no reason it couldn't be replaced by another language or disabled entirely. So I don't think it makes sense to be basing security decisions unrelated to JavaScript on JavaScript. I don't really understand why we introduced Realms at the JS level. The whole thing is kinda weird to me. (I haven't seen any rationale or even any discussion about it, either. It just appeared one day.)

> > I'm happy to define things in terms of Documents (as the spec does)
> I'm not.  It means we have to go special-casing things in Workers
> immediately.

If we define things in terms of script settings objects, we are scripting-language agnostic and don't have to special-case anything. The origin is just a feature of the script settings object.

Even if we continue with the idea that JavaScript is optional, we don't have to treat an existence of a global object as optional. Having a global object as a shared entity between workers and documents to hang information such as origin on is very useful. Not just here, but also for Fetch, Referrer Policy, Mixed Content, CSP, etc.

Maybe? I'm not so sure. It's not a concept every language has. But in any case that seems orthogonal to this bug.

(In reply to Ian 'Hixie' Hickson from comment #23)
> The whole Realm thing is kinda weird to me. JavaScript is an optional part
> of the platform, at least in theory; in principle there's no reason it
> couldn't be replaced by another language or disabled entirely. So I don't
> think it makes sense to be basing security decisions unrelated to JavaScript
> on JavaScript. I don't really understand why we introduced Realms at the JS
> level. The whole thing is kinda weird to me. (I haven't seen any rationale
> or even any discussion about it, either. It just appeared one day.)

I recognize that elegantly engineering a spec world out of the de facto web is a very non-trivial problem. But I don't think these kinds of soft constraints (whether Realm is defined in ES or in HTML) should cause us to require a more complicated implementation than our hard constraints (web-compat, perf, etc) require. I'm pretty confident that we have enough smart people involved to iron out the spec once we decide on the observables.

In any implementation today, we have to keep track of 3 ambient globals. I'm wondering whether there's a clear reason to use all three, or whether we could get away with two.

Well there are definitely cases where we need the incumbent settings object's data (e.g. picking the source browsing context for window.open), definitely cases where we need the target itself (e.g. as one of the two origins that are compared when origin-checking a contentDocument access), and there are definitely times we need the entry settings object (e.g. resolving URLs for window.open).

I would love to be able to get away with two, but I don't see how we can.

> e.g. as one of the two origins that are compared when origin-checking a
> contentDocument access

Nope.  That's a fourth relevant origin/global.  The contentDocument getter function is in the Realm of the page that the <iframe> is in, so doing an origin check against its Realm would be pretty pointless.

Assuming we fix bug 20701 as proposed, the Realm of the contentDocument getter function actually depends on the origins involved. Which is another reason that, IMHO, we shouldn't base these things on Realms and should leave Realms to just being the way JS isolates its data.

Anyway. I'm not against doing something in principle, if we really can simplify the implementation burden. I don't see how to do it. I'm open to proposals.

> Assuming we fix bug 20701 as proposed

Bug 20701 is about cross-origin objects.  But the <iframe> is not a cross-origin object.  The Realm of getters on the iframe is just the Realm whose global the ownerDocument of the iframe is associated with.

There's more to Realms than "the way JS isolates its data".  They also determine which prototypes your objects have by default and so on...

To focus this discussion:

(In reply to Ian 'Hixie' Hickson from comment #27)
> Well there are definitely cases where we need the incumbent settings
> object's data (e.g. picking the source browsing context for window.open),

This is the crux of the question I'm asking in this bug. I am looking for a concrete example of a case where using the current realm (as opposed to the incumbent global) wouldn't work. This all started when I was writing documentation for this setup in Gecko, and couldn't come up with a good example.

So now we have the counter-example of the source browsing context for window.open. What would break if we made sameOriginWindow.open(...) use |sameOriginWindow| as the source browsing context instead of the browsing context associated with the script doing the call?

The source browsing context is used for all kinds of stuff, in particular figuring out if a sandboxed browsing context can follow the link, managing reentrant unloads, and dealing with subtle origin issues (e.g. with javascript: execution).

I'm not really seeing a path forward here. I suggest we reconsider this once we've done the environment settings object stuff though, since that'll affect fetch et al.

(Sorry for the terrible delay here).

(In reply to Ian 'Hixie' Hickson from comment #32)
> The source browsing context is used for all kinds of stuff

Right. And I'm looking for a case where deriving the source browsing context from the current realm breaks.

It seems very likely that we need a separate concept for the incumbent _somewhere_ here, but I'd like to find the clearest and most understandable example of why we need it so that I can add it to our docs.

> in particular
> figuring out if a sandboxed browsing context can follow the link

Ok. So this is the case where allow-same-origin is set, allow-scripts is not set, and we want to distinguish between: <a href="http://forbidden.com" target="_self"> and a scripted .href set by a same-origin frame?

> managing reentrant unloads

I don't follow this. Can you clarify or link me to the right part of the spec?

> and dealing with subtle origin issues (e.g. with javascript: execution).

You mean the case where a cross-origin frame tries to navigate a browsing context to a javascript: uri? With the new cross-origin system, the current realm would do the right thing, right?

https://html.spec.whatwg.org/multipage/webappapis.html#incumbent-settings-object now discourages use of the incumbent settings object in new specs and points here. This bug suggests to use the current Realm instead (https://tc39.github.io/ecma262/#realm), but it takes a lot of standardese to get from a Realm to a settings object. I think you have to get the Realm's global object and then use https://html.spec.whatwg.org/multipage/webappapis.html#relevant-settings-object-for-a-global-object. It'd be nice to keep the shortcut wording of "incumbent settings object" even if its meaning uses the Realm.

So, I finally thought of a case where I'm pretty sure we definitely need the incumbent settings object: getting the source browsing context (for referrer etc) during location-object navigations. Otherwise, in the same-origin case, the source browsing context will always be the same as target browsing context, which is observably different in ways that are probably not web-compatible.

So. We're stuck with incumbent. But I still think (as I advocated in [1]) that we should avoid using it in _almost_ everything, since the additional complication in edge-cases is only necessary in the case where we actually need to resolve to a SourceElements, and not just a global object (which is almost never).

Given that, it seems like we should heed comment 35 and create a clear and easy way to refer to the current realm. We should then update the warning in the HTML spec to indicate that the incumbent settings object is not going away, but is almost always the wrong thing.

[1] https://github.com/annevk/html-cross-origin-objects/issues/8#issuecomment-170689158

Anne/Domenic, does this sound like a good plan?

That sounds reasonable. We should probably introduce "current settings object" to refer to the settings object of the global associated with ECMAScript's "the current Realm" that folks can then use in specifications.

Or maybe merge settings objects and Realms somehow since I think they're always 1:1.

Yeah, entry Foo, incumbent Foo, and current Foo sounds like the most understandable terminology, for some value of Foo.

Is there anything in the settings object definition that still requires a SourceElements, or is it basically all just stuff that hangs off the global at this point?

So, see also https://github.com/whatwg/html/issues/473. I tried to change the entry/incumbent settings objects to depend on the current ES execution context, but kind of screwed it up and that issue is discussing how to fix what I did. But, the intention of that change was to remove the dependency on SourceElements, and we should be able to retain that going forward.

Regarding merging realm and settings object and global object. I think they are 1:1:1. We should for now keep them as separate concepts, but probably should define {entry,incumbent,current} {Realm,settings object,global object} all together.

At some point we should evaluate uses of incumbent and entry (see also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27203) and see how low we can get their usage. If we can get it low enough we can add strong warnings, or rename them "legacy entry" and "legacy incumbent" or something.

I figure defining all this is kind of on me, as part of straightening out the bug at https://github.com/whatwg/html/issues/473. But I am happy for help if someone else wants to dive in. And, even after I get the definitions straightened out, I am probably not the best person to audit existing uses.

(In reply to Domenic Denicola from comment #40)
> So, see also https://github.com/whatwg/html/issues/473. I tried to change
> the entry/incumbent settings objects to depend on the current ES execution
> context, but kind of screwed it up and that issue is discussing how to fix
> what I did. But, the intention of that change was to remove the dependency
> on SourceElements, and we should be able to retain that going forward.
> 
> Regarding merging realm and settings object and global object. I think they
> are 1:1:1. We should for now keep them as separate concepts, but probably
> should define {entry,incumbent,current} {Realm,settings object,global
> object} all together.
> 
> At some point we should evaluate uses of incumbent and entry (see also
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27203) and see how low we can
> get their usage. If we can get it low enough we can add strong warnings, or
> rename them "legacy entry" and "legacy incumbent" or something.

The entry global is basically only relevant for legacy reasons. The incumbent might be more objectively necessary, but only for very specific use-cases (the only one I can think of is referrer). So I think we should basically discourage the use of both.

> I figure defining all this is kind of on me, as part of straightening out
> the bug at https://github.com/whatwg/html/issues/473. But I am happy for
> help if someone else wants to dive in. And, even after I get the definitions
> straightened out, I am probably not the best person to audit existing uses.

I'm happy to respond to questions of the form "does this likely need to use entry/incumbent like it does now?", if that helps.

https://github.com/whatwg/html/issues/1430