Re: [blink-dev] Intent to Ship: DPR, Width, and Viewport-Width client hints

[Yoav Weiss]

On Tue, Jul 14, 2015 at 5:07 PM, Philip Jägenstedt <phi...@opera.com> wrote:

I'm not sure who's waiting for whom at this point. Yoav, are you
having any off-list discussions, or waiting for feedback here?

I believe we're still waiting on some feedback from the net folks.

After giving it some thought, I'm wary of the "just send CH for every image context request" proposals raised on this thread, since (on top of the non-negligible overhead) the headers would hit servers that didn't expect them, and may cause similar backend namespace collisions like what we saw with the "HTTPS" header.

I think that an opt-in approach is significantly safer, and assuming we forgo state for the time being, leaks no further info than a "sending CH to all servers" approach, and poses no linkability risks AFAICT.

Forgoing state would mean that the use-case of direct image URL navigation will not be addressed, but we can address it further down the line by either adding opt-in persistency and/or sending hints on navigational requests.

 

[Mark Nottingham]

> On 16 Jul 2015, at 10:01 pm, Yoav Weiss <yo...@yoav.ws> wrote:
>
>
> On Tue, Jul 14, 2015 at 5:07 PM, Philip Jägenstedt <phi...@opera.com> wrote:
> I'm not sure who's waiting for whom at this point. Yoav, are you
> having any off-list discussions, or waiting for feedback here?
>
> I believe we're still waiting on some feedback from the net folks.
>
> After giving it some thought, I'm wary of the "just send CH for every image context request" proposals raised on this thread, since (on top of the non-negligible overhead) the headers would hit servers that didn't expect them, and may cause similar backend namespace collisions like what we saw with the "HTTPS" header.

I don't think that's a reason to not send them on its own; "HTTPS" was pretty much a fluke. At most, I think we can take away that we shouldn't name headers for existing, well-defined protocol constructs or mechanisms, because implementations might use those as a shorthand for internal use (and even then, those servers are still *very* broken).

> I think that an opt-in approach is significantly safer, and assuming we forgo state for the time being, leaks no further info than a "sending CH to all servers" approach, and poses no linkability risks AFAICT.
> Forgoing state would mean that the use-case of direct image URL navigation will not be addressed, but we can address it further down the line by either adding opt-in persistency and/or sending hints on navigational requests.
>

--
Mark Nottingham https://www.mnot.net/

[Ryan Sleevi]

On Thu, Jul 16, 2015 at 1:01 PM, Yoav Weiss <yo...@yoav.ws> wrote:

I think that an opt-in approach is significantly safer, and assuming we forgo state for the time being, leaks no further info than a "sending CH to all servers" approach, and poses no linkability risks AFAICT.

I'm still not sure I buy this or the "it's accessible via JS" argument, but that's really a question for the Chrome privacy team about how they balance such tradeoffs, and a broader question for the W3C TAG/Privacy Interest Group about how they feel about such things.

Within the extent of balancing tradeoffs, does it make sense to ensure that if going the CH route, the CH are only sent for first-party requests? And only within the main document?

I do wonder from the Blink render/loader stage whether it's possible/reasonable to satisfy the CH bits, so I'd look to hear more from those that understand that side (Philip?). Part of this concern is that other "header influences other requests on the page" mechanisms, such as HPKP and HSTS, there's a lot of non-determinism, but those are admittedly due to the headers affecting socket-level behaviours rather than request-level behaviours. That is, put differently, whether or not the need to know Width/Viewport at the time of kicking off requests during the main page parse phase would cause requests to be held back / occurs at a weird time in loading.

[Philip Jägenstedt]

I have only taken a brief look at the implementation and Yoav can fill in the details, but basically this is a part of the preload scanner, which parsers the page without blocking on scripts or stylesheets, fetching things that will very likely be needed, but can of course turn out not to be if a script turns the world upside down.

This code also knows the viewport size and how to parse the relevant attributes, because that's already used for <picture>. So in terms of implementation, I think everything is in order to send the appropriate headers, whatever we decide they are, without request reordering.

