This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
1) You should not use the effective script origin. 2) You should not use the incumbent settings object. 3) You should use the entry settings object's origin.
Why, exactly?
I take it you're questioning 2, not 1? I thought most APIs use the entry settings object and we had incumbent for certain legacy uses.
The entry settings object is a bizarro action-at-a-distance thing that is used for legacy things like base URIs, but shouldn't, in my opinion, be used for any security information ever. The incumbent settings object or the Realm of the callee function are both reasonable options for security stuff.
What is legacy about a base URL? HTML uses the entry settings object for a bunch of origin checks upon cursory reading. It also says "It is used in some security checks." about the incumbent settings object which does not inspire much confidence. However, if that's wrong I'm happy to file bugs.
> What is legacy about a base URL? The insane way it's computed for things like setting location.href. And then we wanted to be consistent with that elsewhere, so we have the same insane base URL computation scheme everywhere. > HTML uses the entry settings object for a bunch of origin checks I thing HTML is buggy if it's doing that. I just looked, and it looks like it does it for the following (I'm ignoring things like referrers and base URIs and whatnot, just looking at origins): 1) Canvas tainting bits. Does this actually match implementations? Does it make sense to do it that way? 2) .frameElement, looking at effective script origins. This is not too unreasonable, since effective script origins end up needing to match the effective script origins of everything else you're dealing with, pretty much, so it doesn't matter too much which settings object you use here. At least in browsers that implement security membranes (which of course doesn't match the HTML spec, but I consider that a bug in the HTML spec). 3) A check in replaceState which I'm totally unclear on. It claims to restrict sandboxed content, but there's nothing to indicate that the entry settings will be the sandboxed thing! 4) Location security checks. That stuff is all broken as written up right now; see bug 20701. 5) Origin check in registerProtocolHandler. Again, it's not clear to me why using the origin of the entry settings object is the right thing here. I don't think it is. 6) Something in IsSearchProviderInstalled. 7) createImageBitmap. This is similar to canvas tainting. Except ignores CORS? 8) For EventSource, setting the origin for CORS purposes to that of the entry settings object. That makes no sense to me. 9) For websocket, checking the scheme of the origin of the entry settings object, and using its origin in the websocket connection. 10) A sanity check that all origins match in postMessage. This part is not too unreasonable. Note that really the only case in which it matters which exact settings object's origin you use are document.domain cases (because otherwise the entry and incumbent settings objects have to match, and both must match the Realm of the caller, modulo whatever weirdness happens with Location). So it's no surprise that this stuff is not exactly well-tested, and probably not that well-thought-about.
Filed bug 27203, bug 27204, and bug 27205 to get HTML improved here. Should probably also review other specifications as I think there's quite a few that use the entry settings object for everything.
We're migrating W3C bugs to GitHub issues; this one is https://github.com/w3c/FileAPI/issues/20