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

From: Nick Doty <[email-masked]>
Date: Thu, 2 Feb 2017 15:30:24 -0800

Thanks, Mark, for following up with a nudge. (CC public-privacy@w3c)

> On Jan 30, 2017, at 11:27 PM, Mark Nottingham <[email-masked]> wrote:
> 
> It's been a month, and there haven't been any responses to the suggestions below. We're really close to shipping this spec, can we please get it over the line?
> 
> I've nominated stuckees below...
> 
> Cheers,
> 
>> On 26 Dec 2016, at 7:47 am, Mark Nottingham <[email-masked]> wrote:
>> 
>> Thanks, Nick.
>> 
>> A few responses below.
>> 
>>> On 13 Dec 2016, at 8:08 pm, Nick Doty <[email-masked]> wrote:
>>> 
>>> 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.
>> 
>> 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.
> 
> Ilya, do you want to attempt a revision here? Would you like some help?

(One suggestion for the intro at the bottom of this message.)

>>> 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.
>> 
>> 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?
> 
> Ilya? There seem to be some similarities with <https://github.com/httpwg/http-extensions/issues/156 <https://github.com/httpwg/http-extensions/issues/156>> here.
> 
>>> 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.
>> 
>> 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)?
> 
> Ilya?
> 
>>> 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?
> 
> Nick?

A draft of text that could be added to the mechanisms/mitigations paragraph:

> Implementers may provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. Implementations specific to certain use cases or threat models might avoid transmitting these headers altogether, or limit them to authenticated sessions. Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging.

I think mitigations regarding detectability (for example, requiring Accept-CH below) won't lend themselves very well to user choice mechanisms -- detection is a mitigation against fingerprinting that isn't limited to an individual user; all users benefit when it's easier for researchers or policymakers to detect the use of unsanctioned tracking mechanisms.

>>> 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.
> 
> Anyone? Raised as <https://github.com/httpwg/http-extensions/issues/284 <https://github.com/httpwg/http-extensions/issues/284>>

I've followed up on that Github issue; such a requirement would be a privacy benefit not only in terms of minimizing data but also in terms of increasing the detectability of fingerprinting, which is one of the more important client fingerprinting mitigations.

>>> 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?
> 
> Ilya?
> 
>>> 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.

Presumably this could be addressed in re-writing the Security Considerations section. A potential start to that section:

Client Hints defined in this specification may expose information about user's devices or network connections and include information in HTTP headers that may previously have been accessible through client-side scripting. Implementers should be aware of implications for new information disclosure, information disclosure to different parties and for the increased capacity for passive fingerprinting.

>>> 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:
>>>> 
>>>> 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.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 3 Feb 2017 12:27:28 +1100

On 3 Feb 2017, at 10:30 am, Nick Doty <[email-masked]> wrote:

> > Implementers may

might? Otherwise people could read it as MAY.

> provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. Implementations specific to certain use cases or threat models might avoid transmitting these headers altogether, or limit them to authenticated sessions.

s/authenticated sessions/secure contexts/ (or whatever the current terminology is)?

> Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging. 

How is this actionable?

> Client Hints defined in this specification may expose information about user's devices or network connections and include information in HTTP headers that may previously have been accessible throug…

+1

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

---

From: Nick Doty <[email-masked]>
Date: Mon, 6 Feb 2017 16:42:33 -0800

> might? Otherwise people could read it as MAY.

Sure. I like "might" for that, but whatever is your group's preferred way to indicate conditionality without RFC2119 status is fine by me.

> s/authenticated sessions/secure contexts/ (or whatever the current terminology is)?

I actually meant that the UA might want to distinguish between when they know a user is logged-in or otherwise already identified to a site, rather than over a secure HTTPS channel.

>> Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging.

I meant this as a warning or limitation on the use of user choice as a mitigation. Given this challenge, implementations ought to rely on other mitigations unless informed user choice really seems plausible for their population.

---

From: Ilya Grigorik <[email-masked]>
Date: Sat, 11 Feb 2017 02:04:08 -0800

Hey all, apologies about the (super) delayed response!

Re, Accept-CH:
https://github.com/httpwg/http-extensions/issues/284#issuecomment-279133287

> 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)?
>

I'd prefer to keep the (non-normative) reference if possible.. let me know.

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

Pixel precision is available via JS. I don't see why we'd impose an
arbitrary rule here to round it here?

On Thu, Feb 2, 2017 at 3:30 PM, Nick Doty <[email-masked]>
 wrote:

> > Implementers might provide user choice mechanisms so that users may
> balance privacy concerns with bandwidth limitations. Implementations
> specific to certain use cases or threat models might avoid transmitting
> these headers altogether, or limit them to secure contexts or authenticated
> sessions. Implementers should be aware that explaining the privacy
> implications of passive fingerprinting or network information disclosure
> may be challenging.

^ tried to merge the comments from above -- yay/nay? As an aside, we should
probably move the wordsmithing into GitHub? :)

We can update section 2.1 to cover the above.
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-03#section-2.1

--

Did I miss anything?

ig

On Mon, Feb 6, 2017 at 4:42 PM, Nick Doty <[email-masked]>
wrote:

