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

 

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

 

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)

 

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

 

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 <mailto:mnot@mnot.net> > wrote:

Hey Nick,

> On 13 Feb 2019, at 1:16 pm, Nick Doty <npdoty@ischool.berkeley.edu <mailto:npdoty@ischool.berkeley.edu> > wrote:
> 
> On Feb 12, 2019, at 4:06 PM, Mark Nottingham <mnot@mnot.net <mailto: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