Privacy Interest Group Teleconference -- 11 Jul 2013

<trackbot> Date: 11 July 2013

<rvaneijk> Hi Wendy, Tara, Christine ! Hope all is well.

<tara> Hi Rob!

<Christine> Hi

<npdoty> yeah, I think going over the document structures would be useful

<npdoty> scribenick: npdoty

tara: welcome, know that many people are busy with intensive Tracking Protection work, but a good time to check in
... anyone new to introduce themselves? welcome back Rob vE
... overview of the agenda

<Christine> Who is on the call?

Privacy Considerations doc

http://w3c.github.io/fingerprinting-guidance/

<yrlesru> zakim +1.469.242.aabb is yrlesru

<JoeHallCDT> suggest Nick Weaver and Hovav Shacham's student (can't remember)

<JoeHallCDT> scribenick: JoeHallCDT

[missed the beginning of npdoty's stuff]

npdoty: as the entropy of UA strings get more complicated, increased these fingerprintability

… what are the use case that we are protecting for, and in which can we reduce entropy in UA strings?

… who is it that we should be talking to about [passive fingerpting]?

<Christine> That seems like a very sensible idea Nick

… do we know which group or which body would be working on that?

<yrlesru> Could Nick rephrase...

<npdoty> JoeHallCDT: more familiar with the academic work, so I can help you there

npdoty: Who are the right people to talk to about the use cases for the UA strings?

… and if we want to address reducing entropy in in UA strings, who should we talk to?

yrlesru: Do you want to restrict the UA strings to make them less unique?

… because I think the UA strings are widely used, e.g., in the mobile area, to understand what kind of device is accessing the site to do programmatic reformating, etc.

… seems like the horse is out of the barn in trying to restrict the diversity of values in UA strings.

npdoty: maybe not every browser is adding something to the end of the UA string...

… maybe if we have that use case down, we don't need such long UA strings.

Christine: Frank makes a great case about why this is useful.

… Can we identify which groups in w3c are principally focused on using UA strings for this kind of functionality?

npdoty: Wanted to see if anyone knew that off the top of their head. Will take as homework.

tara: you could also throw it out on the list.

… many of us would be interested to see what you find.

rvaneijk: think the document is already a great aggregation of information about fingerprinting.

<npdoty> will follow up with Joe about some of the academic work, and email public-privacy and w3c-internal lists about working groups that might affect UA

… Would like to see things like… device optimization uses vs. for deriving a tracking identifier.

… building up use cases would be very helpful.

… I am writing up a [something] on fingerprinting, so this would be very useful. Would be willing to help expand use cases.

<npdoty> great, thanks, rvaneijk

<yrlesru> I came into call a bit late. Was there anything before Fingerprinting.

JoeHallCDT: asks about focus on passive fp?

npdoty: more people think that active fp is a lost cause.

… once you're running client side code, you're hosed.

<tara> Joe, were you thinking of Keaton Mowery? http://cseweb.ucsd.edu/~kmowery/

… you might be able to detect or disable active fingerprinting.

yes!

thanks, Nick!

<yrlesru> Can we assume we will use the term "passive" and "active" relative to consumer/user participation?

tara: sounds like this is going in a good direction.

<fjh> does user participate when javascript actively checks GPU etc?

<npdoty> yrlesru, I've tried to define "passive" and "active" in that document thus far, mostly to refer to whether local client-side code is involved

… let's move to SPA from yrlesru

<npdoty> http://yrlesru.github.io/SPA/

yrlesru: the SPA is out on github. Thanks to npdoty and [Art Barstow?]

… have received some comments from bartsow and npdoty

<Christine> Would it be helpful to walk through the document today?

I sent you comments.

yrlesru: Rationale… at Nokia, we have a number of people participating in consortia and standards groups and we've begun to understand the privacy impact on our work.

… we're designing bridges w/o asking a structural engineer about integrity of design.

… lots of standards were developed before people were thinking about privacy considerations.

… in IETF you have to have a security considerations sections.

… came from IETF management, who wanted to make sure security impact was recognized as important and incorporated into standards.

… in IETF they have a security directorate, beardos that are wise in security.

… they had some guidance about what this kind of section should look like in RFCs.

… occured to us at Nokia that a similar approach could be taken for privacy.

… wanted to avoid ineherent weaknesses wrt privacy.

… want to have a common process for how editors and contributors would go about looking at privacy impacts.

… if you look at IETF, it's an *ad hoc* approach… no systematic approach to look at privacy impact.

… simply having a set of use cases without understanding how they apply is not systematic.

… having a checklist is much more systematic.

… checklists are very important in health care and aviation contexts.

… having working in ISO on some of the management standards, and privacy impact methodologies, a PIA approach is gaining a lot of momentum.

… it could be that a PIA approach could be a good baseline to start a privacy impact section in a spec.

… about 7 steps that one would want to do.

… like security, privacy impact goes with the data

… by following the data, can figure out where the privacy impact is going to be.

… can then put in safeguards to mitigate those impacts.

… bascially I've just described what's in the SPA document.

… use cases help you understand primary and secondary uses.

… looking at data flow allows you to see how data affects those use cases.

… describes a spec that narrowed the request of contacts after such an examination.

… once you have an understanding of data flows and basic architecture, you can see where there are opportunities to put in controls and safeguards.

… latter element in SPA considers where the impact may be non-architectural but on deployment

… so privacy considerations should touch on deployment too.

<Christine> That was a superb overview Frank

<npdoty> +1

<Zakim> npdoty, you wanted to be skeptical about data flows

npdoty: have been mulling over questions...

… want to focus on whether to apply the process and when.

… want to be skeptical about data flows.

… going through a set of [FIPS-like] principles is very valuable

… less certain how useful it would be to identify specific data flows or to id which information is personal or not.

<yrlesru> FIPP

… some of the questions are less about what kind of data but more about how these principals work.

yrlesru: I heard 1) skepticism about data flows, and 2) the logic diagram that outlines whether or not a specific assessment is needed.

