<mikeoneill> +present

<jnovak> scribenick: jnovak

tara: today's call is looking at migrating high entropy HTTP Headers to Client Hints
... first AOB?
... if not, links to IRC

<tara> https://discourse.wicg.io/t/proposal-migrate-some-high-entropy-http-request-headers-to-client-hints/3132/7

<tara> https://github.com/w3ctag/design-reviews/issues/320

<tara> https://github.com/WICG/lang-client-hint

<tara> https://github.com/WICG/ua-client-hints

tara: this item has been on various reviews: TAG, WICG
... going through review and the incubator group flagged for me
... talking about getting eyes on some of these items in before they get late stage
... so in touch with folks from TAG side and WICG to say we are wiling and available to look at things earlier in the review state
... this is the first one that we got so thought could get feedback at a more useful stage of process
... don't have mike on the call because this is less formal
... idea is what it says on the tin -- there's information exposed in plain text, suggestion is to provide only on request and over secure transport
... split up UA into version, model, platform

<tara> q/

jnovak: see mkwst in IRC but not on call
... wanted to confirm

weiler: confirmed not on call

tara: may be IRC ghost

mikeoneill: way I understand client hints, it's an IETF governed thing.
... the privacy risk is that it is connected with what's being used by third parties or not
... third party / embedded third party on a website
... push it into the auspices of W3C
... from PING point of view need to look at feature policy add on as well
... as it provides fine grained control
... but this isn't in the main text yet
... important to note that the opt-in is by the site but the user
... should there be some user control?
... some wording somewhere (Security section of IETF) that user agent should take control over whether or not it gives user control over it.
... as we have future tie up between feature policy and client hints, that should be referred to somewhere as well
... there should be a ban of client hints for third parties

<Zakim> npdoty, you wanted to comment on user control

From https://github.com/WICG/ua-client-hints

Other PRs for adding the Feature Policy 3rd party opt-in: whatwg/fetch#811 and wicg/feature-folicy#220

Other PRs for adding the Feature Policy 3rd party opt-in: whatwg/fetch#811 and wicg/feature-folicy#220

Other PRs for adding the Feature Policy 3rd party opt-in: whatwg/fetch#811 and wicg/feature-folicy#220

Other PRs for adding the Feature Policy 3rd party opt-in: whatwg/fetch#811 and wicg/feature-folicy#220

npdoty: think the current draft is similar to what mikeoneill is suggesting in terms of user control
... mkwst gives example of giving platform only for downloads
... don't need all the subfields of the user agent field
... if we move this out of the header we send on ever request then can provide some discretion

<tara> Jnovak: feature policy is live (see above links) and active; do we want to add language here?

<christine> feature policy and 3rd parties - feature policy is live and being worked on - do we PING want to add language there or browsers can elect to ignore 3rd party requests at their discretion

<christine> don't want to side-track conversation, come back to later

<weiler> scribenick: weiler

jnovak: several pieces of UA string that get broken up into different CHs. Not clear to me that all of them should be exposed: 1) they create entropy risk and 2) to web platform independence - looking at both archecture and model, these have ... regardless of platform/browser, I wonder if that leads to non-interoperability in addition to privacy risk

<pes> pes+

moneill: implemented in safari?

<npdoty> yeah, revealing the specific model of phone that I’m using seems very specific/invasive

jnovak: no.

moneill: RFC@@ says you should optionally use @2
... the CH RFC...
... section 2.1 , first paragraph....

<npdoty> Mike, can you share a URL? there are a lot of pieces moving in parallel

<jnovak> https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-05

<npdoty> 06 is more recent than that

<npdoty> https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-06

https://tools.ietf.org/html/draft-ietf-httpbis-client-hints-05#section-2.1

scribe: should they take the "optionally" out?

<npdoty> discretion on sending UA client hints is also specifically discussed here: https://tools.ietf.org/html/draft-west-ua-client-hints-00#section-3.3

tara: was Mozilla involved?

npdoty: they've been pretty skeptical of CH in the past, but they've said some positive things here.

pes: would be good to have a common position re: logging, since these wind up in logs.

npdoty: CH v. current UA header?

pes: no... @3....

npdoty: CH has a larger set of privacy q's. we've raised concerns re: passive content. I haven't heard the suggestion re: logging. that would be a new issue to raise.

pes: +1

npdoty: back to Jason's comment re: device model... is that info currently being disclosed somehow?
... I'm concerned about "this website only runs on these devices"
... seems scary

tar: do yu mean limited # of devices raising identifiability?

npdoty: no, this is more about interop.

moneill: is this something for the TAG?

jnovak: risk of privacy loss for questionable gain. I don't think Firefox exposes architecure or device type. Safari exposes desktop or mobile, and that's pretty much it.

christine: re: logging, i wonder if nick and pete could figure out some working to put fwd. we're interested in privacy; tag in interop; need to figure out how to communicate concerns.

pes: I'm not sure I have language to suggest - just general suggestions to authors e.g. "what do you plan to do about this"

sam: did TAG look at this Tuesday? what did they say?

