It's in the environment settings object, no?

Boris, Hixie is right, origin is part of the environment settings object. Which at the moment is always 1:1 with a global object. I guess the question is what happens with new Realm(), but maybe we should revisit at that point.

OK.  So can we define "the origin of global X" to be "the origin stored in the environment settings object corresponding to global X"?  Because pretty much no spec writer will think to write the latter....

We could, but if those spec writers haven't read enough to understand the basics of the Web's security model (such as where the origin is defined) then shouldn't we have much bigger worries?

The reason the origin is on the environment settings object is that a particular environment settings object can actually have two different global objects (the document.open() case). Doing things based on the global isn't a good idea IMHO as it has very subtle implications.

> but if those spec writers haven't read enough to understand the basics of the
> Web's security model

We have problems like that, sure.  But even people who _have_ read it are not likely to remember "the origin stored in the environment settings object corresponding to global X".  Whereas remembering "the origin of global X" is much more straightforward, happens to match how at least the UAs I'm aware of implement this better, and is generally clearer all around.  Just a matter of ergonomics.

> The reason the origin is on the environment settings object is that a
> particular environment settings object can actually have two different global
> objects (the document.open() case)

Sure.  But in that case, the "origin of the global" makes perfect sense; both globals share it, right?  If we had the _reverse_ situation, where a single global could have multiple environment settings objects, that would be a bigger issue.

> Doing things based on the global isn't a good idea IMHO

What do implementations do, I wonder, and is it detectable?  Presumably it's only detectable via some combination of document.domain and document.open() and then seeing which objects have which effective script origin associated with them or something?

One other thing.  Just to be clear, "the Web's security model" as it applies to whether origins are associated with globals or settigs objects may or may not mean anything, since historically the web has had no concept of settings objects, so it's more or less a specification device to explain something.  What I'm trying to understand is, for the document.open case, what behavior UAs have right now prompted this particular specification device.

The settings objects originated as part of speccing the "incumbent script" stack, IIRC.

Anyway, I guess it's fine for us to add some prose somewhere saying that when specs refer to the origin of a global, they really mean the origin of the global's environment settings object. It just seems a bit annoying to have all this indirection everywhere. I think it'd be better to submit feedback to the relevant specs to have them fixed.

I disagree about the cost/benefit analysis here.  It's better to have one single indirection that rigorously defines a concept everyone intuitively understands anyway than to have lots of specs have language that no one can understand without following a bunch of convoluted language in other specs.

If anyone thinks they "intuitively understand" the security model here, then they almost certainly don't. Thus I think that the current situation, where editors who haven't understood the model end up using language like "origin of the Window", acts as an interesting way to flag specs whose authors haven't fully grokked the security model and whose specs therefore might need even closer scrutiny than normal.

I don't understand how _adding_ a level of indirection can possibly make things simpler to understand. You still have to follow all the links, there's just one more to follow.

I'm not sure what it is you think people don't understand in the security model.  The origin of a Window is pretty clear; the fact that it's stored in the script settings object instead of the Window only matters for the effective script origin, not the origin, yes?  And even then it's not clear to me that the model the spec describes is what UAs do in practice.  I haven't had a chance to write testcases to verify whether it is, but if you have some I'd love to see them.

In any case, unless effective script origins get involved, the fact that the origin lives on the script settings object is a pure specification device which is just unnecessary complication imo.

Effective script origins are always involved. Windows aren't always involved. There's not always a global object (since scripting support is optional). These are just three of the subtleties that I would fear people don't understand if they just refer to "the origin of the global object" despite this not being a defined term currently. We can certainly define the term and paper over this lack of deep understanding. It's just that that would remove this flag we have now, which lets us quickly determine how carefully the spec author has read the specs the spec author is referencing.

> Effective script origins are always involved.

That's just not true.  Various things only examine the origin, not the effective script origin.

> Windows aren't always involved.

Sure.  Except for APIs that are only exposed on Window, of course.  More on this below.

> There's not always a global object (since scripting support is optional).

Hmm.  There's always an object there that acts as the global for scripting purposes when scripting is supported, but ok.

And more importantly, for most cases where people are worrying about origins they're defining an IDL API, and then scripting support not existing simply means their code is unreachable anyway.

> which lets us quickly determine how carefully the spec author has read the
> specs the spec author is referencing

No other spec author has read the HTML spec on this matter, except perhaps Anne.  We don't need a flag to know that.

And since no one is checking this flag anyway, its value is pretty low.  :(

There is a very easy way now to get to a settings object from a platform object (including a global object). It's called "relevant settings object". Things still get a little verbose at times, but it doesn't seem that bad to me.

I think this is pretty good now. Hopefully we'll be able to simplify more going forward.