… they're kind of tied together.

… has talked to sensor engineers who don't work with software so much.

… from them, the guidance I got, was "if you could privacy into a set of equations, these people can grok it"

… I came up with four equations.

… they were bored until I showed the equations.

… this enlightened me: engineers will understand privacy a bit better if we can make privacy quantifiable and measurable.

… first equation: what do you mean by data? if you don't have data, you don't have privacy.

… second eq.: breaks down identifiability, observability and linkability

… the point being that it's very important to understand the data flow.

… if there is no flow, there is no or minimal privacy impact.

… under the SUR [? frank likes acros]

<npdoty> "specification under review"

… for me, once I mapped data flows, I had a much better understand of privacy impacts.

… npdoty doesn't need no data flows.

… so this is more for engineers, rather than seasoned privacy experts who know FIPs/FIPPs.

… and this is very simple data flows in a uses case to understand the trust boundaries.

… e.g., if a sensor is collecting information but the data never leaves the sensor register, then there's probably minimal to no impact.

… might not understand that without mapping flows.

[hannes?]: The main part of the specification is entirely about the data flows.

<npdoty> I think Frank is making two points: both that to do a privacy review you need to deeply understand the functionality

<npdoty> and that you need to identify where the data is flowing to explain whether privacy is impacted at all

… I don't think it's good advice to have people write up a summary of the protocol in the privacy considerations section.

