<christine> overview of API
<moneill2> +q
<christine> is API available in nesting browsing context?
yoav: opt-in: is based on a server header
<christine> answer: based on a server header - accept CH
yoav: which can be persisted.
<christine> (thanks Sam)
yoav: this opt-in is targetted only at the first party.
<npdoty> is any of this documented in the spec?
yoav: this is not hooked into the
permissions API because
... the capabilities in enables don't justify a permission
mikeoneill: there's still a fingerprinting risk
yoav: if you have 3rd party JS code on site, it can have access to that api.
<npdoty> if feature policy will allow "delegation" to send these headers to other origins, that's obviously substantial for privacy
yoav: if they're using that for FP< it will be active FP.
mike: but user wouldn't know
yoav: privacy sensitve browsers
could limit upper/lower bound of api
... right now very limited set of values. in privacy sensitive
context could be clamped down more.
mike: is that defined in the doc?
yoav: it was already clamped down much
<npdoty> > A full list of possible values is as follows: 0.25, 0.5, 1, 2, 4, 8
mike: FP can combine data from many sources
yaov: privacy-sensitive UAs can limit this even more
jason: I want to supprot mike's
point. this is the 2nd or 2rd acceptCH header that's come by
ping.
... they all seem to be revealing capabilities of the device,
so the page can be rendered more appropriately....
... network speed, storage space
<npdoty> if a suggested mitigation is limiting the data amounts further in certain browsers, it would be helpful to document that in the specification
jason: now this one.
... mike's point is this is one more piece, but AcceptCH seems
part of an bigger trend.
... why not have a a single "device class and year" instead of
piecemeal bits? you'll have many mroe devices in that
class.
... e.g. 2018 low/medium/high
Shubhie: we considered
that.
... signficant challenges: hard to be future-proof
... hard to get agreement between vendors
... i don't think we need storage. I think we need memory and
CPU.
<npdoty> memory and cpu and network information?
jason: I appreciate that it's
hard.
... we seem to be at an impasse where AcceptCH headers, instead
of doing the work to come up with device class, we instead
offlaod the privacy risk onto users.
... this seems wrong, on balance.
<npdoty> are there times when sending Save-Data will give me a different result than sending a small device memory or CPU header?
yoav: I think the other CH
headers are not about the device.... dpr gives you screen
resolution, viewport width
... width of image, which isn't about device.
... saved data, which is a user preference that varies over
time.
... other than device memory and network info API....
equivalence of the network info API ... which would be hard to
use for FP because they vary over time
... here we're exposing a small numebr of bits of info that
were relatively hard to get before.
jason: I appreciate your
perspective. I disagree re: aggregate FP risk given other
AcceptCH headers and how stable some of those are.
... may be a fundamental impasse.
yoav: examples?
jason: home wifi doesn't change
much. free space doesn't change much.
... it's small amount of entropy.
... it's worth discussing every one, because they add up.
yoav: no one is talking re: free space
jason: I think there is one.
<npdoty> if we had a list of every Client Hint proposal in one place, it might make this kind of analysis easer
mike: need to be concerned re:
info made avail to 3rd parties. esp. now that some browsers are
constraining 3rd party cookies, there will be more tendancy to
do other things.
... it will become more of an issue going fwd.
... this is only a few bits, but the totality of the situation
needs addressing.
... @@ browsers could add up the entropy, and let the user opt
out. we sould address thsi generally, not in indiv apis.
<jnovak> I was incorrect, there is not currently an accept-ch proposal for current space on device
yoav: I calim that regarding
overall CH headers, they don't change status quo. most headers
don't expose things not already available.
... in JS. this is similar to device memory. you could argue
that this is exposing new bits.
... but UA can trim them down.
<tara> weiler: I heard you say 1. it's hard to get this info otherwise and 2. you're not exposing things not readily available. This sounds contradictory.
<tara> Also: recommend suggestion to trim it down should be explicit.
<Zakim> npdoty, you wanted to comment on scope of access
<tara> Re: permissions workshop outcomes, we need to ask whether we need to be doing this at all? In general agreement about concerns about exposure.
<tara> npdoty: helpful to talk about mitigations and scope.
nick: I'm enjoying the
conversation. We're repeating some points from before. It might
be useful to talk re: mitigations and scope.
... I thought I heard earlier that this was supposed to only be
available to 1st party as opt-in, which is notably different
from availabel to third party
... and I don't think that's in the spec.
... and we need to talk re: CH in general. re: what scope
they'll be available in, and opt-in.
yoav: first party scoping is
mentioned in IETF doc on CH. I'm working on it re: fetch
integration of CH.
... we're working on adding feature policy to delegate this to
specific 3rd parties. in ways similar to 1st party changing,
e.g. URLs sent to image CDNs.
nick: @2, none of the docs you mentioned are in the references of the spec.
yoav: I'm noting that we need to open two bugs on spec: include refs to opt-in, and document UA limiting as an option
nick: that makes sense. might explain the implications in the spec.
yoav: it would be better to have a single location... but we should link to it.
mike: there's bigger risk with
request header data: it's much more efficient to collect bits
from request headers
... v. JS
... the problem w/ JS as 3rd parties is that cookies might be
blocked.
... we should be more cautious re: bits in request headers.
yoav: why?
<jnovak> the phrase I was thinking of earlier was "fingerprinting-defense-is-futile argument is an example of privacy defeatism"
mike: information in a request header has different implications than javascript, because of the lack of round-trip requests
jason: not only is it cheaper, it's harder to detect
+1 to jason
scribe: I like that there's a JS
option here... it allows for researchers etc. to survey web and
look for this FP.
... header makes this detection more difficult, which is a net
loss.
yoav: how so?
... opt in lets you see... privacy-aware modes could respect
the opt-in.
... just as they could lie to the JS APIs.
Shubhie: in the PWA store that's
served in india, they need to know early on which page to
serve.
... you can't ship a particular map, then query the JS, then
undo everything.
nick: it is useful to talk re:
the use case. the maps case is an interesting one. it's useful
to know early.... OTOH, you could send a small version by
default and upgrade later.
... if not every site is sending acceptCH, we can crawl the web
looking for that.
Yoav: re: the use case: it's true
that the first view won't get the CH headers... this is a use
case we haven't figured out how to solve in a
privacy-preserving way.
... followup navigation requests can get that if they use the
lifetime header.
<npdoty> and if we're not already getting it on the first request, then using client-side access could work in roughly the same method
Shubhie: i wonder, since we have people using this, if we can see if the JS will meet their needs (w/o the header)
yoav: I think the header and the JS API solve different use cases.
nick: image CDN won't get headers, right?
yoav: it will once we get 3rd party delegation in place...
nick: that works similarly to having first party change urls.
yoav; but that's not how image CDNs are currently deployed. opt-in can be barrier to adoption.
scribe: will make image loads
slower by requiring JS. will require more 3rd party JS, which
people on this call won't like.
... having headers provide data is critical to this use
case.
... I think it makes the priv/sec story better for those
CDNs.
nick: it would help the discussion to have those use cases documented.
yoav: ok.
<jnovak> aside: should we add to the questionnaire a question to the effect of "Does the specification provide use cases for this feature / the data exposed by this feature?"
<npdoty> image CDNs are not discussed in the spec's list of use cases, and wouldn't be able to take advantage of the header as it's currently designed anyway
christine: what are next steps? nick suggest use cases. we also talked re: mitigations.
Shubhie: should we have another call just re: AcceptCH - it feels like we're conflating two things.
<npdoty> I think it would be useful to have a conversation on Client Hints in general, yeah
<jnovak> +1 npdoty
<moneill2> +1
<npdoty> I think it would be great to think about what a progressive enhancement approach would be like for this device-class-switching mode
<npdoty> weiler: including documentation of when UAs can limit
<npdoty> weiler: have a future proofing issue anyway, since memory numbers will also change
<jnovak> fwiw, Facebook has already begun categorizing devices: https://code.fb.com/android/year-class-a-classification-system-for-android/
<npdoty> ... so what could we do in getting people interested in doing the kind of work about device descriptors in the future?
<npdoty> shubhie: could be a library written above these signals that we are exposing
<npdoty> ... but should the device class be exposed at the platform level?
<npdoty> weiler: concern that users who turn off javascript might expect to be protected from fingerpritning, but wouldn't in the case of opt-in client hint headers
christine: thank you to david, shubhie, & yoav
<npdoty> +1, thanks for coming and talking about it
<moneill2> +1
<jnovak> yes, thank you!
christine: let us know if we can be helpful as you continue the work.
yoav: I'll be at TPAC. happy to talk there.
tara: meeting Friday Oct 26 at TPAC.
<DavidC> Clarification. David is here for the VC WG and not the Device Memory API
tara: looking for agenda
items.
... apart from WebAppSec, no specific plans.
<moneill2> +q
DavidC: could we meet w/ VC WG? They've requested. They'd prefer Friday (11am?)
mike: general situation w/ FP
across APIs
... at permissions w/s talked re: how to gather info on how to
make prompts more user friendly.
... also, we're having a DNT post-mortem on Wed.
jason: the DNT thing isn't official. charter has expired; matthais did not get formal time. on plenary day, dave singer and myself are having an open discussion on Wed.
weiler: so maybe talk re: AcceptCH? and also report on permissions w/s.
nick: can we have remote participation?
tara: we've requested a polycom.
weiler: it's still nine hours off...
jason: by tpac, we should have all of ping's edits merged into the questionnaire. working w lukasz on Wednesday.
<npdoty> right, I'll try to talk to tara/christine about how to schedule time on Friday so that I can participate in some sessions not in the middle of the night :)
jason: maybe talk about how that effort went and where to go from here.
christine: thank you jason for driving that.
<npdoty> or could we coordinate joint time for Client-Hints discussion on Friday?
yoav: re: tpac: friday collides with WebPerformance WG, and many Client Hints people are in that. If we have that discussion, it would be good to do it as a breakout.
jason: would we have enough
people ... could we schedule a 1 hr cross-mtg on Friday?
... or on Thurs, do with (with limited PING represenation)?
<xiaoqian> WebPerf Agenda for TPAC https://docs.google.com/document/d/1bYMLTkjcyOZR5Jt3vrulzMSoS32zOFtwyH33f6hW_C8/edit
yoav: if I look at WbPerf WG schedule: finding a free hour would be hard on Th or Fri. strongly prefer a Wed breakout.
jason: welcome add'l participants
on questionnaire.
... thanking Nick and others on that small group working
through the edits.
christine: I will not be at TPAC;
Tara, Sam, and Wendy will.
... thanks again to our guests.
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/keyboard width/viewport width/ Succeeded: s/@@@/dpr/ Succeeded: s/@3/information in a request header has different implications than javascript, because of the lack of round-trip requests/ Succeeded: s/@5/PWA store/ Succeeded: s/so /no / Succeeded: s/it/questionnaire/ Present: tara weiler moneill2 wseltzer xiaoqian Shubhie No ScribeNick specified. Guessing ScribeNick: weiler Inferring Scribes: weiler WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 11 Oct 2018 People with action items: 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.)[End of scribe.perl diagnostic output]