[webkit-dev] Request for position on import.meta.resolve()
Hi webkit-dev, We're proposing a small additional function to add to the HTML Standard, named import.meta.resolve(). See the PR [1] and a mini-explainer [2]. Gecko folks have reviewed the PR and contributed to the discussion, but any thoughts from WebKit would be very welcome. We're hoping to ship in Chrome within the next few weeks, and I imagine web developers would love it if you were to also implement. We have a basic implementation and web platform tests you may find useful [3]. Thanks, Domenic [1]: https://github.com/whatwg/html/pull/5572 [2]: https://gist.github.com/domenic/f2a0a9cb62d499bcc4d12aebd1c255ab [3]: https://chromium-review.googlesource.com/c/chromium/src/+/3456729 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for position on app history API
Hi webkit-dev, The Chrome team, with some help from Mozilla folks, have been working on a proposal for a new history/navigation API aimed specifically at the needs of single-page apps. The current name is the "app history API". You can see the explainer at [1] (and the name bikeshedding thread at [2] ). So far the API has a lot of web developer enthusiasm and engagement on the issue tracker, including a polyfill [3]. We've been prototyping behind a flag in Chromium and are planning to go to origin trial soon, as we have some large sites that want to try conditionally switching out their current router code for code based on app history to see if this brings about the desired simplifications or shakes out any bugs. We also have a lot of web platform tests [4] and a mostly-complete but definitely still WIP spec [5]. We'd love to get your thoughts, whether they're a general appraisal or a more in-depth dive into the API choices and spec. I'm hopeful we can together make developers really happy with a new API for this historically-tricky problem space. Other links you may enjoy are the Mozilla standards positions issue [6] and the initial W3C TAG design review [7]. Thanks so much for your time, -Domenic [1]: https://github.com/WICG/app-history [2]: https://github.com/WICG/app-history/issues/83 [3]: https://github.com/frehner/appHistory [4]: https://github.com/web-platform-tests/wpt/tree/master/app-history [5]: https://wicg.github.io/app-history/ [6]: https://github.com/mozilla/standards-positions/issues/543 [7]: https://github.com/w3ctag/design-reviews/issues/605 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for position on self.reportError()
Hi webkit-dev, We recently added a small utility function, self.reportError(), to the HTML Standard [1]. It is pretty simple and just lets developers appropriately send errors to the "error" event handler and the console, like what happens when the browser reports uncaught exceptions. This is already implemented in Firefox and we're looking to ship it in Chrome soon. Would you all be interested this feature as well? It should be pretty simple to implement; it was for us at least. [2] Thanks, -Domenic [1]: https://github.com/whatwg/html/pull/1196 [2]: https://chromium-review.googlesource.com/c/chromium/src/+/3125854 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for position on the Origin-Isolation header
Hi again webkit-dev, I'm just pinging this thread to let you know that in the HTML Standard repository (and Chrome implementation), we're working to rename this feature from "origin isolation" to "origin-keyed agent clusters", with the header going from Origin-Isolation to Origin-Agent-Cluster. This is due to people thinking that the "origin isolation" name implied security guarantees, like Chrome's "site isolation" term or the HTML Standard's "cross-origin isolation" term. You can read more about the reasoning at https://github.com/whatwg/html/issues/6192 and see the renaming pull request at https://github.com/whatwg/html/pull/6214. Thanks! -Domenic ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for position on import maps
Thanks for your response Ryosuke! From: Ryosuke Niwa > How does this feature supposed to work with CSP subresource integrity? >As far as I've read various specs and the proposal, it's not currently >possible to specify any integrity checks on modules loaded via import this. >This is a pretty serious downside because it would mean that any remote server >ever referenced by an import map becomes a security liability for a given >website. It's a lot worse compared to normal scripts > because of the >action-at-a-distance of import maps. There is no indication that a given >module import could involve access to cross-origin servers isn't obvious from >where the import statement appears. Correct, this proposal does not change the status quo regarding models and CSP integrity integration. I can understand how import maps might increase the priority of improving CSP in that way for WebKit, and I imagine the webappsec group would welcome any collaboration on solving that. There are even proposals from community members to piggyback on the import map's
[webkit-dev] Request for position on import maps
Hello webkit-dev, For the last couple of years myself some other Chrome folks have been working on the import maps proposal. This allows controlling the behavior of JavaScript import statements and import() expressions, in particular by allowing the page to customize the translation of the module specifiers used there into URLs. Developer reception of the feature has been very positive, with continual prompting for when it'll be widely available in more browsers, and a plethora of community-created tools and polyfills. Chrome is working toward shipping this in an imminent release, and we'd love any thoughts or contributions from the WebKit community. Relevant links: * Explainer: https://github.com/WICG/import-maps/blob/master/README.md * Spec (would eventually merge into HTML upon multi-implementer interest): https://wicg.github.io/import-maps/ * Test suite: https://github.com/web-platform-tests/wpt/tree/master/import-maps/ (although getting rearranged a good bit in https://github.com/web-platform-tests/wpt/pull/26239 ) * Mozilla standards position discussion, with lots of web developers contributing: https://github.com/mozilla/standards-positions/issues/146 * Some gathered evidence of developer interest: https://github.com/WICG/import-maps#community-polyfills-and-tooling Thanks for your time! -Domenic ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Request for position on the Origin-Isolation header
Thanks Ryosuke! From: Anne van Kesteren > On Fri, Aug 21, 2020 at 2:41 AM Ryosuke Niwa wrote: >> I feel like I saw some discussions of also differentiating based on >> protocol (treating http://webkit.org and https://webkit.org >> differently). Do you know you've already had such a discussion and if >> so what the outcome of that discussion was? > > The scheme is already part of an origin so that is definitely a boundary for > this feature. However, I guess you're asking about the "normal" website > security boundary, which is site (roughly scheme + registrable domain, exact > definition in HTML). Site historically lacked scheme, but that was changed. > There are still some features (primarily cookies) that compare sites and > ignore the scheme (this operation is also defined in HTML), but those too > have proposals to move away from that. In addition to this, I'll note that the feature is currently specced to only work on secure contexts; on non-secure contexts the header is ignored. So, non-secure pages will always end up in the site-keyed agent cluster, i.e. there is no way to use this header to isolate http://example.com from http://sub.example.com/ like you can do for the https: counterparts. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Request for position on the Origin-Isolation header
Hello webkit-dev, I've been working on a new header called Origin-Isolation, which is a way of allowing origins to opt-out of using document.domain and cross-origin sharing of WebAssembly.Module, and thus allowing the browser to put them into an origin-keyed agent cluster instead of a site-keyed one. This could in turn allow the browser to make better behind-the-scenes decisions for process isolation, or other resource allocation decisions, since sites no longer have any ways to synchronously communicate cross-origin. Relevant links: * Explainer: https://github.com/WICG/origin-isolation * HTML spec PR: https://github.com/whatwg/html/pull/5545 * Test suite: https://github.com/web-platform-tests/wpt/tree/master/origin-isolation * Gecko "worth prototyping" standards position: https://mozilla.github.io/standards-positions/#domenic-origin-isolation A natural question one might ask is how this relates to COOP+COEP? The explainer has that covered: https://github.com/WICG/origin-isolation#coop--coep Thanks for your time! -Domenic ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
