Re: Request for help on follow up items from the last call

Thanks, Mike!

On Thu, Feb 14, 2019 at 12:29 PM <michael.oneill@baycloud.com> wrote:

> I think a lot of the confusion comes from having to read different docs,
> the IETF RFCs and W3C (mainly FP).
>

The nice thing about having primitives is that you can compose them. The
bad thing about compositions is that you have to understand all the
primitives. :/


> The main fingerprinting risk IMO comes from the ability of subresources to
> request it, and the original CH RFC just said the opt-in was optional i.e.
> 2.1 in:
>
> https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-06
>
> The opt-in is in the issues discussion about FP but not yet in the
> published draft, though the issue is mentioned in 9.12
>
> https://w3c.github.io/webappsec-feature-policy/
>
>
>
> Your  RFC covering language headers:
>
> https://tools.ietf.org/html/draft-west-lang-client-hint-00
> <https://tools.ietf.org/html/draft-west-lang-client-hint-00#section-3.1>
>
> is much better as it has the paras about delegation (3.2) and Access
> restrictions (3.3)
>

I agree that Client HInts itself is in a confusing state.

AFAICT, there are several clarifying PRs against HTML and Fetch that the
folks working on Client Hints have had a hard time landing (the list at
https://github.com/WICG/lang-client-hint#wait-a-minute-i-dont-see-this-delegation-stuff-in-the-client-hints-spec
was, at one point, exhaustive). I believe the current plan is for +Yoav
Weiss <yoavweiss@google.com> to put together a single document full of
monkey-patches against HTML and Fetch so that we can have a conversation
about what the state they're intending to land on.

Does the existing Chromium implementation block subresources from using CH
> now, or does it already support the upcoming FP opt-in?
>

+Yoav Weiss <yoavweiss@google.com> and/or +Ilya Grigorik
<igrigorik@google.com> will know things about Chromium's current state. I
do know that implementation of the Feature Policy integration is only just
kicking off this quarter.

-mike


>
>
> Thanks,
>
>
>
> Mike
>
>
>
>
>
> *From:* Mike West <mkwst@google.com>
> *Sent:* 14 February 2019 07:46
> *To:* Mark Nottingham <mnot@mnot.net>
> *Cc:* Nick Doty <npdoty@ischool.berkeley.edu>; Pete Snyder <
> psnyder@brave.com>; public-privacy (W3C mailing list) <
> public-privacy@w3.org>
> *Subject:* Re: Request for help on follow up items from the last call
>
>
>
> On Thu, Feb 14, 2019 at 8:18 AM Mark Nottingham <mnot@mnot.net> wrote:
>
> Hey Nick,
>
> > On 13 Feb 2019, at 1:16 pm, Nick Doty <npdoty@ischool.berkeley.edu>
> wrote:
> >
> > On Feb 12, 2019, at 4:06 PM, Mark Nottingham <mnot@mnot.net> wrote:
> >>
> >> Such general questions are more appropriate on the mailing list because
> the working group needs to keep some discipline over its issues list. If
> issues were a way for people to ask for general / background information on
> our specs, our issues list would quickly become unfit for its primary
> purpose -- discussing issues with the specifications we're developing. In
> particular, I (as WG chair) have a strong interest in protecting my editors
> (who are inevitably time-poor) from an overly large issues list, as that
> tends to remove their motivation to contribute.
> >
> > I believe on our last call we (PING) had specifically directed Pete to
> raise GitHub issues list because some WGs seem to have an increasingly
> strong preference for feedback via GitHub (and I believe the other issue
> opened is more specific). However, I do think discussing the motivating
> data on Clients-Hints usage on the mailing list would be preferable if
> HTTPWG is open to it, since it is more of a general topic.
> >
> > So, thanks Mark for the re-direction and thanks Pete for following up to
> get the question to the right place.
> >
> > The other part of my interest for background/motivating data was around
> the `User-Agent` and `Lang` replacements specifically. If we understood the
> particular use cases for different parts of a User-Agent string, we could
> do a better job evaluating what should (or shouldn’t) be exposed where.
> That’s more specific to Mike West’s proposed draft, and I don’t know if
> there is a WG discussing that yet or not. What's the right venue for
> discussion of that?
>
> That's a good question. Mike seems to be straddling his personal repo,
> WICG and HTTP-WG for those, and it's not clear where they'll land, so you
> might want to ask him.
>
>
>
> A small correction: none of this is in a personal repo anymore. :)
>
>
>
> For more detail than you probably want:
>
>
>
> * WICG adopted the work in
> https://discourse.wicg.io/t/proposal-migrate-some-high-entropy-http-request-headers-to-client-hints/3132/12,
> and that's where the proposals currently live. (This is the path proposals
> from Chromium contributors generally take: personal repository -> get
> enough people interested to justify moving to WICG -> WICG for incubation
> -> W3C/WHATWG/IETF for standardization).
>
>
>
> * I submitted IDs to the IETF, as that's where the headers I'd like to
> replace are defined, and discussed them in the HTTPWG. My understanding of
> the way that discussion ended is that folks would prefer that the CH
> infrastructure remain in the IETF, but that I move these specific
> definitions to the HTML and Fetch specifications in the WHATWG (see
> https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0008.html
> and https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0079.html,
> for example). I plan to send out PRs to those specifications once I'm
> confident that the design is reasonable and implementable.
>
>
>
> * To that end, I'm putting together a first pass at an implementation of
> both hints in Chromium (you can follow along via the bugs linked from
> https://crbug.com/924047, if you're curious; `Sec-CH-Lang` and a
> half-finished JS implementation of the user agent bits and pieces are
> currently behind a flag).
>
>
>
> * For completeness, there's also been some discussion at
> https://discourse.wicg.io/t/proposal-migrate-some-high-entropy-http-request-headers-to-client-hints/3132/,
> in the TAG at
> https://github.com/w3ctag/meetings/blob/gh-pages/2019/02-tokyo/02-06-minutes.md#topic-client-hints
> and https://github.com/w3ctag/design-reviews/issues/320, and
> https://github.com/mozilla/standards-positions/issues/79.
>
>
>
> I feel like I've been pretty public about this, and pretty active in
> soliciting feedback. If there's a venue I missed, I'd love y'all's help
> finding it. As I mentioned in my previous email
> <https://lists.w3.org/Archives/Public/public-privacy/2019JanMar/0042.html>,
> I'm happy to talk about these specific proposals wherever you like. Issues
> filed against https://github.com/WICG/ua-client-hints and
> https://github.com/WICG/lang-client-hint are fine, but if y'all have a
> preferred venue for specific privacy discussions, I'm happy to join y'all
> there. :)
>
>
>
> -mike
>