Re: [Wpack] Sec-Content-Origin clarification question (was Re: About content-based origins)

[Devin Mullins <[e-mail]>]

On Wed, Mar 25, 2020 at 10:28 AM Ted Hardie <[e-mail]> wrote:

> If the ecosystem supported something like signed bundles and unsigned
> bundles which used content identifiers, would you see a site sending a
> Sec-Content-Origin response resulting in the user agent essentially
> upgrading the bundle's treatment to the same as a signed bundle's, or would
> there a third state (unsigned bundled, verified NI, signed bundle)?
>

If you're asking about user-agent behavior, I'll defer to folks who work on
user-agents such as Martin and Jeffrey.

In terms of how the framework would behave, I'm not the expert, but from
the hip, I'd guess, if in all major user agents, signed bundles can access
storage on their attested origin, then we'd bundle the same JS in both
signed and unsigned cases. We'd have to move the state of any of our
render-critical components [1] to indexedDB for unsigned, and after that, I
don't see a reason to keep the non-indexedDB version around just for
signed; it'd be a maintenance burden. (But I'm betting there's nuances I
don't know about.) If transfer event handlers end up being a lot of code,
we could optimize them away in signed bundles to save JS binary size, but
I'm guessing they won't be a lot of code, therefore not worth the effort to
factor the code for that ability.

To make the above work, I'd think we'd need the "wait for transfer" DOM API
to resolve immediately for signed bundles and non-bundled pages.

Of course, with all things, this will take time. Since support for signed
exchanges exists today, it would be easiest to migrate support to signed
bundles initially, so I would expect a staggered rollout.

I hope I answered your question!

[1] or portions of the analytics/consent components, possibly

>