<jnovak> https://github.com/w3ctag/design-reviews/issues/320#issuecomment-460926256

<npdoty> I think we could add to httpwg github issues on the Client-Hints topics more generally, since I think pes concern is not specific to this User-Agent/Lang piece

sam: so they thumbs-up'ed w/ no interop concerns?

<pes> npdoty: yes 100% agree on above

mike: I heard something about waiting to see re: feature policy and 3rd party.
... think it's a shame that we have CH in IETF, Feature Policy here, and permissions somewhere. I wish this were all tied together.
... I wonder how we can have a discussion. they didn't come up in the Permissions w/s. how can get a discussion going in one place?

<npdoty> I think the conversation is already happening across IETF and W3C, with a lot of overlap of people, fwiw

<npdoty> I don’t think the TAG review went into that much detail on the interop specifics, they just support the fingerprinting limitation

pes: I think interop is important but not our remit. i have idea re: logging... anything else re: privacy, fingerprinting?

nick: on privacy Q, and with interop, the Q is which fields we really need.
... for UA, we have 4-6 sub-fields. made we need a way to evaluate if a subfield is needed or not. uses cases not clear. if we're not getting something useful, why give away the underlying architecture?

pes: as in, ask them for motivating examples?

nick: could be. or ask for data collection on how UA is being used?
... seems reasonable

pes: we should be careful not to take on their responsibility - we can ask them to show us the data.

sam: seems like nick was being more abitious...

nick: if we can set of criteria, that would be great.

christine: might be 2-step. first see what they have to say, then criteria. I'm nervious about us saying "it's okay in these cases". I'm okay with saying "not okay in X".

<npdoty> I think in some ways we are talking about the severity factors listed here: http://w3c.github.io/fingerprinting-guidance/#identifying-fingerprinting-surface-and-evaluating-severity

<npdoty> we’ve already talked about detectability with the server-side opt-in

mike: if headers are being seen by 3rd parties - 100's of them - @5 . they shouldn't be aavailable to 3rd partites. there's no way for user to determine who 3rd parties are. that's dangerous - a privacy risk.

<npdoty> and mikeoneill is raising the question of availability and scope (to which parties, and whether there is permission)

mike: Feature Policy is in WebAppSec - should we attend it? have a session on privacy ?

sam: suggest it to webappsec chairs

pranjal: have there been discussions re: dropping support on JS APIs that leak similar info?

nick: more specific?

pranjal: navigator, user agent... any discussion to limit this out of JS.

moneill: I've seen some.

<npdoty> mkwst is specifically suggesting that we freeze the js properties for navigator.platform, etc. and create new methods to match the new client hints

sam: some general discussion at tpac re: preferring JS versions, since they're easier to detect

<pranjal> npdoty: the suggestions that I see on the github issues was limiting it to secure contexts, but the JS APIs will be available for use. Let me know if that's incorrect

jason: at tpac, discussed that there's a a change in CH so that server had to .@5 to make detection easier? (scribe: is that right?)

<npdoty> pranjal, yes, he is suggesting that there would be a JS api available

<jnovak> jnovak: my recollection of TPAC is, roughly, that the argument was that CH was now, with the opt-in and FP delegation, equivalently observable to JS API

<npdoty> yes, the Client-Hints proposals have been updated for server-side opt-in, which has the effect of observabilty by researchers

<npdoty> pranjal, do you have next steps or questions about the JS piece?

<npdoty> pes, what were the two? (I only heard one)

<pes> npdoty: 1) logging, 2) data motivagin these headers

<pranjal> The only remaining question would be if there were any specific concerns deprecating the JS APIs completely

tara: pranjal, how would you like that addressed
... ?

pranjal: I'll browse GH issues and open a new one if needed.

tara: thanks all!

jnovak: lucas was at TAG mtg this week - sec & privacy questionaire got some specific feedback. Not sure of next steps. Might be another call.

<Zakim> christine, you wanted to discuss next call

<npdoty> there was a request to get some permissions guidance into the questionnaire, maybe based on our workshop

christine: we have a request for feedback on request payment api. can we do that on 28 Feb?

<pes> WFM

<pranjal> +1

pes: private browsing mode: I think I've addressed all Q's sent my way. I can restart thread on mailing list re: next steps.

<npdoty> tara, christine, do we have a schedule on Note publication for mitigating fingerprinting guidance?

christine: thanks pete. send another email.
... i think it's get a Q of getting peoples' attention.

tara: no schedule yet.

<pes> thanks ya’ll!

tara: thanks all. see you on Feb 28th. do your background reading.

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/auspicious/auspices/
Succeeded: s/second/section/
Succeeded: s/Moz/Mozilla/
Succeeded: s/FP/Feature Policy/
Succeeded: s/rading/reading/
Succeeded: s/28th/Feb 28th/
Present: jnovak tara pranjal christine pes mikeoneill npdoty
Found ScribeNick: jnovak
Found ScribeNick: weiler
Inferring Scribes: jnovak, weiler
Scribes: jnovak, weiler
ScribeNicks: jnovak, weiler

WARNING: No "Topic:" lines found.


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)