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

Hi Mike,

Apologies if this is fragmenting the conversation from GH, but hoping for any clarification you could provide on the following:

Can origins delegate to third parties with “*”?

If so, this seems scary and likely to become stack-overflow-advice for how to make things work, which would be a very-likely, privacy-scary scenario. Do you think the CH folks be amenable to removing this option, and requiring a delineated max-size'd list of FQDN’s? (Apologies if this is answered elsewhere, but I don’t see an issue or similar open on the topic, or it addressed in threads / specs I can find).

Thanks again!
Pete

> On Feb 14, 2019, at 3:43 AM, Mike West <mkwst@google.com> wrote:
> 
> 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
> 
> 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 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 and/or +Ilya Grigorik 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, 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
>

Received on Tuesday, 26 February 2019 00:36:53 UTC