Thanks for the question. Responses inline below. On Tue, Apr 19, 2022 at 6:29 PM Titouan Rigoudy <[email protected]> wrote:
> Hi there, > > Has anything changed between the OT and this launch? > > A good question. No behavior change between the OT and this launch. Thanks! > Cheers, > Titouan > > On Wed, Apr 13, 2022 at 10:39 AM Hayato Ito <[email protected]> wrote: > >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_10M-CYuWz%2BE__id-e7jey0kA6J-ayF8qy8wdPgzeSZZA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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_0WArbeGmpE00vAVzuryDg%3DCLgivM1v7pchct%3DAgSTJWg%40mail.gmail.com.
