See also: IRC log
<trackbot> Date: 11 July 2013
<rvaneijk> Hi Wendy, Tara, Christine ! Hope all is well.
<tara> Hi Rob!
<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?
<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.
<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.
<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
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
<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.
… 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)
<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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/someone/yrlesru/ Succeeded: s/Bartsow/Barstow/ Succeeded: s/havig/having/ Succeeded: s/whole care/whole car/ Succeeded: s/fjh/rvaneijk/ Found ScribeNick: npdoty Found ScribeNick: JoeHallCDT Found ScribeNick: npdoty Inferring Scribes: npdoty, JoeHallCDT Scribes: npdoty, JoeHallCDT ScribeNicks: npdoty, JoeHallCDT Default Present: Christine, +1.650.283.aaaa, tara, npdoty, JoeHallCDT, fjh, rvaneijk, +1.469.242.aabb, Frank, +358.504.87aacc, Hannes Present: Christine +1.650.283.aaaa tara npdoty JoeHallCDT fjh rvaneijk +1.469.242.aabb Frank +358.504.87aacc Hannes Frederick_Hirsch Found Date: 11 Jul 2013 Guessing minutes URL: http://www.w3.org/2013/07/11-privacy-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]