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

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

> Hi Ilya,
>
> 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


> Cheers,
>
>
>
> > On 25 Feb 2017, at 4:39 am, Ilya Grigorik <ilya@igvita.com> wrote:
> >
> > 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/
> >
> >
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>