Repository navigation
Minimize usage of the entry concept #1431
Description
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):
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.
Activity
Use current instead of incumbent + entry in worker constructors
Use relevant settings object for pushState/replaceState URL parsing
domenic commentedon Jun 30, 2016
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.frameElementis a representative and simple example. It saysMy 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.
frames[0].hello()from entry. Incumbent and current since otherwise incumbent couldn't accesscurrent.frameElementorcurrent.document.openorcurrent.ImageBitmap. And current and relevant since otherwise "perform a security check" will immediately fail.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 commentedon Jul 1, 2016
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.
Use current instead of incumbent + entry in worker constructors
Use relevant settings object for pushState/replaceState URL parsing
bzbarsky commentedon Jul 7, 2016
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 commentedon Jul 7, 2016
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 commentedon Jul 7, 2016
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 commentedon Jul 8, 2016
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.domainthemselves to havenow.shas their origin's domain. I have left entry to have an origin ofhttps://frame-element-entry-feolpgggwv.now.sh/. Clicking on the test button then produces a security error, presumably according to the spec'sIn 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 commentedon Jul 8, 2016
You're seeing a security error because when the test case does
frames[0].test(note we're just doing theGet()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 setdocument.domainbut 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 theframeElementgetter.The actual exception message in the SecurityError does make this somewhat clearer in Firefox than in Chrome:
13 remaining items
Allow <a>/<area> with download="" to not require user activation
Editorial: Include "legacy" in the name of entry and incumbent
Use current instead of incumbent + entry in worker constructors
Use relevant settings object for pushState/replaceState URL parsing
Remove unnecessary and unimplemented canvas tainting when painting text
Use "current settings object" in the frameElement origin check
Use the associated document for pushState/replaceState's origin check
Use relevant settings object in protocol handlers
Use only the incumbent global in postMessage
Allow <a>/<area> with download="" to not require user activation
Remove entry settings object usage in the WebSocket constructor
Remove image/media origins and check origin-cleanness directly
domenic commentedon May 5, 2021
With #6655 and #6656 we almost have the spec matching the cases I see in Chromium codesearch, i.e.
Location,document.open()/document.write(), andwindow.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.
Remove image/media origins and check origin-cleanness directly
Remove entry settings object usage in the WebSocket constructor