<npdoty> (and I'm generally more supportive of the first than of the second, which I fear can be misleading)

<yrlesru> Please, Hannes, read the SPA. THere is no request to put DFD in Privacy Considerations.

Isn't the SPA an instrument for creating a privacy considerations section?

<yrlesru> The DFD is needed for assessor, not to put in PC section.

… [having a hard time scribing Hannes]

yrlesru: SPA says there are only two or three things that go in privacy considerations section.

… where is personal information being collected and processed.

… where is privacy being impacted

… how has this been addressed

… [one other thing Joe missed]

<npdoty> hannes: specifications tend to be very generic, APIs aren't used only in a single place, in the home, but used generally

hannes: need to outline what's the responsiblity of spec writers vs. deployers.

… e.g., a protocl dev can't say anything about a retention period.

… no way to enforce a recommended retention period.

… requiring protocol authors to write anything meaningful about deployment is very challenging.

yrlesru: however, for the person deploying the spec, if the service designers haven't thought about, e.g., retention, they might be impacted by this being in the spec.

<npdoty> fjh may have some experience with providing guidance to implementers, and how useful they might be

… the underlying fundamental point is that if you're creating protocols/specs, it behooves us from the beginning to take into account S&P in a systematic and considered manner.

… need to map the protocol into how it will be used.

hannes: IAB published "writing protocol models" that goes into some depth about how to write protocols to be analyzeable from security folks.

… challenge is that people are super-busy, now you're throwing another piece of work on them.

… they won't be able to do everything that your asking.

<yrlesru> Challenging part of the privacy work is to mature the privacy maturity of the group. We are at a primitive stage.

… what do you want them to do?

… I would like to focus them on something else?

npdoty: Frank is saying if you're doing a privacy review but did not write the spec, you need to do these things to understand how it's working.

… curious if privacy requirements are more productive than data flow?

yrlesru: how do you know what to apply if you don't know what it's doing?

… notice and consent, e.g., may not even apply.

… how do you know what to apply without knowing what the spec is doing?

… doesn't want to see privacy principle opportunism.

… agrees with Hannes that we don't want to make undue work for folks.

<fjh> +1 need to be pragmatic and reasonable work for those producing work products

… look at the intent of the processes and can then consider if you need to put in back up processes.

npdoty: wanted to understand why the data flow is useful.

yrlesru: in some of the less systematic approaches, people just have a set of threats.

… e.g., unauth. access… how do you know that applies?

… you don't unless you understand the process.

<fjh> if done right, systematic approach could be less work?

less work than copy+paste? :)

… editors will be in a better place as they already understand flows

… but for assessors, the flows will be key.

… for ISO 90001 [?] and the associated assessors, this will be important.

<npdoty> I'm personally a little concerned that "oh, there's no data" may be misleading; some of the privacy concerns we've identified on event notification and correlation might not identify a set of new data that's flowing

Christine: my understanding is that we have two privacy reviews in the queue

… yrlesru is doing something like the SPA process in GetUserMedia

… might help to see an example of a SPA applied to a real spec.

<Christine> Re Nick - yes - Hannes leading GetUserMedia and Wendy leading EME

rvaneijk: concur with frank that flows are important and understanding is too.

… from a DPA perspective, I have to look at lot of implementations of that policy

… have a set of questions that I ask.

… flows are key for me. I always ask for a diagram or summary.

<Christine> Rob is speaking

… this Q&A helps a lot to understand if there is a processing, collection of personal information.

<npdoty> thanks, rvaneijk, that's great input

hannes: you get to review a subset of a service.

… not a spec.

… data model may be more obvious in a spec.

<Christine> Time monitor: 5 mins to the hour

… while I agree that flows are important, what is the responsibility of the editors?

rvaneijk: if you have a little piece from a car, does the manuf. have to worry about the impact of that little piece or the whole car?

hannes: parts for the care are very specific, but here we're definiing very specific contexts.

<tara> Thanks, Christine...we should wrap this up.

<tara> Thanks, Joe!

<npdoty> scribenick: npdoty

hannes: very difficult, because specifications are very generic, to be applied to many different types of applications

<yrlesru> I believe that it is good to have such as process, even if today (2013) the privacy maturity of W3C is not sufficient to leverage every step in the process.

<fjh> I'll share my comment on the list

hannes: HTTP cookies, for example, some applications needed state management, but hard to see all the implications at that time

tara: hate to cut off, but running out of time

<Christine> We need people to work with Frank, Hannes and Nick on the 3 privacy guidance documents. Please volunteers.

yrlesru: both general and specific comments are welcome; this discussion is important regarding maturity levels of the process

<Christine> We also need volunteers to help Hannes and Wendy with the GetUserMedia and EME specs

yrlesru: work in progress (with GitHub); tried to apply to getUserMedia but found the high-level API difficult so falling back on use cases for now

<Christine> Next call?

<Christine> 22 August?

tara: any conflicts for 22 August? (let tara and christine know)

<fjh> thanks

<yrlesru> No conflict with 22.8.

<Christine> Thanks Frank! Joe! Hannes! Tara! Everyone!

<yrlesru> Thanks to all for lively discussion!

tara: thanks all for joining, and to Joe for scribing

<yrlesru> +358 was Hannes.

<yrlesru> +1-469 was yrlesru/Frank

- DRAFT -

Privacy Interest Group Teleconference

11 Jul 2013

Attendees

Contents

Privacy Considerations doc

Summary of Action Items

Scribe.perl diagnostic output