Yoav and I chatted on IRC, where I complained that the header name Accept-CH is quite misleading, as this isn't content negotiation in the style of other Accept-* headers I'm aware of. Many (most?) of these headers will be sent to other hosts entirely that are not part of the negotiation, and ought not be. Yoav wasn't psyched about changing the name but still came up with Send-CH, which I think describes the behavior better: I command you to send these headers.

Philip

[Yoav Weiss]

On Thu, Jul 16, 2015 at 10:06 PM, Mark Nottingham <mn...@mnot.net> wrote:

> On 16 Jul 2015, at 10:01 pm, Yoav Weiss <yo...@yoav.ws> wrote:
>
>
> On Tue, Jul 14, 2015 at 5:07 PM, Philip Jägenstedt <phi...@opera.com> wrote:
> I'm not sure who's waiting for whom at this point. Yoav, are you
> having any off-list discussions, or waiting for feedback here?
>
> I believe we're still waiting on some feedback from the net folks.
>
> After giving it some thought, I'm wary of the "just send CH for every image context request" proposals raised on this thread, since (on top of the non-negligible overhead) the headers would hit servers that didn't expect them, and may cause similar backend namespace collisions like what we saw with the "HTTPS" header.

I don't think that's a reason to not send them on its own; "HTTPS" was pretty much a fluke. At most, I think we can take away that we shouldn't name headers for existing, well-defined protocol constructs or mechanisms, because implementations might use those as a shorthand for internal use (and even then, those servers are still *very* broken).

I agree. What I meant to say is that it'd be significantly safer to send out these headers with the explicit opt-in mechanism that Accept-CH provides us, at least at first. 

[Yoav Weiss]

On Thu, Jul 16, 2015 at 10:26 PM, Philip Jägenstedt <phi...@opera.com> wrote:

On Thu, Jul 16, 2015 at 10:06 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Jul 16, 2015 at 1:01 PM, Yoav Weiss <yo...@yoav.ws> wrote:

I think that an opt-in approach is significantly safer, and assuming we forgo state for the time being, leaks no further info than a "sending CH to all servers" approach, and poses no linkability risks AFAICT.

I'm still not sure I buy this or the "it's accessible via JS" argument, but that's really a question for the Chrome privacy team about how they balance such tradeoffs, and a broader question for the W3C TAG/Privacy Interest Group about how they feel about such things.

Within the extent of balancing tradeoffs, does it make sense to ensure that if going the CH route, the CH are only sent for first-party requests? And only within the main document?

I do wonder from the Blink render/loader stage whether it's possible/reasonable to satisfy the CH bits, so I'd look to hear more from those that understand that side (Philip?). Part of this concern is that other "header influences other requests on the page" mechanisms, such as HPKP and HSTS, there's a lot of non-determinism, but those are admittedly due to the headers affecting socket-level behaviours rather than request-level behaviours. That is, put differently, whether or not the need to know Width/Viewport at the time of kicking off requests during the main page parse phase would cause requests to be held back / occurs at a weird time in loading.

I have only taken a brief look at the implementation and Yoav can fill in the details, but basically this is a part of the preload scanner, which parsers the page without blocking on scripts or stylesheets, fetching things that will very likely be needed, but can of course turn out not to be if a script turns the world upside down.

This code also knows the viewport size and how to parse the relevant attributes, because that's already used for <picture>. So in terms of implementation, I think everything is in order to send the appropriate headers, whatever we decide they are, without request reordering.

Yeah, everything is in place in the preloadScanner to send out the correct headers, and most of it is there for srcset/<picture>.

 

Yoav and I chatted on IRC, where I complained that the header name Accept-CH is quite misleading, as this isn't content negotiation in the style of other Accept-* headers I'm aware of. Many (most?) of these headers will be sent to other hosts entirely that are not part of the negotiation, and ought not be. Yoav wasn't psyched about changing the name but still came up with Send-CH, which I think describes the behavior better: I command you to send these headers.

As you said, I prefer to leave the naming as is. With that said, let the bikeshed begin :) 

[Ilya Grigorik]

On Thu, Jul 16, 2015 at 1:06 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

