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

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

On Sun, Feb 12, 2017 at 9:52 PM, Mark Nottingham <mnot@mnot.net> wrote:

>
> > On 11 Feb 2017, at 9:04 pm, Ilya Grigorik <ilya@igvita.com> wrote:
> >
> > 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.
>
> Non-normative is better.
>
> >
> > > 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?
>
> 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 <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.
> >
> > ^ 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 <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.
> >
> > 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
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>