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

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