Subject: I-D Action: draft-ietf-httpbis-client-hints-03.txt

From: [email-masked]
Date: Fri, 02 Dec 2016 10:08:22 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Hypertext Transfer Protocol of the IETF.

        Title           : HTTP Client Hints
        Author          : Ilya Grigorik
	Filename        : draft-ietf-httpbis-client-hints-03.txt
	Pages           : 13
	Date            : 2016-12-02

Abstract:
   An increasing diversity of Web-connected devices and software
   capabilities has created a need to deliver optimized content for each
   device.

   This specification defines a set of HTTP request header fields,
   colloquially known as Client Hints, to address this.  They are
   intended to be used as input to proactive content negotiation; just
   as the Accept header field allows clients to indicate what formats
   they prefer, Client Hints allow clients to indicate a list of device
   and agent specific preferences.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-hints/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-httpbis-client-hints-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 02 Dec 2016 18:38:33 +0000

--------
In message <[email-masked]>, [email-masked] writes:

So with my Common-Structure hat on:

>[...]
>     Save-Data = sd-token *( OWS ";" OWS [sd-token] )
>     sd-token = token

Why isn't this list separated by "," like we usually do ?

The same question goes for Key: header, even though that
is in a different draft ?

>	Key: DPR;partition=1.5:2.5:4.0

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Mike O'Neill" <[email-masked]>
Date: Sat, 3 Dec 2016 09:58:01 -0000

I worry that this makes fingerprinting easier for tracking servers, especially for subresources. 
It is true that these capabilities are already available via JS but only for browsing contexts and the extra turnaround forces some stickiness. This would make these granular user-agent capabilities immediately available to any resource, without need for a round trip.

I think that at least the availability of a user opt-in should be a MUST.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 02 December 2016 18:08
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-httpbis-client-hints-03.txt

Abstract:

---

From: Julian Reschke <[email-masked]>
Date: Mon, 5 Dec 2016 08:56:31 +0100

> Why isn't this list separated by "," like we usually do ?

It's consistent with other client hints which do not use list syntax... 
That said, the prose should state like for the other hints...

> ...

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 05 Dec 2016 08:20:27 +0000

--------
In message <[email-masked]>, Julian Reschke writes

>That said, the prose should state like for the other hints...

It may be consistent, but it is a good idea, if we want to make life
simpler down the road ?

---

From: Julian Reschke <[email-masked]>
Date: Mon, 5 Dec 2016 09:26:58 +0100

> It may be consistent, but it is a good idea, if we want to make life

No opinion on that right now; just explaining how the draft likely got 
there.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 05 Dec 2016 08:29:56 +0000

--------
In message <[email-masked]>, Julian Reschke writes

>No opinion on that right now; just explaining how the draft likely got 

Ok.

I'd like to suggest that we make these two (?) drafts conform to
common structure, by making the lists comma separated.

---

From: Ilya Grigorik <[email-masked]>
Date: Mon, 5 Dec 2016 13:51:39 -0800

> common structure, by making the lists comma separated.

Background: https://github.com/httpwg/http-extensions/issues/168

We didn't intend Save-Data to be a list.. The goal was to allow attributes
on the single token defined in CH. I'll defer to Mark on Key.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 6 Dec 2016 13:02:33 +0100

> common structure, by making the lists comma separated.

In general, if we are serious about common structure, we ought to.

That said, this draft has been through WG Last Call already...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 9 Dec 2016 14:01:58 +1100

> On 6 Dec. 2016, at 11:02 pm, Julian Reschke <[email-masked]> wrote:
> 

Personally, I tend to agree.

Ilya, will changing "save-data" to being comma-delimited cause great pain for implementation and deployment?

Cheers,

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

---

From: Ilya Grigorik <[email-masked]>
Date: Mon, 12 Dec 2016 17:22:21 -0800

> for implementation and deployment?

I'm still a bit confused about what we're trying to solve here.

The intent behind [1] was not to provide list semantics. Rather, we wanted
to allow a modifier on the token - e.g. "on;skip-video", or some such.
Similar to Key's "user-agent;substr=MSIE" and so on. As such, I'm not sure
the whole list discussion applies?

Am I missing something obvious? :-)

