Re: [Wpack] About content-based origins

[Devin Mullins <[e-mail]>]

>
> I think that Ekr and I both separately mentioned in on the call last week,
> but it's worth writing this down somewhere (because I failed to do so thus
> far).  There is a variant of this design that uses signature public keys as
> the primary identifier and considers all content signed with the
> corresponding private key as the one co-extant origin.  That avoids most of
> this mess.  There are a few challenges, but as the liveness test
> (Sec-Signer-Origin maybe) remains, concerns about revocation are
> approximately the same as it pertains to protecting the target origin.
>

Ah, interesting. This could solve a problem I just learned about.
https://amp.dev/documentation/components/amp-access/#amp-reader-id is used
for access control (e.g. paywalls). It has different user IDs across
different (publisher, delivery, browser) tuples, so this would bring that
to parity with existing behavior.

For experiments, I think the origin would want a way to opt into sharing
some subset of its state with this co-extant origin, before Sec-CO response
(e.g. for those middle-of-session pageviews). Otherwise, it has to delay
rendering or risk generating a session should be excluded from analysis.
Similar for consent.

For analytics & origin-based ACLs, their libraries/services would need code
changes (either to defer requests until origin is correct, or to accept
some alternate attestation of origin). My guess is that, even outside of
AMP, these are usually rolling releases [1], and thus changes would be
largely achievable. Just a guess.

This is of course coming from my document-centric view of the web, since
that's the use case I'm thinking most about.

[1] e.g.
https://developers.google.com/analytics/devguides/collection/analyticsjs

The other question you raise is the difficult of implementation for this.
> I don't know to what extent state is used in frameworks and sites, so I
> don't have a good handle on this.


It occurred to me it may be possible for a bundling service to determine
whether a page uses state, with ~0 false negatives. Easy version: disallow
any feature that uses state, such as JS. Medium version: hardcode
allowances for certain common 3p scripts. Difficult version: analyze
trivial scripts (classifying "don't know" as "uses state").

This would allow easier implementation for at least some portion of the
long tail of the publisher distribution. For the torso, the publisher could
provide an override annotation for any page that the bundler classifies as
"uses state".