Re: [whatwg/fetch] Define a cache for H2 server push & friends (#354)

On Sun, Feb 26, 2017 at 4:07 PM, Martin Thomson <notifications@github.com>
wrote:

> (I'm really fuzzy on which origins we're talking about being the "same"
> here. There is a page origin, the request origin, and the origin of the
> pushed resource. All are potentially relevant in this context.)
>
I'm not sure how best to clarify the confusion, because there's only one
origin - it's a scheme/host/port tuple. It's the processing model that
varies, and that is the point. The coalescing of HTTP/2 does not mean that
you can skip the processing model of Fetch or CORS - as to do so would
undermine the security properties and principles that the SOP is designed
to protect.

> I'm looking at fetch and it doesn't appear to be that there is any problem.
>
We should work to figure out why, given the above explanation. It's unclear
whether you disagree with my observations regarding the interaction or
whether I didn't communicate them well.

> I agree that there are many reasons for withholding a request, but they
> can all be reduced simply by observing two things:
>
>    1.
>
>    Sites can cause the browser to make a request. This is no different to
>    generating a push promise.
>
> I tried to explain why this observation is incorrect. I'm not sure if the
fuzziness above made that less obvious, but I'm hopeful we can figure out
where the confusion is. There are a number of notable differences here, in
that there are a number of ways in which sites cannot cause the browser to
make certain types of requests, whereas PUSH promises would allow them to
make that. That's the problem - and a security risk.

>
>    1.
>
>    The existence of a response does not need to mean that the response
>    needs to be used. Thus, all the blocking, service workers, and other
>    conditions can easily apply before consuming the response. Worst case, the
>    request needed a preflight; so send the preflight and hope that that was
>    pushed as well.
>
> I'm not sure I agree with this, on two grounds:

1.  You cannot apply these easily, because of the issues I've already
highlighted in that an initiation of fetch has a context (in the page and
origin) that exceeds the available information in a PUSH PROMISE. Ergo, you
cannot map the information from a PUSH PROMISE into an equivalent framing,
even though you have an associated URL.
2. I disagree that preflight is the "worst case", due to the fact that any
form of cross-origin push is already a-priori cross-origin. Therefore, I
assert that the need for a preflight is arguably the common case for any
form of cross-origin push.

These two concerns - and the issues I highlighted - hopefully demonstrate
why you it's neither an 'easy' matter nor a compliant manner to allow a
PUSH into the HTTP cache.

> I appreciate the caution, and the reasons, and the need to make some
> changes to accommodate the above model (if you accept that it is valid).
> However, I don't think that those reasons are strong enough to say that you
> categorically don't cache pushed resources.
>
I'm not sure how we can agree on the above item but disagree here. As it
stands, you categorically cannot cache pushed resources safely. I think
we're both in agreement that changes need to be made, but I'm suggesting
that as it stands, it is unsafe to enter a pushed item into the cache,
because it violates the processing model defined in the Fetch spec in
observable ways, both for the end-user and for the page author.

I think we're in agreement that it is possible to imagine an outcome where
we do allow this, by refining the specs and, in some cases, outright
preventing it, but I think the point being is that this is all work that
needs to be done, has not been done, and has non-trivial security and
privacy impact, ergo, a UA cannot simply allow this for anything but
same-origin fetches in limited cases.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/354#issuecomment-282601827