RFP: Client Hints about standards-positions HOT 41 CLOSED

To clarify; is this a request for a moz position on Client Hints (the whole spec), or specifically the Accept-CH header? I'm guessing it's the former, in which case the title should be changed.

from standards-positions.

I think our experience of being a minority-share browser (by different amounts at different times in our history) has taught us that server-side content negotiation has historically been worse for competition in the browser space than client-side content negotiation because it's been harder for minority browsers to get content that works for them. It's possible that the addition here of more pieces of data in that space may help, but I fully expect sites to infer other facts from the small set of facts they're provided, and I expect those inferred facts to often be incorrect for the browsers the sites weren't thinking about. (On the client side, there's a much richer set of information both about the device and about feature availability, and I think that has historically helped a bit because there was a "correct" client-side way to detect many things developers care about.)

I expect that wider use of things like this will lead to minority browsers like us maintaining site-specific lists of lies to tell (e.g., shipping code in the browser that says that any URL starting with https://www.google.com/maps (plus a hundred country-specific variants of it) will never be told that the browser's display width is between 600 and 900 pixels) just as minority browsers are likely to have to do the same for User-Agent. (To be clear, that's a mostly-made-up example.)

from standards-positions.

@mnot errrr, sorry.. false alarm. I misread the publication date on the httpwg draft. All good!

from standards-positions.

Architecturally, we prefer client-side solutions for retrieving alternate versions of content, such as .

I don't believe that's an architectural position, it looks more like preference driven by a browser vendor's perspective.

Architecturally, the Web supports both client-driven (reactive) and server-driven (proactive) negotiation for good reasons; for one, server-driven negotiation is possible to interpose in the server or an intermediary without modifying HTML content, a valuable property when one relies on infrastructure to do things like resize pictures, compress content, and so on.

This is not being driven by "legacy systems;" it's a requirement at scale by many very modern sites.

from standards-positions.

@dbaron: You mention a "'correct' client-side way to detect many things developers should care about". Isn't that exactly what Client Hints is aiming for on the server side? Creating a "correct" server-side detection path exactly so that sites aren't practically pushed towards inferring data (often incorrectly!) based on the limited amount of information in an HTTP request?

from standards-positions.

I think our experience of being a minority-share browser (by different amounts at different times in our history) has taught us that server-side content negotiation has historically been worse for competition in the browser space than client-side content negotiation because it's been harder for minority browsers to get content that works for them.

@dbaron can you provide some specific past examples?

I fully expect sites to infer other facts from the small set of facts they're provided, and I expect those inferred facts to often be incorrect for the browsers the sites weren't thinking about.

@dbaron ditto, I'll echo @mikewest's earlier comment.. I'm not trying to be confrontational, but I'm struggling to reason about this in the abstract. Are the specific edge cases you're concerned about in the context of Sec-CH-Lang, Sec-CH-UA-*, and other hints that we've proposed to date?

Having yet more client hints could help -- though one issue we've had in the past with detection mechanisms that are detached from the actual feature is that the detection mechanism gets out of sync with the thing it's detecting. There are probably ways we could help fix that, though (e.g., by adding syntax to tie things to feature detection mechanisms into WebIDL).

It's an explicit goal of CH to integrate the feature and the hint(s), such that they are coherent and accurate. That's why we're integrating this infrastructure with HTML, Fetch, and all the relevant specs and feature definitions in other places. I agree with you that status quo (parse UA string -> guess a long list of properties) is broken and that's what CH is trying to fix.

from standards-positions.

I think Mozilla should reconsider rating Client Hints (the original draft, not the specific new use) as "non-harmful".

Client Hints presents a privacy risk even if it involves sending some data to the server that is already available on the client side. In particular, many widespread web trackers have persuaded sites to embed a "tracking pixel" (a 0x0 or 1x1 image), but not script. By providing more entropy to the server, we enable better fingerprinting through purely passive third-party web resources. Since many cross-site trackers have wider reach for passive resources than for directly included script, this hurts privacy in practice. This could be mitigated by withholding Client Hints from third-party sub resources, but the internet-draft does not do so, and I think doing so would defeat some of the proposed use cases (such as CDNs doing server-side image selection).

This privacy risk, combined with the architectural layering issue (which we on the WebKit team agree with) makes the feature overall harmful in my opinion.

from standards-positions.

That sounds like a neat plan. I agree that httpwg/http-extensions#372 raises the same problem I am describing. At this time the plan seems to consist of issues and multiple in-flight pull requests so a bit hard to review quickly whether it will fully address the privacy risk.

from standards-positions.

Hmm, the httpwg draft appears to be out of date. The latest version is:
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-05

On a related note, Chrome M67 is shipping Accept-CH + Accept-CH-Lifetime support documented in -05 draft — see blink-dev i2s.

from standards-positions.

@igrigorik Github says that was rebuild an hour ago.

https://github.com/httpwg/http-extensions/tree/gh-pages

from standards-positions.

cc @ddragana @mayhemer @mcmanus

from standards-positions.

I think that this needs to be client-hints as a whole. At some point we will need to make decisions separately about whether to send DPR, Save-Data, and friends when a server requests them. That decision might be different for each hint, but right now we are looking to see if the spec is good or bad.

Unfortunately, though I say that we want a position on the entire specification, the answer is bound up in the trade-offs that apply to each of the hints. For mine, DPR is harmless, whereas Save-Data remains fraught for all the reasons that the network information API was tricky. Width and Viewport-Width are close to harmless. I'm inclined toward non-harmful as a whole.

from standards-positions.

My opinion on Client-Hints hasn't changed from the bug comments.

I can understand why client-hints is easier to bolt onto some legacy systems than more HTML/CSS-oriented solutions, but I still think HTTP is the wrong layer for this, because the hint values can change in situations where re-requesting everything would be undesirable (e.g. rotating a hand-held device or zooming on desktop).

I think the image use case should be handled via <picture> and srcset. I think the CSS use case should be handled via an attribute on <link> to opt out synchronous CSSOM access so that style sheets whose media query isn't currently matching don't need to be eagerly fetched.

I.e. I think our position should be that Client-Hints are harmful. However, if Client-Hints proceeds regardless, Accept-CH is likely non-harmful in the sense that it avoids a situation where browsers would have to keep sending Client-Hints to every site forever just in case some site actually depended on it.

from standards-positions.

I think the CSS use case should be handled via an attribute on <link> to opt out synchronous CSSOM access so that style sheets whose media query isn't currently matching don't need to be eagerly fetched.

FWIW, the HTML Standard allows for this these days and most browsers didn't do this to begin with.

from standards-positions.

FWIW, the HTML Standard allows for this these days and most browsers didn't do this to begin with.

Do we have a bug open for matching most browsers on the point of CSS loading?

from standards-positions.

https://bugzilla.mozilla.org/show_bug.cgi?id=1386840

from standards-positions.

To clarify; is this a request for a moz position on Client Hints (the whole spec), or specifically the Accept-CH header? I'm guessing it's the former, in which case the title should be changed.

I'm asking whole. So I'll change the title.

from standards-positions.

FWIW, the HTML Standard allows for this these days and most browsers didn't do this to begin with.

@annevk, you and @hsivonen are talking about different things. You're talking about whether the fetch blocks rendering. He's talking about whether the fetch happens at all.

from standards-positions.

I can understand why client-hints is easier to bolt onto some legacy systems than more HTML/CSS-oriented solutions, but I still think HTTP is the wrong layer for this, because the hint values can change in situations where re-requesting everything would be undesirable (e.g. rotating a hand-held device or zooming on desktop).

FWIW, contrary to the legacy claim we're seeing a lot of requests and demand for hints on navigation requests to help optimize delivery of new products. As a concrete example, Google Search goes to great lengths to identify client's properties (network, screen size/capabilities, etc) to deliver fast responses to the client. In some markets this means aggressively scaling back and disabling media heavy features, serving completely different HTML powered by a different stack, etc. Ditto for Google Maps, YouTube, and many other non-Google products. The argument for CH is not that you "cannot do this with plain HTML / CSS / JS", but that CH enables a much more efficient route to tackle such use cases — saving a few RTTs on flaky or high-latency connection has significant impact on product.

I think the image use case should be handled via and srcset. I think the CSS use case should be handled via an attribute on to opt out synchronous CSSOM access so that style sheets whose media query isn't currently matching don't need to be eagerly fetched.

I'm with you. I wish every developer and site owner would adopt <picture> and srcset, religiously optimize all of their assets with optimal quality settings, scale them to display size, and transcode them to relevant optimal image formats. Alas, that is not true today, and I have little faith that this will ever going to happen — I've spent last half decade trying to convince developers to do so, mostly unsuccessfully. In addition to the markup solutions ("the advanced mode") we need to pave paths that allow for simple automation of these best practices, which is the niche that CH aims to fill.

from standards-positions.

I think that who choose "which contents will fits for the client" should CLIENT not SERVER.
for example, client send "I'm on wifi", but that's doesn't mean server can serve large content to that client.
if server returns large content for wifi hints and that (seems) works for now, but imagine future if mobile has new candidate about network status, and user doesn't wanna large contents on wifi.
I think mobile browser will send different value to server even if they on wifi. that's the similar thing happens on User-Agent. same for other hints DPR and Width etc.

again, server can't decide which content is fits for client, even if clients sends piece of state information.
if server decide choice of contents based of CH, client will send lie to CH if they wanna other choice from server does. and CH header will be useless.
It seems better to send choice of candidate from server, and client should choice which is fits, like Picture/srcset.

from standards-positions.

@Jxck you're making same argument as @hsivonen. I agree that there are tradeoffs when the server makes the decision vs. the client, however this is not a binary "good or bad pattern" discussion. There are cases where deferring decision to the server leads to a better outcome for the user, and yes in some cases the application may need to provide a way for the user to override server's decision — this is nothing new, many applications already do this.

As a concrete example, the Google Search App serves a very different experience when the server detects certain client properties, and that has huge lift on user experience (e.g. as in, the user is actually able to see the results), but delivering same experience on the web is pure guesswork (with much lower success rate) today without cooperation from the client — i.e. they need Client Hints.

from standards-positions.

@igrigorik

application may need to provide a way for the user to override server's decision

this seems saying lie on CH.

many applications already do this

give me some example which kind of application ?

from standards-positions.

A simple example is weblight..

Google shows faster, lighter pages to people searching on slow mobile connections in selected countries. To do this, we transcode (convert) web pages on the fly into a version optimized for slow networks, so that these pages load faster while saving data.

Same logic applies to Search pages themselves, etc.

from standards-positions.

I've read through the comments above, the comments on Bug 935216, the discussion on dev-platform, and refreshed my memory on the WHATWG objections to conneg. While there is no clear consensus about overall merit, the following appears to be generally true:

• Architecturally, we prefer client-side solutions for retrieving alternate versions of content, such as <picture>.
• Despite these architectural preferences, we find that Client-Hints do not present a concrete harm to the web or to its users.

Based on the foregoing, I agree with @martinthomson's evaluation that Mozilla considers this specification to be non-harmful.

from standards-positions.

In light of @martinthomson's comments on https://lists.w3.org/Archives/Public/ietf-http-wg/2018OctDec/0176.html, and some conversations I had at TPAC with @dbaron, @dveditz, and others, I'd like to get a feel for whether or not the Sec-CH-Lang and Sec-CH-UA-* hints alter y'all's view on the underlying Client Hints infrastructure.

@adamroach: Would it be reasonable to reopen this RFC for that question? Or would you prefer that I file a new RFC on those specific hints?

from standards-positions.

It's creating a correct way for a set of things -- but often what people care about is the vast array of javascript-detectable features that are incrementally added to the web platform. (At least, I don't think Client Hints is covering that.)

from standards-positions.

Perhaps I'm misunderstanding your concern. It sounds like you're worried that sites make assumptions based on incomplete and/or incorrect information in HTTP requests. Client Hints would seem to mitigate this risk, insofar as it sends accurate information about a subset of the things that a site would otherwise want to (inaccurately) infer. You've suggested that sending accurate information might be bad for your users (the Maps example above), but that seems less likely to me than the status quo in which inaccurate assumptions based on user-agent string parsing rule the day. It'd be nice to chat a bit about your perspective, since I suspect you have more data to back up your assertions that I'm missing.

Still, in your last comment, you suggest that "people care about ... the vast array of javascript-detectable features that are incrementally added to the web platform", and note that Client Hints only addresses a subset. One way of engaging with that response is to suggest that we should have more Client Hints, to cover more of the things that would otherwise be inferred via user-agent parsing so that developers don't guess. :)

from standards-positions.

I think there's a tradeoff. Client-Hints improves the capabilities of detection that's done on the server side -- but it's still only a tiny fraction of what can be detected on the client. It also increases the power of detection that's done on the server side, which will encourage more of it to be done on the server rather than the client, which moves it to the place where it's going to be less accurate/powerful.

Having yet more client hints could help -- though one issue we've had in the past with detection mechanisms that are detached from the actual feature is that the detection mechanism gets out of sync with the thing it's detecting. There are probably ways we could help fix that, though (e.g., by adding syntax to tie things to feature detection mechanisms into WebIDL).

from standards-positions.

Also for context, WebKit's current view on Client Hints is that we will not implement it as specified, and we object to further potentially less harmful features being layered on top of it.

from standards-positions.

@othermaciej - The concerns you raise are valid, were raised before and were fully addressed in the latest PR incarnation of the spec (even if not yet in the Chromium implementation :/).

The plan is to add explicit third party delegation of certain hints to certain third parties, that will enable content owners to address the CDN use-case, while avoiding leaking that information to unrelated passive third-party resources.

Furthermore, As @mikewest mentioned above, we plan to use these capabilities to explicitly reduce passive fingerprinting surface, and specifically, to replace the passive fingerprinting the User-Agent and Accept-Language headers provide with explicit client hints, which the origin opts into. That would provide the browser with more knowledge regarding who is using those values, and will give it more power to block or lie about those values in cases where it deems it necessary to protect the user's privacy.

from standards-positions.

If by "CDN use case" you mean "third party content", I agree. However, CDNs could use CH if it were restricted to first-party; it just wouldn't apply to quite as many use cases (which is the case for any site, CDN'd or not).