> >>>>> 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?
> >>>
> >>> Nick?
> >>
> Sure. I like "might" for that, but whatever is your group's preferred way
> to indicate conditionality without RFC2119 status is fine by me.
>
> >> provide user choice mechanisms so that users may balance privacy
> concerns with bandwidth limitations. Implementations specific to certain
> use cases or threat models might avoid transmitting these headers
> altogether, or limit them to authenticated sessions.
> >
> I actually meant that the UA might want to distinguish between when they
> know a user is logged-in or otherwise already identified to a site, rather
> than over a secure HTTPS channel.
>
> >> Implementers should be aware that explaining the privacy implications
> of passive fingerprinting or network information disclosure may be
> challenging.
> >
> > How is this actionable?
>
> I meant this as a warning or limitation on the use of user choice as a
> mitigation. Given this challenge, implementations ought to rely on other
> mitigations unless informed user choice really seems plausible for their
> population.
>
> >> Presumably this could be addressed in re-writing the Security
> Considerations section. A potential start to that section:
> >>
> >> Client Hints defined in this specification may expose information about
> user's devices or network connections and include information in HTTP
> headers that may previously have been accessible through client-side
> scripting. Implementers should be aware of implications for new information
> disclosure, information disclosure to different parties and for the
> increased capacity for passive fingerprinting.
> >
> > +1
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 13 Feb 2017 16:52:10 +1100

> On 11 Feb 2017, at 9:04 pm, Ilya Grigorik <[email-masked]> wrote:
> 
> Re, Accept-CH: https://github.com/httpwg/http-extensions/issues/284#issuecomment-279133287
> 

Non-normative is better.

> Pixel precision is available via JS. I don't see why we'd impose an arbitrary rule here to round it here?

The motivation was to avoid promoting active fingerprinting (via JS) into passive fingerprinting (in a header), by reducing the resolution of the data. Of course, if we do decide to require Accept-CH (at least for these headers), that seems like it would address it too.

> 
> On Thu, Feb 2, 2017 at 3:30 PM, Nick Doty <[email-masked]> wrote:
> > Implementers might provide user choice mechanisms so that users may balance privacy concerns with bandwidth limitations. Implementations specific to certain use cases or threat models might avoid transmitting these headers altogether, or limit them to secure contexts or authenticated sessions. Implementers should be aware that explaining the privacy implications of passive fingerprinting or network information disclosure may be challenging. 
> 
> ^ tried to merge the comments from above -- yay/nay? As an aside, we should probably move the wordsmithing into GitHub? :)
> 
> On Mon, Feb 6, 2017 at 4:42 PM, Nick Doty <[email-masked]> wrote:

---

From: Ilya Grigorik <[email-masked]>
Date: Fri, 24 Feb 2017 09:39:27 -0800

PTAL: https://github.com/httpwg/http-extensions/pull/305

On Sun, Feb 12, 2017 at 9:52 PM, Mark Nottingham <[email-masked]> wrote:

> > > 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)?
> >
> The motivation was to avoid promoting active fingerprinting (via JS) into
> passive fingerprinting (in a header), by reducing the resolution of the
> data. Of course, if we do decide to require Accept-CH (at least for these
> headers), that seems like it would address it too.
>
>
> >
> > ^ tried to merge the comments from above -- yay/nay? As an aside, we
> should probably move the wordsmithing into GitHub? :)
> >
> > >>>>> Mitigations could include, as Mike suggests, asking users to opt
> in, although explaining the details to users may be difficult.
> > >>>>
> > Sure. I like "might" for that, but whatever is your group's preferred
> way to indicate conditionality without RFC2119 status is fine by me.
> >
> > >> Client Hints defined in this specification may expose information
> about user's devices or network connections and include information in HTTP

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 27 Feb 2017 16:24:25 +1100

Hi Ilya,

Looks good; I left a few editorial-ish notes in the pull request.

How do others feel? Note that (as I mentioned in an issue just now), I think our role here is to define the protocol elements and the potential privacy/security impact of using them, not to detail exactly how Web browsers are to use them. That's specified in the Fetch spec, and should happen over there. Make sense?

Ilya -- I also see this happening over at NetInfo: <https://github.com/WICG/netinfo/issues/46>. Is that something that we should be including here, or is it too early? How likely is it that it will deprecate Downlink?

Cheers,

> On 25 Feb 2017, at 4:39 am, Ilya Grigorik <[email-masked]> wrote:
>

---

From: Ilya Grigorik <[email-masked]>
Date: Sun, 26 Feb 2017 21:47:21 -0800

> Looks good; I left a few editorial-ish notes in the pull request.

Thanks! Followed up on the PR.

> Ilya -- I also see this happening over at NetInfo: <
> https://github.com/WICG/netinfo/issues/46>. Is that something that we
> should be including here, or is it too early?

Still under active discussion.. Personally, I don't think we need to
include those in CH. They do reference CH and there is discussion about
using Accept-CH, but that's all fine. If we need to, we can always craft
separate specs for those later.

> How likely is it that it will deprecate Downlink?
>

Good question.. not sure. I think we need some operational experience to
figure that out.

Perhaps a more relevant one to consider is:
https://github.com/WICG/netinfo/issues/47.

ig

> > > > 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)?
> > >
> > > > AFAICT Width and Viewport-Width do not require pixel precision;
> would rounding to the nearest 10 be sufficient?
> > >
> > The motivation was to avoid promoting active fingerprinting (via JS)
> into passive fingerprinting (in a header), by reducing the resolution of
> the data. Of course, if we do decide to require Accept-CH (at least for
> these headers), that seems like it would address it too.
> >
> >
> > >
> > > I actually meant that the UA might want to distinguish between when
> they know a user is logged-in or otherwise already identified to a site,
> rather than over a secure HTTPS channel.
> > >
> > > >> Implementers should be aware that explaining the privacy