I'm still not sure I buy this or the "it's accessible via JS" argument... (snip)

Ryan, which parts? The simple proof is that it's possible to polyfill <picture> [1]. However, using that requires that you rewrite your markup to use <picture> and incur the penalty costs of running the polyfill... CH resolves both of these.

 

Within the extent of balancing tradeoffs, does it make sense to ensure that if going the CH route, the CH are only sent for first-party requests? And only within the main document?

No, that would break a lot of important CH use cases - e.g. many sites host their assets on separate (CDN) origin(s). Extending same argument as above, you can already export all the same data by encoding it in the URL, or if you have SW by appending appropriate headers.. Albeit with various performance costs as you can't get at this data as early as our native implementation that we're discussing here.

[1] https://github.com/scottjehl/picturefill 

On Thu, Jul 16, 2015 at 1:51 PM, Yoav Weiss <yo...@yoav.ws> wrote:

Yoav and I chatted on IRC, where I complained that the header name Accept-CH is quite misleading, as this isn't content negotiation in the style of other Accept-* headers I'm aware of. Many (most?) of these headers will be sent to other hosts entirely that are not part of the negotiation, and ought not be. Yoav wasn't psyched about changing the name but still came up with Send-CH, which I think describes the behavior better: I command you to send these headers.

As you said, I prefer to leave the naming as is. With that said, let the bikeshed begin :) 

I'd prefer we skip the bikeshed. "Send" is no clearer than "Accept" in indicating that CH headers will be sent for all subresources, and "Accept-" does have an established pattern of use; there is no need to reinvent this particular wheel.

ig

[Yoav Weiss]

At PhilipJ's request, I'd like to summarize where we're at and how we got here (to make it easier for more OWNERS to weigh in :D)

A few things that came up during the discussions:

* The spec was missing a "privacy considerations" section, since added.

* Concerns were raised about interaction with intermediaries, which after discussions, we agreed are not an issue.

* I wrote a browser implementation consideration document to address various questions raised, and to complement the spec.

* The original algorithm for the hints didn't match the client-side responsive images solutions, and we decided that it would be better to match the info sent with `Width` and `Viewport-Width` to source-size. In practice that meant removing the `width` attribute value for the time being. We'd add that back once we add it to source-size.

* There was a discussion about the need for an opt-in mechanism and its nature. We discussed avoiding the opt-in and trying to slowly roll-out the feature by other means, but eventually decided that an opt-in is the best way forward. In order to avoid info leaks, we decided that at a first phase we won't add any persistency to the opt-in signal, resulting in some use-cases not addressed right now (mainly the "direct navigation to an image URL" use-case).

The only remaining open question is with regard to the naming of the opt-in signal. Currently it is "Accept-CH", which in PhilipJ's view might be confusing (as it is applied to the current document rather than to the host), and would better be called "Send-CH".

[Mark Nottingham]

On the standards side — we discussed CH briefly at the http meeting yesterday, and I intend to issue a Call for Adoption shortly.

I've also been discussing an alternative working group process with folks, whereby we can hold discussions and make decisions on the issues list, rather than the mailing list. I need to put the details of how that would work together, but would be happy to make this draft a trial of that if it works for people.

Would implementers show up in the HTTP WG to push this through if we adopted it? And, are you happy to continue editing, Ilya?

Cheers,

[Philip Jägenstedt]

I was assuming some kind of consistency in how existing Accept* headers work, but it's not as orderly as I had thought:

