Re: [Wpack] About content-based origins

[Martin Thomson <[e-mail]>]

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.