-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Minimize usage of the entry concept #1431
Comments
As shown by https://settings-object-worker-client-abibrisfdk.now.sh, all browsers use the current settings object for the fetch client, i.e. the "outside settings", instead of the incumbent settings object. (Except we do not know the result in Edge, since they don't seem to send a Referer header for us to inspect.) Part of #1430. As shown by https://settings-object-worker-client-wellwosyqf.now.sh/entry/entry.html, all browsers also use the current settings object for URL resolution, instead of the entry settings object. Part of #1431.
Tested by https://url-parsing-entry-iaqyojravh.now.sh/entry/entry.html; all browsers use relevant, instead of entry, at least for URL parsing. Further testing is needed for the origin checks. Part of #1431.
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?
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 My tentative conclusion is that in cross-origin situations all four must always be same-origin, and thus interchangeable for origin checks.
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. |
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. |
As shown by https://settings-object-worker-client-abibrisfdk.now.sh, all browsers use the current settings object for the fetch client, i.e. the "outside settings", instead of the incumbent settings object. (Except we do not know the result in Edge, since they don't seem to send a Referer header for us to inspect.) Part of #1430. As shown by https://settings-object-worker-client-wellwosyqf.now.sh/entry/entry.html, all browsers also use the current settings object for URL resolution, instead of the entry settings object. Part of #1431.
Tested by https://url-parsing-entry-iaqyojravh.now.sh/entry/entry.html; all browsers use relevant, instead of entry, at least for URL parsing. Further testing is needed for the origin checks. Part of #1431.
No, they must be same-effective-script-origin, generally (ignoring cross-origin-accessible stuff like |
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. |
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". |
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
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. |
You're seeing a security error because when the test case does The actual exception message in the SecurityError does make this somewhat clearer in Firefox than in Chrome:
|
Since this is a same origin-domain check, we can use any settings object, as they are all same origin-domain. Part of #1431.
This updates the origin check in pushState/replaceState to use the origin of the document of the relevant History object, instead of that of the entry settings object. This more correctly matches 2/3 open source browsers: - https://chromium.googlesource.com/chromium/src/+/c21f0b11ac83ea970d0eaf6a0b223d48a32a4b32/third_party/WebKit/Source/core/frame/History.cpp#234 - https://github.com/WebKit/webkit/blob/0ee7b606dbf35d9688c15b19b1a83ec1ff242cd7/Source/WebCore/page/History.cpp#L150 (Gecko does no such security check). It also helps with #1431. While there, cleaned up some redundant steps and tightened wording.
The test at https://url-parsing-entry-gjqursujea.now.sh/entry/entry.html reveals that Firefox at least uses relevant for URL parsing. Boris says that Firefox does something nonsensical for the origin check and that he would prefer relevant or current. Code inspection reveals that Blink and WebKit use relevant for both URL parsing and origin checking: - https://chromium.googlesource.com/chromium/src/+/ee94bde91c72a046bec15436d56cfe32bb0e524c/third_party/WebKit/Source/modules/navigatorcontentutils/NavigatorContentUtils.cpp#71 - https://github.com/WebKit/webkit/blob/83624b838d4fa81df77060c51b09587169f8ff19/Source/WebCore/Modules/navigatorcontentutils/NavigatorContentUtils.cpp#L109 Edge does not support these methods. Helps with #1431.
Since this is a same origin-domain check, we can use any settings object, as they are all same origin-domain. Part of #1431.
Hopefully this will help discourage people from using them. Also remove "entry global object" as it seemed to be unused. See whatwg#1430/whatwg#1431
As shown by https://settings-object-worker-client-abibrisfdk.now.sh, all browsers use the current settings object for the fetch client, i.e. the "outside settings", instead of the incumbent settings object. (Except we do not know the result in Edge, since they don't seem to send a Referer header for us to inspect.) Part of whatwg#1430. As shown by https://settings-object-worker-client-wellwosyqf.now.sh/entry/entry.html, all browsers also use the current settings object for URL resolution, instead of the entry settings object. Part of whatwg#1431.
Tested by https://url-parsing-entry-iaqyojravh.now.sh/entry/entry.html; all browsers use relevant, instead of entry, at least for URL parsing. Further testing is needed for the origin checks. Part of whatwg#1431.
As discussed in whatwg#1540, this check does not give any additional protections over those already provided by CORS, which these days fonts are subject to. Fixes whatwg#1540. Helps with whatwg#1431.
Since this is a same origin-domain check, we can use any settings object, as they are all same origin-domain. Part of whatwg#1431.
This updates the origin check in pushState/replaceState to use the origin of the document of the relevant History object, instead of that of the entry settings object. This more correctly matches 2/3 open source browsers: - https://chromium.googlesource.com/chromium/src/+/c21f0b11ac83ea970d0eaf6a0b223d48a32a4b32/third_party/WebKit/Source/core/frame/History.cpp#234 - https://github.com/WebKit/webkit/blob/0ee7b606dbf35d9688c15b19b1a83ec1ff242cd7/Source/WebCore/page/History.cpp#L150 (Gecko does no such security check). It also helps with whatwg#1431. While there, cleaned up some redundant steps and tightened wording.
The test at https://url-parsing-entry-gjqursujea.now.sh/entry/entry.html reveals that Firefox at least uses relevant for URL parsing. Boris says that Firefox does something nonsensical for the origin check and that he would prefer relevant or current. Code inspection reveals that Blink and WebKit use relevant for both URL parsing and origin checking: - https://chromium.googlesource.com/chromium/src/+/ee94bde91c72a046bec15436d56cfe32bb0e524c/third_party/WebKit/Source/modules/navigatorcontentutils/NavigatorContentUtils.cpp#71 - https://github.com/WebKit/webkit/blob/83624b838d4fa81df77060c51b09587169f8ff19/Source/WebCore/Modules/navigatorcontentutils/NavigatorContentUtils.cpp#L109 Edge does not support these methods. Helps with whatwg#1431.
Previously one of the origin checks was performed with the entry settings object, while the origin and source attributes of the resulting MessageEvent were derived from the incumbent settings object. At least WebKit and Blink appear to use the same global for both, and it makes sense to align the checks on the same global. The difference is only observable in test cases that fiddle with document.domain, as entry and incumbent are always same origin-domain (but, in document.domain cases, not always same origin). Fixes whatwg#1542. Helps whatwg#1431 but hurts whatwg#1430.
Fixes whatwg#2116, wherein it is documented that this restriction is not supported in any existing engines and attempting to do so in WebKit proved not web-compatible. Also helps with whatwg#1431.
This matches implementations, and helps with #1431. Also, slightly modernize the algorithm.
That is, check the type of response directly, instead of synthesizing an opaque origin for opaque responses and then comparing that to the entry settings object's origin. This helps with #1431 by removing various uses of the entry concept, and closes #2761 by removing the origin concept for image and media elements entirely, since it is now unused.
With #6655 and #6656 we almost have the spec matching the cases I see in Chromium codesearch, i.e. What remains is the spec uses the entry settings object for hyperlink downloading, which needs to be rebased on top of navigation in general. |
That is, check the type of response directly, instead of synthesizing an opaque origin for opaque responses and then comparing that to the entry settings object's origin. Closes #2813. Helps with #1431 by removing various uses of the entry concept, and closes #2761 by removing the origin concept for image and media elements entirely, since it is now unused.
This matches implementations, and helps with #1431. Also, slightly modernize the algorithm.
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:
Fetch:
Service Worker:
XHR (whatwg/xhr#98):
Notifications (whatwg/notifications#86):
If you have other specs that use the entry concept, comment here and I will update the OP.
The text was updated successfully, but these errors were encountered: