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 > -- 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/38ac91fd-331c-4f43-973a-441a462e29e4n%40chromium.org.