from standards-positions.

@mnot I was imagining a CDN use model where the main resource is served from one origin (perhaps self-hosted by the site operator, perhaps cached) and static resources from a different fully CDN-controlled origin. I agree that if the CDN serves the whole page, including all sub resources, from a single origin, then strictly first-party only client hints would suffice.

I am not sure of the relative frequency of these models or how much need they have for client hints. Strictly first-party-only CH would have less privacy risk than even allow list gated access for third parties.

from standards-positions.

@mnot - yeah, my use of "CDN use case" was ambiguous, sorry! :) I was referring to the case where the CDN is serving assets off of a dedicated domain, rather than the same domain as the main page.

from standards-positions.

In case that's helpful, I wrote an explainer and a "spec situation" document that may help when reviewing the current state of the feature's specification as well as the overall motivation behind it. Feedback welcome! :)

from standards-positions.

@ddragana will take another look at this.

from standards-positions.

@martinthomson - given our discussions at IETF 105, should Mozilla reconsider its position here?

from standards-positions.

The current rating seems to be accurate. If you were looking for a signal about whether Firefox would ship the capability, that's a separate discussion.

from standards-positions.

@martinthomson - would it make sense to open a separate issue for specific features that use this framework (e.g. UA Client Hints)?

from standards-positions.

Probably best. We generally don't want to ask questions about every tiny thing, but that seems like it might be big enough to ask about separately.

from standards-positions.

@martinthomson - Thanks! Filed #202

from standards-positions.

I'm not seeing any new information in here that really bears on the initial question about client hints in general -- the discussion mostly revolves around the UA Client Hints issue that #202 raises. I'm going to re-close this issue, and take guidance from #202 for a position on that specific subset of client hints.

from standards-positions.