Re: [art] Side meeting on Signed Exchanges and Web Packaging

[Yoav Weiss <[e-mail]>]

I'll be there!

To reiterate here comments I've made elsewhere
<https://groups.google.com/a/chromium.org/d/msg/blink-dev/n7cZXSTwBTY/Ham62KVeAgAJ>
: I'm super excited about this work, from multiple perspectives:

<cdn-person-hat>
This feature will enable CDNs to serve origin-signed content from origins
that are not on their network (and which private keys they don't have).
Origins signing their static resources would make those resources available
to be cached anywhere, and sites that use those resources could download
them over their own H2 connections, avoiding connection establishment and
contention costs, without compromising on the resource's integrity.

That should result in significant performance wins when delivering such
resources.
</cdn-person-hat>

<performance-person-hat>
Web packaging (not the Origin Signed part, but the packaging format part
<https://github.com/WICG/webpackage/blob/master/draft-yasskin-dispatch-web-packaging.md>)
can help us solve the problems we have around resource bundling.
Right now there's a clear tradeoff for bundling JS/CSS resources: Larger
bundles provide improved compression ratios, but later execution, as the
entire bundle must be downloaded before execution starts.
Web packaging can help us sidestep that dilemma and deliver all our
(static, non-credentialed) resources in a single compressed bundle, that is
processed in a streaming fashion. No tradeoffs!

Packaging also seems doubly important when we look at ES6 modules that have
to be delivered in their own file. AFAIUI, current bundling processes work
around that by smooshing multiple modules together as part of the bundling
process. Would be great to avoid that need.

Finally, from a caching perspective, web packages are superior to bundles,
as they can enable invalidation of specific resources, where today the
entire bundle gets invalidated.

*Aside:* I was hoping we can fix these issues by extending the protocols
and pushing compression to the h2 layer
<https://github.com/vkrasnov/h2-compression-dictionaries/blob/master/draft-vkrasnov-h2-compression-dictionaries.md>.
Lack of excitement from the security community has since caused me to doubt
it will become a reality in the near future.
</performance-person-hat>

<api-owner-hat>
The use-case as outlined by the AMP team seems like a win that will enable
decentralizing content which aggregators provide to their users.

The current model where aggregated content (AMP, but also MIP, Baidu's
variant) is often served from the aggregator's domain is not necessarily
healthy for the Web's long-term success. I'll be glad to see that model go
away, and this feature seems paramount to enabling that.

Other use-cases, such as offline sharing of PWAs also seem important and
can potentially increase the reach of web apps in emerging markets.

</api-owner-hat>

On Fri, Mar 2, 2018 at 2:30 AM Jeffrey Yasskin <[e-mail]> wrote:

> I'll be holding a side meeting (Bar BoF w/o the bar) Monday over lunch in
> the IAB office (https://datatracker.ietf.org/meeting/101/floor-plan) to
> talk about the Signed HTTP Exchanges and other Web Packaging proposals. See
> https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses
> and https://github.com/WICG/webpackage/blob/master/explainer.md.
>
> We'll be trying to determine interest in the area and nail down concerns
> that the specifications need to address.
>
> Thanks to Mark Nottingham for booking the room.
>
> Jeffrey
>