It's not clear that we want to use incumbent for origin checks, except when operating on cross-origin Window and Location, which are their own special kettle of fish.  I think we should seriously think about using the current Realm for origin checks in normal cases.

So there's three set of objects in play? Entry, incumbent, and current Realm? Current Realm seems fine, but that would require some kind of IDL hook, right? And again, people will need guidance as this is hard.

(In reply to Anne from comment #0)
> According to bz for anything new we should use incumbent for origin checks
> and entry for base URL and Referrer. It might be good to stipulate that
> clearly.

For navigation, I think the referrer is generally supposed to come from the Source Browsing Context, see [1].
This can be a variety of things, including coming from the incumbent settings object.
I'm not sure it is ever specified as coming from the entry settings object, although it could of course end up being the same thing.

[1] https://html.spec.whatwg.org/multipage/infrastructure.html#processing-model

(In reply to Boris Zbarsky from comment #1)
> It's not clear that we want to use incumbent for origin checks

Agreed. See bug 26603.

> except when
> operating on cross-origin Window and Location, which are their own special
> kettle of fish.

Yeah. And even for that it's not really using the origin for a security check per se, but rather for determining the "Caller-Appropriate Cross-Origin Representation" of the various methods and accessors. See the current draft of the spec for this stuff: https://etherpad.mozilla.org/html5-cross-origin-objects

> I think we should seriously think about using the current
> Realm for origin checks in normal cases.

Definitely.

> So there's three set of objects in play? Entry, incumbent, and current Realm? 

Yes.

> but that would require some kind of IDL hook, right?

That's a good question.

Per ES, every function object (and this includes the getters/setters/methods IDL generates) has an associated Realm and that Realm becomes the current Realm when the function is called.

We may need a mechanism to go from a Realm to a settings object or an origin, but that doesn't seem like an IDL thing.  Rather, that seems like something that's part of the prose defining a global object, right?

> And again, people will need guidance as this is hard.

Yes, I agree.

The IDL hook is needed for the prose written in specifications as that typically does not deal with the JavaScript environment (nor theoretically has access to it I suppose). Currently it can use "entry settings object" or "incumbent settings object". And XMLHttpRequest uses something different again: https://xhr.spec.whatwg.org/#dom-xmlhttprequest

> nor theoretically has access to it I suppose

That's flat-out impossible, because it needs to be able to create JS objects like typed arrays and promises.  IDL describes how to do the type conversions, but all it does is "return the same object".  _Creating_ the thing requires access to a JS global environment.

Right now specs sweep this under the hood, which is actually pretty confusing, because it doesn't make it clear which JS global environment is getting used.  I'm 99% sure this leads to observable behavior differences between browsers in edge cases (some of which may be somewhat covered up by IDL instanceof operating on cross-global objects).  Just like the failure of most specs to specify which global environment their 

If we want to have the polite fiction that IDL is language-agnostic, we need to seriously rework how these objects work in IDL.

One other note.  IDL defines a "perform a security check" operation, or rather a hook for performing such a check that gets passed the things to check against each other.  This explicitly uses the current Realm to get the global and then passes that to "perform a security check".  See <http://heycam.github.io/webidl/#es-security>.  Sadly, HTML doesn't actually define what it means to "perform a security check".  :(

> I'm 99% sure this leads to observable behavior differences

For example, try https://web.mit.edu/bzbarsky/www/testcases/global-object-association/webcrypto-parent.html in Firefox and Chrome.

> we need to seriously rework how these objects work in IDL.

Or at least provide IDL hooks for creating Promise and typed array objects... and decide whether these hooks use some implicit global (which one?) or have to be handed an explicit global, together with a hook for getting the current realm global or something.

Filed bug 27212 on HTML to define that security check.

I would be happy for IDL to remove the language agnostic stuff and just be JavaScript.

Bug 24652 is the IDL bug on defining the associated Realm.

If this is asking for spec writing guidance, shouldn't that be in the wiki?

I don't know. In my experience people write specs the same way they write code. By copy and pasting others and then changing the bits they don't like until it looks "reasonable". This argues for some short clarifying notes if concepts are particularly tricky.

Something like this: http://www.w3.org/2001/tag/doc/promises-guide

would be good, but applied to Realm as well, as mentioned in Bug 26603.

Currently, Blob URLs use this to define origin.

I'm all for people writing spec writing advice, guides, wiki pages, and so on. I don't have the bandwidth to do it.

I believe this is taken care of by https://html.spec.whatwg.org/multipage/webappapis.html#realms-settings-objects-global-object