Re: CfC: Republish MIX as CR; deadline July 29th.

Mike West <mkwst@google.com> wrote:

> 2. As discussed in
> https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0137.html,
> we've changed MIX to handle passthrough `fetch()` requests inside Service
> Workers as optionally-blockable if they're triggered from
> optionally-blockable Document-generated requests.
>

Sorry for the slow response.

I read the change. The interesting thing about this change is that I have
no idea whether I agree with it or disagree with it, because it is so
unclear what is being specified.

If I understand correctly, then the |window| property of a request will
only be set if the request is created as part of an internal fetch for
loading subresources like <img src>. But, (1) is that something that we can
be sure will always be true, forever, and (2) how can anybody who isn't
very intimately involved with the implementation of browsers understand
what that means?

I think it would be better to do one of these things instead:

1. Have a distinct boolean property, .e.g. |synthesized|, on the request
that indicates whether it was internally-created by the UA or synthesized,
even if it is *currently* 100% redundant with the |window| property.

2. In the Fetch spec, document an algorithm "Was request generated by the
UA while processing declarative markup?" that is specified to currently
return |request.window != null|, and then reference this algorithm in MIX.

3. Add a read-only |originalContext| property to requests that is "fetch"
for any synthesized request and the value of |context| for any internal
request, and then test |originalContext| instead of |context|.

I personally think that #3 is best because I think it will also be useful
for specifying similar passthrough for referrer control (with a different
set of relevant contexts).

Cheers,
Brian