Privacy Interest Group Teleconference -- 25 Apr 2013

<trackbot> Date: 25 April 2013

<yrlesru> yrlesru is Frank

we originally had Joe Hall down to scribe this session, but now I think he may be in hearings on the Hill

<scribe> scribenick: npdoty

<christine> Agenda:

<christine> 1. Welcome and introductions.

introductions

<christine> Christine Runnegar, co-chair of PING

Nick Doty, W3C / UC Berkeley

<yrlesru> Frank Dawson = yrlesru

<christine> Hannes Tschofenig

<Karima> Karima / University of Nice Sophia Antipolis - CNRS

<yrlesru> Frank is also from Nokia, btw.

<christine> 2. Status of EME privacy review

christine: npdoty, can you follow up with rigo?

npdoty: yes, wseltzer may be managing, since she's already doing EME work

christine: please volunteer, can contact rigo, wseltzer

<christine> 3. Status of the getUserMedia privacy review

hannes: a little bit behind on the privacy review (worked on the privacy considerations document instead)
... when do we need to have that ready? what timeframe?

christine: til the next call, but sooner is better because sooner makes it much more likely to have useful impact on a WG's deliverables
... due on 16 May?

action-3?

<trackbot> ACTION-3 -- Hannes Tschofenig to lead privacy review on Media Capture -- due 2013-04-04 -- OPEN

<trackbot> http://www.w3.org/Privacy/track/actions/3

hannes: feel free to contact me to volunteer with help

christine: Joe Hall may be able to help from CDT

action-3: due 16 May

<trackbot> Notes added to ACTION-3 Lead privacy review on Media Capture.

Privacy Guidance Documents

<christine> This item: Frank Dawson - Specification Privacy Assessment

frank: thx to Nick, tried to put SPA into W3C format
... status and purpose of the documentation, give specification authors an explanation why privacy assessment is important
... when would this process be used (a series of three questions)
... how to conduct an analysis of your specification
... and what sort of content should be written in a Privacy Considerations section
... methodology, threat analysis from Security Development Lifecycle
... understand where the trust boundaries are
... external interactors
... kind of data in a protocol, understand what privacy principles might apply and what threats there might be
... are there any privacy controls that might be put into the specification?
... for Device API, rather than limit the kind of data available through the spec, instead assume that the deployers would have guidance on the privacy in implementation
... looking at the stages of documents, what can you do as an editor / document team at each stage to identify and mitigate privacy issues?
... Privacy Data Lifecycle, data collected by a sensor, how that data is transferred back to a server, etc.
... ISO generalization of privacy principles (OECD, US FIPPs, proposed EU regulation), blending into a list of 11, and references to other lists
... if using the logic of a three-step question, you find that there are no privacy considerations, standard boilerplate for the otherwise empty privacy considerations section
... classification scheme (PII 2.0, Solove)

npdoty: look at the 3 questions for whether review is necessary

frank: follow the data
... first look at whether it will process personal data (definition of "personal data" important)
... you might not be processing, but providing links to personal data elsewhere, which would also suffice
... second, will it generate personal data? (in case you consider that separate than processing)
... concern because we carry our mobile devices everywhere
... third, will deployment be used in a network device by an individual?
... process may seem heavy, but it's the longest, ideal case, even if it won't always be used entirely
... might (often) be the case that privacy considerations will be passed on to some other party, like the deploying party
... steps may be useful for the trial privacy reviews we're doing right now
... make sure you understand the spec itself, do a data flow diagram on the back of an envelope
... identify what kinds of data
... for each privacy principle, what safeguards would be necessary?
... for DAP, they tried to minimize the amount (number of records, which fields) of data from the Contacts API
... could use a checklist of threats, logical threats for different steps in a data flow

npdoty: for these questions, wouldn't every W3C spec qualify? (browsers in use on network devices by individual)

frank: could be, so maybe we need a lighter weight process to start

christine: thanks frank, a very useful introduction

<yrlesru> SEVEN-Step Program For Privacy ... LOL!

christine: would be very good to see how it works in practice as we do privacy reviews
... for example, could inform media capture reviews for hannes / wseltzer
... if no questions now, please all read through the document carefully and share comments on the mailing list
... start with what frank has done, an amazing piece of work, and tinker to what we need

frank: take to the list, or feel free to contact me directly

http://www.tschofenig.priv.at/w3c-privacy-guidelines.html

<christine> Next item: Privacy Considerations for Web Protocols

