Subject: Re: [Wpack] On double-hashing (was: Re: About content-based origins)

From: Devin Mullins <[email-masked]>
Date: Wed, 1 Apr 2020 14:20:21 -0700

On Mon, Mar 30, 2020 at 8:44 PM Martin Thomson <[email-masked]> wrote:

> Not really.  The push can include the H(Content) and the site can
> calculate H(H(C)).  So the truncated hash only really limits the
> information the client has to include, trading it for more from the
> server.  Since opening that issue, I'm not convinced that it is worth
> pursuing for anything other than that trade-off (which is only a
> maybe-optimization at best).
>

Ah, my assumption was that the UA could limit the number of options the
server was allowed to respond with, thus weakly enforcing that others have
the same content. The utility of that enforcement would depend on the RPS
of the publisher's server, I suppose.

---

From: Devin Mullins <[email-masked]>
Date: Fri, 3 Apr 2020 15:59:00 -0700

>
> 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".

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 06 Apr 2020 16:54:36 +1000

On Sat, Apr 4, 2020, at 09:59, Devin Mullins wrote:
> 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.

There is nothing that is inherent to the design that prevents content from talking to its target origin (or any other origin for that matter).  What might cause that to be limited is policies that a browser might apply to those interactions.  For instance, in the AMP case, the entire point is to prevent that sort of communication because that might allow a publisher to exfiltrate information about the linking context prior to a decision to activate a link.

Assuming that the transfer of state to a target origin is under programmatic control, then any number of things might occur prior to that.  Even if you assume minimal communication, you might allow content to specify query parameters on the request to transfer.
 
> 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.

The deployment question is separate than one you might make about target origin.  Content that is served from A might falsely claim a target origin of B, so you would have to allow the server that applies the ACL to decide not to accept the request.  Assuming with an assumption that this sort of request would be denied might be OK.

For deployment, yeah, I expect that if there is enough demand for this, then the providers of fonts and other such things would be motivated to enable this interaction and could do so relatively easily.

> It occurred to me it may be possible for a bundling service to 
> determine whether a page uses state, with ~0 false negatives.

That seems right; you could probably get a long way the way you describe.  You could maybe also do this empirically: load pages with an extension that shimmed out those APIs that relate to state and log uses with some false negatives.  Browsers could help with this by hooking that analysis into the reporting API, or by supporting CSP rules that constrained use and generated reports on violations.