|Allow cross-eTLD+1 push|
|Project Member Reported by b...@chromium.org, Jul 28 2017||Back to list|
Currently SpdySession rejects a pushed HTTP/2 stream if eTLD+1 does not match. The reason for this is that cookies (and Channel ID) are scoped to eTLD+1. However, if the pushed request is cookieless (both the request and the response headers), then cross-origin pushed might be allowed as long as other requirements (like valid certificate) are met.
Currently, on connections with Channel ID, SpdySession rejects a pushed HTTP/2 stream if the pushed resource eTLD+1 does not match that of the connection (from SpdySessionKey). The reason for this is that Channel ID is scoped to eTLD+1. However, if the pushed request is cookieless (both the request and the response headers), then cross-origin pushes might be allowed as long as other requirements (like valid certificate) are met.  https://cs.chromium.org/chromium/src/net/spdy/chromium/spdy_session.cc?l=685
Jul 28 2017,
Just to capture some discussions with bnc@ on a design doc: The current requirement (that a channel ID be scoped to the eTLD+1) is a requirement driven by both privacy and security requirements. Privacy, in that a channel ID is "effectively" a cookie and that, by allowing this request cross-pollination, conceptually represents a "third-party tracking cookie" - which is unacceptable. Security, in that channel ID is not exclusively limited to cookies. That is, it's functionally a mechanism that can allow you to bind any resources/expressions to the bound token (and via Chrome-specific APIs, allows you to extract the public key from the bound token), and thus it's important to ensure a resource has the correct channel ID associated with the origin. For non-credentialed (Fetch term) or anonymous (CORS term) or privacy mode (Chrome term) requests, the eTLD+1 restriction won't apply, because Channel ID will not have been used. For virtually all non-Google traffic, the eTLD+1 restriction won't apply (because Channel ID will not have been used) For Google traffic, that is credentialed (Fetch), non-anonymous (CORS), non-privacy mode (Chrome), Channel ID may be used, and if so, the eTLD+1 restriction is important for both security and privacy, independent of cookies, so can't be removed.
Re comment #4: thank you for the detailed explanation. Based on our discussion, I am closing this issue at WontFix.
|► Sign in to add a comment|