hannes: frank has spoken about the process, guidelines together for how to write these privacy considerations
... took the work from IETF/IAB to re-use aspects where possible
... took from DAP Privacy Guidelines as well
... for introduction and terminology, tried to re-use from the IAB document
... fingerprinting, w3c has more context available now, so could put some references there, perhaps in place of these definitions
... briefly highlighted the privacy threats (section 3)
... list from Dan Solove, Understanding Privacy
... Guidelines (section 4), taking from other documents
... not telling you a particular solution, since those solutions will vary in different w3c specs
... Data Minimization; Trade-offs; Defaults; User Participation
... user participation gets at notice, consent, user control mechanisms
... with minimization, provided examples, which originally were used in the TAG document
... would like to add examples from w3c as we do our own reviews, make it more interesting to read
... tried to keep it as short as possible
... I believe I have captured the same concepts in the TAG document, but not the terminology of "privacy-by-design" or "privacy patterns"
... tried to stay abstract with user participation

christine: might be able to provide short examples of how a privacy problem was identified and then mitigated (with an expression of how well it worked out)
... for npdoty, does w3c already have a glossary of terminology?

npdoty: not aware of any glossary, not specific to privacy; but many specs themselves define terms, like "user agent" defined in an HTTP spec

hannes: yes, could replace when other documents have more specific terms, like with your separate fingerprinting document
... useful to have these terms not just for use in this document, but when doing privacy reviews of another document, it's useful to have common terms, to avoid talking past

npd: +1

christine: might want to determine when there are terms-of-art that have a particular meaning to the W3C community
... although ideally all standards communities would use the same terms, probably not possible

npdoty: just initially, what do we think about use of this in relation to what Frank presented?

hannes: a process aspect (how is the machinery done), and instead what is the actual content
... left out process on the understanding that that would be covered by Frank's document; for example, who does the reviews, who makes decisions, how are the results framed in the spec

<yrlesru> And hopefully some examples, too!

christine: may end up with one or two documents at the end; Frank's doc would provide the process; Hannes's doc would provide more detailed guidance about how they might be mitigated

<Karima> +q

<yrlesru> I am also interested in seeing catalog of threats to privacy being developed over a very long period.

Karima: very useful to have a glossary, because usually there is no one definition
... even if we can't have one for all standards, if we have one for what we're doing, it will be useful

<yrlesru> There are some good glossaries out in internet on privacy.

Karima: we developed a glossary for one project in France, and now it's been in use by the government

<yrlesru> ISO SC27/WG5 has one. I think that others maybe could contribute to that also.

yrlesru, can you email us your list, or whatever glossaries you know of that we should be considering?

<yrlesru> Will queue that up!

christine: again, ask that people look at the content of this document over the next week, and start feedback on the mailing list

<christine> 4. Fingerprinting guidance

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

<Karima> OK. It is not a privacy glossary, more a security glossary

<christine> nick: a few short updates on the document since the last discussion - now Github hosted

<christine> nick: written in HTML - can see repository - can edit using Github

<christine> nick: changes will go into the centralised repository

<christine> nick: if not comfortable using Github, can send proposed changes on email

<christine> nick: defn of browser fingerprinting similiar to priv consid - but seems we need passive, active, cookie-type defins

<christine> nick: passive is harder to identify; browser does not run code; efficient; can be done offline without visibility to the user

<christine> nick: active is where a lot of work has been done recently - add function to API - add more characteristics to identify uniquely browsers

<christine> nick: graphical rendering to look at output of ??? [nick to fill this in]

<christine> nick: some argue too hard to solve ... but there might be some indication that is occurring and the ability to do something about it

<christine> nick: so we might say no new specfications should increase ability to passive fingerprinting

<yrlesru> In older mobile platform (Symbian), the call log had information like MSISDN called, duration of call, etc. Some researchers were analyzing this data to assess the social profile of users. I guess that is kind of like fingerprinting :-)

<christine> nick: but less stringent on active as it might be inevitable if functionality is desired

<christine> nick: cookie-type fingerprinting

<christine> nick: welcome feedback on definitions

<christine> nick: also input on what to do to mitigate fingerprinting

<scribe> scribenick: npdoty

christine: thanks. any questions?

hannes: regarding conversation at last TPAC meeting, and lots of publications, how far would you like to go?

<christine> nick: the distinction on defn could help - may be able to make more progress with passive than active - don't share the view that it is so bad nothing can be done

npd: maybe I'm being incorrectly optimistic, I would welcome corrections

<yrlesru> Will be leaving meeting IRC. I have some reading to do. Thank you Nick and Hannes for my reading list. Ciao.

christine: again, ask folks to look closely at the document, provide feedback -- either pull request in github or discussion on the mailing list
... any other business?
... thanks for joining, and for work on these documents

propose next call for 23rd May

christine: hoping to have draft reviews on getUserMedia and EME a week ahead of the next call

<Karima> thanks Christine and all !

- DRAFT -

Privacy Interest Group Teleconference

25 Apr 2013

Attendees

Contents

introductions

Privacy Guidance Documents

Summary of Action Items

Scribe.perl diagnostic output