W3C home > Mailing lists > Public > public-privacy@w3.org > January to March 2017

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

From: Nick Doty <npdoty@ischool.berkeley.edu>
Date: Mon, 6 Feb 2017 16:42:33 -0800
Cc: Ilya Grigorik <ilya@igvita.com>, HTTP working group mailing list <ietf-http-wg@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Message-Id: <EEB185E5-BC2E-47AB-BDB2-C5ABDDA9EB19@ischool.berkeley.edu>
To: Mark Nottingham <mnot@mnot.net>
On Feb 2, 2017, at 5:27 PM, Mark Nottingham <mnot@mnot.net> wrote:
> On 3 Feb 2017, at 10:30 am, Nick Doty <npdoty@ischool.berkeley.edu> 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?
>> A draft of text that could be added to the mechanisms/mitigations paragraph:
>>> Implementers may
> 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.

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

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.

>>>>> 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.
> +1

Received on Tuesday, 7 February 2017 00:43:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 7 February 2017 00:43:12 UTC