Thanks for the clarification. Yeah, I think it's up-to each browser, however, it is worth clarifying that extensions in chrome are able to see and operate on subresources in Web Bundles.
See https://bugs.chromium.org/p/chromium/issues/detail?id=1155402 for details. On Wed, Apr 13, 2022 at 5:18 PM Kenji Baheux <[email protected]> wrote: > A quick clarification ✔️ to avoid confusion 😕 or needless agitation 🥵: > > On Wednesday, April 13, 2022 at 12:43:24 PM UTC+9 Hayato Ito wrote: > >> Contact emails:[email protected], [email protected] >> >> >> Explainer: >> >> >> https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading.md >> >> >> Specification: >> >> https://wicg.github.io/webpackage/subresource-loading.html >> >> >> Summary: >> >> Provides a new approach to load a large number of resources efficiently >> using a format that allows multiple resources to be bundled, Web Bundles >> <https://wpack-wg.github.io/bundled-responses/draft-ietf-wpack-bundled-responses.html> >> . >> >> >> Note that the scope of this "Intent to Ship" is only v1, which is >> explained in our long term plan >> <https://github.com/WICG/webpackage/issues/648>. We have been conducting >> the Origin Trial for v1 features >> <https://chromium.googlesource.com/chromium/src/+/refs/heads/main/content/browser/web_package/subresource_loading_origin_trial.md>. >> Given that the outcome is promising, we’d like to ship v1 as MVP in order >> to mitigate the risk of "develop everything and ship them all at once". >> >> >> After shipping v1, we'll explore *v2*, designing and implementing >> missing key features, eg. cache-aware WebBundles. There are several >> proposals, such as Bundle Preloading >> <https://github.com/WICG/bundle-preloading> (discussion >> <https://github.com/WICG/webpackage/issues/699>), Bundle Dependencies >> <https://github.com/WICG/webpackage/blob/main/extensions/proposals/dependencies-section.md>, >> and others. We continue to explore this area to identify a missing Web >> Platform primitive in order to serve large Web Apps in a cache-efficient >> way with Web Bundles. >> >> >> Blink component >> >> Blink>Loader>WebPackaging >> >> >> TAG review: https://github.com/w3ctag/design-reviews/issues/616 >> >> TAG review status: While the status of the review is open, we have >> addressed the concerns raised in the discussion. In particular, we plan to >> explore the designs in v2 as explained above. Additionally, if a concern >> with the extension part >> <https://github.com/WICG/webpackage/blob/main/explainers/subresource-loading-opaque-origin-iframes.md> >> continues to be an issue, we aim to address it in v2 as well. >> >> >> Risks: >> >> Interoperability and Compatibility: >> >> No interoperability and compatibility risk has been identified. This is >> purely a feature addition. A browser which doesn’t support this feature >> should load subresources from the network, as usual. >> >> >> Gecko: No signal (issue >> <https://github.com/mozilla/standards-positions/issues/590>) >> >> WebKit: No signal (ML >> <https://lists.webkit.org/pipermail/webkit-dev/2021-November/032038.html> >> ) >> >> >> Web Developers: >> >> Google Ads (use case <https://github.com/WICG/webpackage/issues/624>) >> (origin trial participant) >> >> > Web bundle serving is a major overhaul of how GPT requests and renders >> ads, built on top of a new browser API which we have been designing with >> the Chrome team. It offers large loading performance improvements and >> security and privacy relative to safeframe rendering: >> >> - >> >> Performance improvements by fetching multiple Ads creatives in a >> single request. >> - >> >> Enhance privacy: Creative contents can no longer be read or modified >> by the publisher or others in the publisher's JS context. Creatives can no >> longer read or modify each other. >> >> > This hardening of read/write access is only meant for code originally > present on the page, not code coming from user extensions. > In other words, *extensions can see and operate* on ads served in this > manner. > In particular, *extensions can still act upstream *of these ads requests > as is typically the case (e.g. directly acting on the scripts that drive > these requests). > > The goal for this particular use case is to improve users’ privacy and > security by preventing non-user controlled/added code from peeking into, or > making malicious changes to, ads that were served by another party, with > better or neutral performance (see the TAG review for more details and > analysis). > > I hope this is clear and useful 🙏🏼 🙇. > > > >> >> Ergonomics >> >> This feature can be used to improve loading performance by fetching >> multiple resources in a single request. If a browser doesn’t support this >> feature, a request should be served from a network as usual. >> >> `HTMLScriptElement.supports("webbundle")` can be used for feature >> detection as well. >> >> There are several tools and plugins >> <https://github.com/WICG/webpackage#web-bundles> available for packaging >> Web Bundles. >> >> >> Security >> >> Received approval for Security and Privacy in our launch bug >> <http://crbug.com/1306701>. We had addressed a security concern for the >> usage of <link> elements. The API now uses <script> elements. We ship only >> <script type=webbundle>. >> >> >> Debuggability >> >> Developers have the ability to test this functionality on their pages by >> opening DevTools and selecting the Network tab. This allows the DevTools to >> represent Web Bundles and the resources that originate from it being >> attributed to the Web Bundle (link >> <https://bugs.chromium.org/p/chromium/issues/detail?id=1182537>). >> >> >> Is this feature fully tested by WPT? >> >> Yes (link >> <https://github.com/web-platform-tests/wpt/tree/master/web-bundle/subresource-loading> >> ). >> >> >> Tracking bug >> >> crbug.com/1082020 >> >> >> Launch bug >> >> crbug.com/1306701 >> >> >> Estimated milestones >> >> M102 >> >> >> Links to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5710618575241216 >> >> >> >> -- >> Hayato >> > -- Hayato -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_10M-CYuWz%2BE__id-e7jey0kA6J-ayF8qy8wdPgzeSZZA%40mail.gmail.com.
