Resent-Date: Mon, 13 Feb 2017 05:52:56 +0000
Resent-Message-Id: <E1cd9ZI-0003Up-MN@frink.w3.org>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAKRe7JEqUr6Xryo7GaVGA5hT2MB+krOEiDJdKQLdkwGAEgxpgg@mail.gmail.com>
Date: Mon, 13 Feb 2017 16:52:10 +1100
Cc: Nick Doty <npdoty@ischool.berkeley.edu>,
 HTTP working group mailing list <ietf-http-wg@w3.org>,
 "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EAD963A1-8390-4771-B254-B4415467DD6C@mnot.net>
References: <148070210225.29664.2630836091018103593.idtracker@ietfa.amsl.com>
 <15ba01d24d4b$bbd65ec0$33831c40$@baycloud.com>
 <AEB52D75-E794-468E-B954-E57A63C6EB3D@ischool.berkeley.edu>
 <F4E8AD6F-2981-440D-9D1F-09A5D361FD6A@mnot.net>
 <7AE1C62F-3899-412E-8EB3-062FDC8CFEEF@mnot.net>
 <224212CF-7955-4F83-A194-C33BC9F0A139@ischool.berkeley.edu>
 <3E5E3BDC-3257-44CA-B1C0-2648823AF492@mnot.net>
 <EEB185E5-BC2E-47AB-BDB2-C5ABDDA9EB19@ischool.berkeley.edu>
 <CAKRe7JEqUr6Xryo7GaVGA5hT2MB+krOEiDJdKQLdkwGAEgxpgg@mail.gmail.com>
To: Ilya Grigorik <ilya@igvita.com>
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net;
 helo=mxout-07.mxes.net
Subject: Re: I-D Action: draft-ietf-httpbis-client-hints-03.txt
Archived-At: <http://www.w3.org/mid/EAD963A1-8390-4771-B254-B4415467DD6C@mnot.net>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list


> On 11 Feb 2017, at 9:04 pm, Ilya Grigorik <ilya@igvita.com> wrote:
>=20
> Hey all, apologies about the (super) delayed response!=20
>=20
> Re, Accept-CH: =
https://github.com/httpwg/http-extensions/issues/284#issuecomment-27913328=
7
>=20
> > 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)?
>=20
> I'd prefer to keep the (non-normative) reference if possible.. let me =
know.

Non-normative is better.

>=20
> > AFAICT Width and Viewport-Width do not require pixel precision; =
would rounding to the nearest 10 be sufficient?
>=20
> 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.


>=20
> On Thu, Feb 2, 2017 at 3:30 PM, Nick Doty =
<npdoty@ischool.berkeley.edu> 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.=20
>=20
> ^ tried to merge the comments from above -- yay/nay? As an aside, we =
should probably move the wordsmithing into GitHub? :)
>=20
> We can update section 2.1 to cover the above.
> =
https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-03#section-2.1=

>=20
> --
>=20
> Did I miss anything?
>=20
> ig
>=20
>=20
>=20
> On Mon, Feb 6, 2017 at 4:42 PM, Nick Doty =
<npdoty@ischool.berkeley.edu> wrote:
> 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.
>=20
> Sure. I like "might" for that, but whatever is your group's preferred =
way to indicate conditionality without RFC2119 status is fine by me.
>=20
> >> 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)?
>=20
> 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.
>=20
> >> Implementers should be aware that explaining the privacy =
implications of passive fingerprinting or network information disclosure =
may be challenging.
> >
> > How is this actionable?
>=20
> 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.
>=20
> >>>>> 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
>=20

--
Mark Nottingham   https://www.mnot.net/