[1] https://github.com/httpwg/http-extensions/issues/168

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 13 Dec 2016 12:40:48 +1100

Hi Ilya,

On 13 Dec. 2016, at 12:22 pm, Ilya Grigorik <[email-masked]> wrote:
> The intent behind [1] was not to provide list semantics. Rather, we wanted to allow a modifier on the token - e.g. "on;skip-video", or some such. Similar to Key's "user-agent;substr=MSIE" and so on. As such, I'm not sure the whole list discussion applies?
> 

I think that's the context that was missing here. The intent AIUI is not to allow more than one save-data token to appear at a time (in a list); rather, it's to allow tokens to carry additional context as extensions.

Given that, is there still a concern about compatibility with what Common Structure might define?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 13 Dec 2016 22:02:07 +0000

--------
In message <[email-masked]>, Mark Nottingham wri
tes:

>I think that's the context that was missing here. The intent AIUI is not 
>to allow more than one save-data token to appear at a time (in a list); 
>rather, it's to allow tokens to carry additional context as extensions.
>

I think not.

But I'm left wondering why it was done that way ?

	Save-Data: on;video-only

looks fine, until you try to extend it and end up with:

	Save-Data: on;video-and-big-pictures-unless-cute-kittens

I would have leveraged mime-types and our existing "grading" tool:

	Save-Data: video/*;q=1,audio/*;q=5

But I'm not a stakeholder in this, so that is just an observation.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 14 Dec 2016 11:31:08 +1100

> on the single token defined in CH. I'll defer to Mark on Key.

Whether you have a list or not, Save-Data has some odd semantics when
it comes to extension.  How do I model the following variants?

Save-Data: on
Save-Data: on;video-only
Save-Data: on;exclude-video
Save-Data: on;compress-video-more

Assuming that the extensions are not understood, we end up in an odd
place.  I see several conclusions:

1. unknown extensions are ignored
2. unknown extensions can only increase the amount of compression; and
are ignored otherwise (see compress-video-more)
3. unknown extensions cause the entire clause to be ignored

Option 1 seems to be what we have right now, but that doesn't give a
client any way to request selective compression (the
video-only/not-video example).

Option 2 might allow a client to request more aggressive compression,
but it does nothing to address the case where a client wants video
compression, but would prefer not to have images degraded by
compression.

Option 3 might be combined with a comma-separated list to allow
clients to provide a fallback strategy.

There's also probably something more complex as well.

---

From: Nick Doty <[email-masked]>
Date: Tue, 13 Dec 2016 17:08:24 -0800

I share Mike's concern about the privacy issues of this proposed mechanism. It appears that this feature would ease browser fingerprinting; inhibit efforts to detect or mitigate browser fingerprinting; and expose local network information. The Security Considerations section does not adequately describe or mitigate these impacts.

In particular, while some information exposed in these hints may already be available to client-side JavaScript in some browser implementations, making the same information available in (potentially all) HTTP requests would make fingerprinting more trivially achievable and, importantly, less detectable. Making fingerprinting detectable is a key goal given the challenge of eliminating the capability altogether and the potential harmful effects of unsanctioned tracking methods. Moving information about the user from active client-side code into HTTP requests inhibits user agents, researchers and policymakers in detecting that fingerprinting is ongoing.

Related, adding HTTP headers for subrequests, including to static resources, exposes client information to parties that previously would not have been able to access it, and in a way where the user agent cannot detect it. The Introduction notes as a limitation that HTTP cookies are bound by the same-origin policy; we typically cite the same-origin policy as a feature of the Web privacy model, not something to be removed.

Finally, this draft includes adding access to local network information; as defined, this is potentially high entropy (as opposed to "Save-Data" which has only the "on" value) the "Downlink" header has (at least) 33 values in the cited Community Group report and user agents and can also reveal private network topology that might otherwise have been intentionally obscured.

Mitigations could include, as Mike suggests, asking users to opt in, although explaining the details to users may be difficult. Detectability could be improved by requiring that user agents only send client hint information in HTTP if the server has specifically requested it in an HTTP response header. Specifying that hints should not be sent to other origins on subrequests would limit the unintentional spread of this client information. At that point, however, it's not entirely clear how great the functional advantage is over using existing mechanisms (like client-side JavaScript access to user agent information and explicit HTTP cookies for managing preferences). Restricting values to a smaller enumerated range is mentioned, but the specification does not provide such an enumeration or recommend its use.

While I'm glad to see that there has been some discussion of active/passive fingerprinting and our draft on mitigating browser fingerprinting (https://github.com/httpwg/http-extensions/issues/215), I'm not sure those issues have been substantively resolved. That implementers could potentially implement a variety of mitigations is accurate, but if we consider which of those mitigations is necessary to prevent a marked harm to user privacy, we could include some mitigations in the design, such that UA/server implementation variation doesn't determine the outcome.

The first sentence of the Security Considerations section appears to be false.
> Client Hints defined in this specification do not expose new
>    information about the user's environment beyond what is already
>    available to, and can be communicated by, the application at runtime
>    via JavaScript and CSS.

Both the Downlink and Save-Data client hint, if broadly implemented, would likely reveal new information about the user's environment. Also, it's generally concerning when the first sentence of the Security Considerations section does not summarize the security or privacy issues of a specification but instead suggests to the casual reader that there's nothing to see here.

> However, implementors
>    should consider the privacy implications of various methods to enable
>    delivery of Client Hints - see "Sending Client Hints" section.

The Security Considerations section also refers to the Sending Client Hints section, but I don't understand the point it's trying to make. Is it just that user agents can use user preferences to decide whether to send client hints and could use that as a time to consider privacy implications?

Thanks,
Nick

> On Dec 3, 2016, at 1:58 AM, Mike O'Neill <[email-masked]> wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Dec 2016 10:14:17 -0500

> On 13 Dec. 2016, at 7:31 pm, Martin Thomson <[email-masked]> wrote:
> 

I think there's also an Option 4: extensions can only be defined by a sd-token, when it is defined. I.e., this extension syntax is for the use of future sd-tokens, not for arbitrary extension independent of them.

That's what I'd assumed when we defined the syntax; regardless of the intent, we should write something down about how the extension point is used.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 25 Dec 2016 15:47:31 -0500

Thanks, Nick.

A few responses below.

> On 13 Dec 2016, at 8:08 pm, Nick Doty <[email-masked]> wrote:
> 

Right. It seems like Security Considerations needs to be rewritten with this in mind; i.e., that fingerprinting which used to require active measures could now be performed passively. 

> Related, adding HTTP headers for subrequests, including to static resources, exposes client information to parties that previously would not have been able to access it, and in a way where the user…

In some cases, CH is necessary on sub requests for proper conneg; e.g. DPR and Width. In others, it could probably be restricted to the navigation request (e.g., Viewport-Width).

Ilya, I know we'd said that much of this could be handled in the Fetch integration, but could we have some high-level constraints on when it's to be sent in this spec?

> Finally, this draft includes adding access to local network information; as defined, this is potentially high entropy (as opposed to "Save-Data" which has only the "on" value) the "Downlink" header…

Save-Data is defined in terms of NetInfo's downlinkMax, which seems to be a double. Personally, I'd agree that having that much precision isn't terribly helpful.

Ilya, as an aside -- referring to NetInfo is going to be problematic; it will likely block publication. Can we make that non-normative (or ideally, drop it)?

> Mitigations could include, as Mike suggests, asking users to opt in, although explaining the details to users may be difficult.

That's already discussed in Security Considerations, although we could certainly expand it. Would you mind making text suggestions?

> Detectability could be improved by requiring that user agents only send client hint information in HTTP if the server has specifically requested it in an HTTP response header.

How do people feel about requiring Accept-CH before sending any CH? Right now it's implied, but we could raise this to a requirement.

> Specifying that hints should not be sent to other origins on subrequests would limit the unintentional spread of this client information. At that point, however, it's not entirely clear how great the functional advantage is over using existing mechanisms (like client-side JavaScript access to user agent information and explicit HTTP cookies for managing preferences). Restricting values to a smaller enumerated range is mentioned, but the specification does not provide such an enumeration or recommend its use.

It seems like candidates for that would be Width, Viewport-Width and Downlink (as discussed above).

AFAICT Width and Viewport-Width do not require pixel precision; would rounding to the nearest 10 be sufficient?