27204 2014-10-31 08:11:22 +0000 Provide guidance on entry vs incumbent settings objects 2016-06-15 19:28:43 +0000 1 1 1 Unclassified WHATWG Unwelcome unspecified PC All RESOLVED FIXED https://www.w3.org/Bugs/Public/show_bug.cgi?id=26603 P2 normal Unsorted 27203 1 annevk mike arun bobbyholley bobowencode bzbarsky d ian josh mike sideshowbarker+unwelcome oldest_to_newest 114306 0 annevk 2014-10-31 08:11:22 +0000 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. 114309 1 bzbarsky 2014-10-31 08:16:56 +0000 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. 114310 2 annevk 2014-10-31 08:20:05 +0000 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. 114311 3 bobowencode 2014-10-31 08:51:40 +0000 (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 114314 4 bobbyholley 2014-10-31 10:15:37 +0000 (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. 114323 5 bzbarsky 2014-10-31 14:51:23 +0000 > 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. 114324 6 annevk 2014-10-31 14:57:02 +0000 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 114325 7 bzbarsky 2014-10-31 15:13:26 +0000 > 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". :( 114328 8 bzbarsky 2014-10-31 15:24:48 +0000 > 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. 114373 9 annevk 2014-10-31 17:48:04 +0000 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. 114389 10 annevk 2014-10-31 18:20:24 +0000 Bug 24652 is the IDL bug on defining the associated Realm. 114469 11 ian 2014-11-04 00:44:16 +0000 If this is asking for spec writing guidance, shouldn't that be in the wiki? 114472 12 annevk 2014-11-04 08:23:05 +0000 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. 115074 13 arun 2014-11-18 21:00:00 +0000 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. 117258 14 ian 2015-01-15 23:42:23 +0000 I'm all for people writing spec writing advice, guides, wiki pages, and so on. I don't have the bandwidth to do it. 126781 15 d 2016-06-15 19:28:43 +0000 I believe this is taken care of by https://html.spec.whatwg.org/multipage/webappapis.html#realms-settings-objects-global-object