• Accept is sent by the client and influences the Content-Type of the response. (This has become ossified, it's not an actual enumeration of supported types.)
• Accept-Charset is sent by the client and influences the charset parameter in the Content-Type of the response. (No longer sent by browsers.)
• Accept-Encoding is sent by the client and influences the Content-Encoding of the response. (Still useful.)
• Accept-Language is sent by the client and influences the Content-Language of the response. (Sent, but can only be used as a hint about the default language.)
• Accept-Ranges is sent by the server and tells the client that it can handle the Ranges header in subsequent requests. (Failed for <video>, where a "Range: bytes=0-" header is instead sent on the first request, and a 206 (Partial Content) response is evidence of support.)

The Accept-CH spec does give the impression that this should work similarly to Accept-Ranges with the mention of "subsequent requests", but Yoav's spec makes it clear that it's not so.

Anyway, I will not hold this feature hostage to a naming issue, and if both Yoav and Ilya think that Accept-CH is fine, then fine it is.

Philip Rogers is going to have a chat with Ilya and follow up on this thread, I am told.

Philip 

[Ilya Grigorik]

On Wed, Jul 22, 2015 at 1:29 AM, Mark Nottingham <mn...@mnot.net> wrote:

On the standards side — we discussed CH briefly at the http meeting yesterday, and I intend to issue a Call for Adoption shortly.

I've also been discussing an alternative working group process with folks, whereby we can hold discussions and make decisions on the issues list, rather than the mailing list. I need to put the details of how that would work together, but would be happy to make this draft a trial of that if it works for people.

Would implementers show up in the HTTP WG to push this through if we adopted it? And, are you happy to continue editing, Ilya?

Yes x2, let's do it :)

On Wed, Jul 22, 2015 at 1:33 AM, Philip Jägenstedt <phi...@opera.com> wrote:

The only remaining open question is with regard to the naming of the opt-in signal. Currently it is "Accept-CH", which in PhilipJ's view might be confusing (as it is applied to the current document rather than to the host), and would better be called "Send-CH".

I was assuming some kind of consistency in how existing Accept* headers work, but it's not as orderly as I had thought:

• Accept is sent by the client and influences the Content-Type of the response. (This has become ossified, it's not an actual enumeration of supported types.)
• Accept-Charset is sent by the client and influences the charset parameter in the Content-Type of the response. (No longer sent by browsers.)
• Accept-Encoding is sent by the client and influences the Content-Encoding of the response. (Still useful.)
• Accept-Language is sent by the client and influences the Content-Language of the response. (Sent, but can only be used as a hint about the default language.)
• Accept-Ranges is sent by the server and tells the client that it can handle the Ranges header in subsequent requests. (Failed for <video>, where a "Range: bytes=0-" header is instead sent on the first request, and a 206 (Partial Content) response is evidence of support.)

The Accept-CH spec does give the impression that this should work similarly to Accept-Ranges with the mention of "subsequent requests", but Yoav's spec makes it clear that it's not so.

FWIW, as implemented we do require Accept-CH opt-in, and I think that's the right place to start to mitigate concerns over request overhead. We'll update Yoav's doc to resolve the confusion. 

 

Anyway, I will not hold this feature hostage to a naming issue, and if both Yoav and Ilya think that Accept-CH is fine, then fine it is.

My preference is to keep Accept-CH. If we do find ourselves wanting to change the name later, we can do so: the combination of the opt-in model, plus the fact that we don't (can't) always send all the headers means that developers have to account for the cases where CH hints are not present.. changing the opt-in name won't break the site.

Naming discussions aside, I think we have all the necessary functionality and precautions in place, and at this stage we need to get this feature into the hands of developers to get some real-world production experience to inform further iterations.

ig

[Philip Rogers]

LGTM, but I'd like for the privacy team to sign off on the issues raised here and on the Mozilla bug. Ilya is going to kick off the privacy review.

The benefits of bandwidth/memory savings and latency reduction are subtle but powerful. My main worry is that I'm not a networking expert but our networking team, Mozilla's networking team, and CDNs all seem to be supportive. I think it's likely the spec will change a bit once feedback comes in from us shipping, but the nature of headers means we won't break existing users if this happens (nor if this feature had to be removed entirely).

[Philip Jägenstedt]

LGTM2

[Chris Harrelson]

LGTM3!

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[igri...@google.com]

On Wednesday, July 22, 2015 at 1:32:29 PM UTC-7, Philip Rogers wrote:

LGTM, but I'd like for the privacy team to sign off on the issues raised here and on the Mozilla bug. Ilya is going to kick off the privacy review.

Got A-OK from the privacy review. CC'ing mkwst@ and engedy@ who did the review in case any other questions come up.

CL to land this https://codereview.chromium.org/1262253002/.

Thanks everyone! Onwards! :-)