Minimize usage of the entry concept

[domenic]

This is a tracking bug, both for HTML and for the wider web ecosystem, to see if we can minimize the number of places that use the entry global/settings object/realm. Originally this was https://www.w3.org/Bugs/Public/show_bug.cgi?id=27203.

Here is our HTML checklist:

• XMLDocument's load() URL parsing [Remove XMLDocument.prototype.load #1478]
• Setting the request client for downloading a hyperlink
• Origin-clean checking for canvas image sources [Remove image/media origins and check origin-cleanness directly #6656]
• Origin-clean setting for canvas font drawing [Remove unnecessary and unimplemented canvas tainting when painting text #1549]
• frameElement same-origin checks [Change a variety of entry settings object uses #1541]
• window.open()
  • https://url-parsing-entry-iaqyojravh.now.sh/entry/entry.html shows this uses entry in all browsers; unlikely to be able to change this
• URL parsing and origin-checking in pushState/replaceState [Use relevant settings object for pushState/replaceState URL parsing #1479, Change a variety of entry settings object uses #1541]
• Origin-checking in the Location object
• Origin-checking in document.open()
• URL parsing and origin-checking for registerProtocol/ContentHandler [Change a variety of entry settings object uses #1541]
• Origin-clean setting for ImageBitmaps [Remove image/media origins and check origin-cleanness directly #6656]
• Establishing a WebSocket connection [Remove entry settings object usage in the WebSocket constructor #6655]
• Origin-checking in postMessage [Which origins to use in postMessage? #1542, Use only the incumbent global in postMessage #1573]
• URL parsing in the Worker constructor (see also SharedWorker) [Use current instead of incumbent + entry in worker constructors #1472]
• Error reporting plans to start using entry!? Clarify "report an exception" #958

Fetch:

• Request constructor URL window association and URL parsing [https://github.com/Stop using entry settings object fetch#367]
• Response constructor HTTP state propagation [https://github.com/Stop using entry settings object fetch#367]
• Response.redirect URL parsing [https://github.com/Stop using entry settings object fetch#367]

Service Worker:

• register URL parsing [https://github.com/Parse URLs relative to the relevant settings object, not entry w3c/ServiceWorker#963]
• getRegistration URL parsing [https://github.com/Parse URLs relative to the relevant settings object, not entry w3c/ServiceWorker#963]
• navigate URL parsing [https://github.com/Tidy up global object usage w3c/ServiceWorker#950]
• openWindow URL parsing [https://github.com/Tidy up global object usage w3c/ServiceWorker#950]
• registerForeignFetch URL parsing [https://github.com/Tidy up global object usage w3c/ServiceWorker#950]
• Start Register URL parsing [https://github.com/Parse URLs relative to the relevant settings object, not entry w3c/ServiceWorker#963]

XHR (whatwg/xhr#98):

• xhr.timeout attribute Window check
• xhr.responseType Window check
• xhr.open() Window check

Notifications (whatwg/notifications#86):

• a newly-created notification's origin and API base URL
• permission getter
• requestPermission origin permission association
• getNotifications origin permission association

If you have other specs that use the entry concept, comment here and I will update the OP.

[domenic]

I've investigated most of the "easy" ones. Many of the rest have to do with origin checks.

@bzbarsky @bholley @annevk, would you be able to help check my logic on the origin check things? window.frameElement is a representative and simple example. It says

If container's node document's origin is not same origin-domain with the entry settings object's origin, then return null and abort these steps.

My usual trick of setting up something a test similar to https://html.spec.whatwg.org/multipage/webappapis.html#realms-settings-objects-global-objects does not work because I can't call frames[0].hello() cross-origin.

My tentative conclusion is that in cross-origin situations all four must always be same-origin, and thus interchangeable for origin checks.

• When testing something not in the whitelist of cross-origin-accessible properties (for example, window.frameElement or document.open or ImageBitmap), entry, incumbent, current, and relevant must all be same-origin. Entry and incumbent because otherwise you can't call incumbent's frames[0].hello() from entry. Incumbent and current since otherwise incumbent couldn't access current.frameElement or current.document.open or current.ImageBitmap. And current and relevant since otherwise "perform a security check" will immediately fail.
• When testing something on the whitelist (postMessage, location stuff), entry must be same-origin with incumbent because otherwise you can't call incumbent's frames[0].hello(). Incumbent and current since anything on the whitelist creates an origin-appropriate representation. And current and relevant since otherwise "perform a security check" will immediately fail.

Does this seem correct? I'm not so sure on the incumbent ~ entry correspondence, but the other correspondences seem right.

If that's correct we can just replace them all with current or relevant, which is nice.

[bholley]

In general a lot of these differences are observable in the non-revoking document.domain case. However, since Gecko revokes on document.domain, it is unlikely that much/anything on the Web would depend on the behavior there.

[bzbarsky]

My tentative conclusion is that in cross-origin situations all four must always be same-origin

No, they must be same-effective-script-origin, generally (ignoring cross-origin-accessible stuff like window.postMessage). That's not the same as same-origin. And as Bobby says, they may not even be same-effective-script-origin in the revoking document.domain case.

[domenic]

Hmm. Would anyone be able to help me by outlining how to make a test for, say, window.frameElement that distinguishes these different cases? I guess we'd want to create a setup where incumbent, entry, relevant, and current are all different-origin (but are same-effective-script-origin), and I'm not sure how to do that.

[bzbarsky]

You serve some of your stuff from foo.bar.com and some from baz.bar.com and set document.domain in both to "bar.com".

[domenic]

OK. Can someone check that I set up this test right? https://frame-element-entry-feolpgggwv.now.sh/, with source at https://github.com/domenic/browser-quirk-tests/tree/master/frame-element with a subfolder for each origin.

I believe what this shows is that frameElement does in fact depend on the entry settings object. I have made the current, relevant, and incumbent pages all document.domain themselves to have now.sh as their origin's domain. I have left entry to have an origin of https://frame-element-entry-feolpgggwv.now.sh/. Clicking on the test button then produces a security error, presumably according to the spec's

If container's node document's origin is not same origin-domain with the entry settings object's origin, then return null and abort these steps.

In this case container's node document should be that of the incumbent global.

(This occurs in Firefox, Edge, and Chrome.)

This is a bit surprising to me, since previously @bzbarsky indicated that he thought that frameElement was probably wrong in using entry, and I wasn't able to find a trace of entry usage in Chrome's implementation. (In fact, what I was able to find seems at least to suggest it's checking current, not entry. But V8 has known issues with creating cross-frame property descriptors...)

So it seems quite possible I've made a mistake in my setup. Could anyone take some time to confirm my findings? I can't figure out any way that this security error would consistently occur, given that everything except entry is same origin-domain, unless entry were involved in the security check.

[bzbarsky]

Clicking on the test button then produces a security error

You're seeing a security error because when the test case does frames[0].test (note we're just doing the Get() so far, not even the call) we end up in https://html.spec.whatwg.org/#windowproxy-getownproperty which tests false in step 3 because the thing inside the iframe set document.domain but the thing outside did not. We then go to https://html.spec.whatwg.org/#crossorigingetownpropertyhelper-(-o,-p-) and "test" is not in the list at https://html.spec.whatwg.org/#crossoriginproperties-(-o-) so we return undefined. Back in https://html.spec.whatwg.org/#windowproxy-getownproperty we have undefined in step 5, go on to step 6, "test" is not a child browsing context name, we go to step 7 and throw a SecurityError. The "test" function is never called, nor is the frameElement getter.

The actual exception message in the SecurityError does make this somewhat clearer in Firefox than in Chrome:

Permission denied to access property "test"

[domenic]

With #6655 and #6656 we almost have the spec matching the cases I see in Chromium codesearch, i.e. Location, document.open()/document.write(), and window.open().

What remains is the spec uses the entry settings object for hyperlink downloading, which needs to be rebased on top of navigation in general.