Minutes [was: Re: Request Privacy Review of Device Memory]

Record for the call of this privacy review is available at
https://www.w3.org/2018/10/11-privacy-minutes.html

also in plain text below.

Many thanks to the Privacy IG, Shubhie and Yoav.

-------------
Privacy Interest Group Teleconference
11 Oct 2018
Attendees
Present
tara, weiler, moneill2, wseltzer, xiaoqian, Shubhie
Regrets
Chair
SV_MEETING_CHAIR
Scribe
weiler
Contents
Topics
Device Memory API
TPAC
Summary of Action Items
Summary of Resolutions
<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.

Summary of Action Items
Summary of Resolutions
[End of minutes]

On 2018-10-01 02:49, Jason A. Novak wrote:
> Great. And just to help PING coordinate, when are you looking for
> feedback by?
> 
> Our next meeting is on October 4th; Tara and Christine can speak to
> whether we have time in that meeting to have an internal discussion
> regarding this specification and consolidate comments.
> 
> J
> 
> On Sep 30, 2018, at 1:45 PM, Yoav Weiss <yoav@yoav.ws> wrote:
> 
>> Yes, GitHub issues would be best.
>> 
>> Thanks! :)
>> 
>> On Sun, Sep 30, 2018 at 8:37 PM Jason A. Novak <jnovak@apple.com>
>> wrote:
>> 
>>> Thanks Xiaoqian.  What’s the best way and best place to give
>>> feedback? GitHub issues?
>>> 
>>>> On Sep 30, 2018, at 9:59 AM, Xiaoqian Wu <xiaoqian@w3.org>
>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> The WebPerf WG has published a First Public WD of the Device
>>> Memory API [1]. This specification defines a HTTP Client Hint
>>> header to surface device capability for memory i.e. device RAM, in
>>> order to enable web apps to customise content depending on device
>>> memory constraints.
>>>> 
>>>> Your suggestion would be very welcome if there is any privacy
>>> concern on this document.
>>>> 
>>>> Thanks.
>>>> 
>>>> -xiaoqian
>>>> 
>>>> [1] https://www.w3.org/TR/2018/WD-device-memory-1-20180925/
>>>>

Received on Friday, 12 October 2018 15:58:00 UTC