Privacy Interest Group Teleconference -- 11 Oct 2018

<christine> overview of API

Device Memory 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> https://freedom-to-tinker.com/2018/06/29/against-privacy-defeatism-why-browsers-can-still-stop-fingerprinting/

<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.

TPAC

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.

- DRAFT -

Privacy Interest Group Teleconference

11 Oct 2018

Attendees

Contents

Device Memory API

TPAC

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output