New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 750107 link

Starred by 0 users

Issue metadata

Status: WontFix
Last visit 22 days ago
Closed: Aug 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocked on:
issue 554220

Sign in to add a comment

Allow cross-eTLD+1 push

Project Member Reported by, Jul 28 2017

Issue description

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.



Comment 1 by, Jul 28 2017

Description: Show this description

Comment 2 by, Jul 28 2017

Blockedon: 554220
Marking  issue 554220  as dependency because both bugs require a largish change to do PUSH validation as a function of response headers, and I'll work on the other one first.
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.

Comment 5 by, Aug 16 2017

Status: WontFix (was: Started)
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