Privacy Interest Group teleconference -- 06 Dec 2012

<rigo> christine, looks like frederick stole your line

<rigo> kind of identity theft

<christine> So what do I do?

<christine> Thanks Frederick

<rigo> fjh, are you in 415 area?

<rigo> ah :)

<christine> Waiting for the hour and for scribe to arrive

<christine> Agenda:

<christine> 1. Welcome and introductions.

<christine> 2. Report out from the TPAC breakout session: Is fingerprinting a lost cause? and skeleton draft (Nick)

<christine> 3. Report out from the TPAC DAP WG meeting and privacy (Frederick/Rigo/Christine)

<christine> 4. Report out from the Do Not Track and Beyond workshop (Brad/Nick)

<christine> 5. Update regarding CSP privacy issues (Trent)

<christine> 6. Upcoming privacy reviews: - Proximity API (Frederick) - others?

<tara> Not sure if 415 is me - that's my area code but not the number at this desk...

<christine> 7. Privacy considerations (Nick/Frank)

<christine> 8. AOB

<christine> (As you see I need lessons in IRC and Zakim)

<christine> New person: Zuiderveen Borgesius, Frederik

<npdoty> welcome, Frederik

<npdoty> welcome back, fjh

<tara> Welcome and hello!

<fjh> Hi, I'm Frederick Hirsch from Nokia, charing Device APIs (DAP) and XML Security. Have been active in W3C privacy workshops in the past. Interested in applying to DAP.

<christine> Agenda item 2 - report out from TPAC - Is fingerprinting a lost cause?

<Frederik> hi, Frederik here http://www.ivir.nl/staff/borgesius.html

<christine> Report provided by Nick

Fingerprinting

<christine> To discuss suggestions that fingerprinting might be too difficult to deal with

<christine> e.g. with respect to APIs

<christine> to Rigo: please could you record attendance?

<tara> http://www.w3.org/2012/10/31-fingerprint-minutes.html

<christine> Different threat models - can we prevent passive fingerprinting; can we produce a common brower profile with reduced functionality

<christine> Trade-offs when developing a new API

<christine> Consensus - you should not do nothing - balancing considerations - WGs considering when develping APIs

<MacTed> (Administrivia: updates to the upcoming meeting schedule [and past minutes] in the wiki would be a goodness. I can fix some of the past, but look there myself to learn about the future...)

<christine> Handing over scribe duties to Robin

<christine> Nick talking about the skeleton draft (see email thread)

<christine> Looking for feedback

<npdoty> this was my skeleton draft: http://lists.w3.org/Archives/Public/public-privacy/2012OctDec/0204.html

<christine> A very useful document. Let's put it in a collaborative space and start fleshing it out.

<fjh> wiki sounds simpler to start

<Karima> +q

<npdoty> wiki or github? what would make others most likely to help?

<Karima> ok

<npdoty> "the most secure system is a brick"

<christine> [All Robin is experiencing technical issues - could someone else volunteer to take over scribing]

<npdoty> fjh: call out the tradeoff between functionality and fingerprinting risk at the very outset

<tara> I can!

<npdoty> scribenick: tara

<JC> Isn't there a difference between passive and active fingerprinting?

DAP F2F summary

<fjh> summary http://lists.w3.org/Archives/Public/public-privacy/2012OctDec/0212.html

<npdoty> JC, yes, definitely, that's one of the differences I wanted to highlight in this document

<christine> Agenda item 3

Frederick & Rigo: update on DAP

<npdoty> ... because I think we'll give different guidance on passive vs. active new fingerprinting surface

Came up with thoughts: informative material would be helpful.

Details are in email that was circulated. (Not scribed here.)

<fjh> see http://lists.w3.org/Archives/Public/public-privacy/2012OctDec/0212.html

Participants were worried about privacy concerns (e.g., around debugging) and what limits this might cause.

Were able to reassure them that an effective solution could be found.

<bblfish> hi

<npdoty> christine: really was a case of the device api group asking for help with concerns

<fjh> thank you for joining DAP for that session

<bblfish> sorry for being late.

<JoeHallCDT> \me doesn't think Tara is actually scribing, no?

<robin> I may be able to take over now...

<robin> Apologies for my poor IRC skillz :^(

(We seem to be handing off various parts - but go ahead Robin!)

<bblfish> bblfish is Henry Story, http://webid.info/

<rigo> christine, bblfish is Henry Story

<npdoty> scribenick: robin

OK - apologies in advance if I don't recognise voices

<npdoty> npdoty: to take a more skeptical view, were we coming in too late?

Now's a good time to reintroduce the privacy topic

<rigo> this is fjh

<npdoty> ... have occasionally heard pushback when privacy people come in with feedback too late in the process

<rigo> robin, just type ??: if you don't understand who is talking

<npdoty> Web Intents vs. Web Activities, yeah?

fjh looking to combine Web Intents work (Google) and Mozilla WebActivities work

*WebIntents

bblfish to speak under AOB

hannes: question for FJH: what's the best way to bring new joiners up to speed with the privacy issues, deployment models etc?

<npdoty> all the important stuff (nec'y for the security/privacy review) is hidden behind tons of details -- interesting point

<fjh> http://webintents.org/

Is there a high-level write-up that would help people get the essentials from a welter of details about Web Intents and Web Activities?

hannes to send a link to a similar write-up as a model

Agenda Item 5 - report from the Beyond DNT workshop (last week); npdoty to report

UC Berkeley hosted the event

What should W3C focus on on the wake of existing DNT work?

<JoeHallCDT> It was great!

2-3 bullets:

1 - how much should W3C standards address the "policy" space? (and how much do they already?)

discussion revealed that there's generally some policy content, even if it's not explicit/understood

2 - DNT

User studies and economic arguments were also intersting; summary/minutes to be published along with a brief report

*interesting

<Frederik> [ 1.347.570.aadd is me, Frederik by the way ]

User education is still not well addressed...

<rigo> Nick Doty is talking

3 - Future work:

Privacy specification assesssment - Frank Dawson

<scribe> new privacy technologies; privacy icons, standardised short notice...

<JoeHallCDT> yeah, the "resurrection" so to speak of p3p was fascinating

JoeHallCDT: P3P discussion was fascinating... often written off, but actually a lot of the work is still 'not stale'

<fjh> privacy rulesets work might be relevant to future work discussions related to P3P, http://dev.w3.org/2009/dap/privacy-rulesets/

JoeHallCDT: definitelyopportunities to learn from the successes that were in P3P's work...

<npdoty> vocabulary and ontology very thoughtful and perhaps still useful

Frederik: Contributed pointer to privacy rulesets work as a possible asset

<rigo> fjh, please note DSR and my paper that addresses http://www.w3.org/2012/10/dsr-rw-json-p3p/

<fjh> rigo, thanks am not up to speed on what happened at the workshop

rigo: two main threads of discussion: (1) policy and tracking implications... and how much should W3C get into that area
... and (2) actually some policy/compliance considerations are unavoidable in work on "tracking protection"
... we can look at P3P as a first attempt to define what metadata is needed for such protections, and how they are to be transported/expressed/enforced

<npdoty> if people are interested in this short notice work...

<npdoty> http://opennotice.org/

<npdoty> is a group of various projects around the privacy icon idea

Agenda item 6: update on CSP privacy issues

<npdoty> and we might look into a Community Group to investigate work at W3C, which I'll update PING on

jtrentadams: a quick recap: Content Security Policy (CSP) WG

<npdoty> Web App Sec Working Group, which is working on Content Security Policy

jtrentadams: set of substantive issues, plus some general concerns about engagement

3 substantive issues:

jtrentadams: 1 - "phone home" question: if a user agt violates policy, should the agent report the violation, and if it does, should it be allowed to be a silent feature (i.e. without user notice/consent)?

*silent

jtrentadams: networked application design is based on a clear assumption that data is flowing back and forth constantly; therefore a "core dump" of whatever is on the client might not be appropriate (compared with a more standard 'distributed PC' architecture
... 2 - CSP spec now has reporting fields that are necessary for debugging or enforcement, and nothing else
... 3 - Capabilities for applications to 'fingerprint' a given device; a known issue/problem/concern, but not realistically within the scope of the CSP group

<npdoty> is there a new fingerprinting risk from CSP? is that from the violation reports? or some other feature?

<rigo> DRM!

jtrentadams: Up to site owner to lock down the delivery of content to a specific set of channels, but configs across the web are so unique that some form of fingerprinting is pretty unavoidable

*owner

<fjh> rigo, ?

jtrentadams: Turning to Fred's second set of issues:

<rigo> fjh, security violation on the user's terminal equipment is another word for DRM :)

jtrentadams: Are the Web App Sec group acting with due respect to issues raised? Can the PING group contribute its views?

<rigo> fjh, CSP is not limited to that

<rigo> but can be used for it...

jtrentadams: Trent expressed the concerns to Web App Sec, who took serious steps to review their issue-handling process and ensure concerns raised were properly dealt with
... ... and expressed their regret that the conversation had not been well managed on their part initially; reaffirmed their commitment to ensure good cross-group activity henceforth

<npdoty> thank you, jtrentadams, and well done!

<JoeHallCDT> yes +1

rigo: Thanks, Trent - good job
... <... ... ...> [redacted] ;^p
... it may not be as obvious on some mobile devices that such reporting back is taking place - so it remains an important issue - but satisfied that CSP is taking it seriously

<npdoty> I wonder if this sort of diplomacy will be a consistent work item

<fjh> http://lists.w3.org/Archives/Public/public-privacy/2012OctDec/0214.html

Next agenda item: Frederick has a request relating to specs including Proximity (link above)

Frederik: experience has led to a preference for small, simple, specific, testable and digestible specs for HTML5 functionality
... Has circulated a set of specs; use-cases are yet to be fleshed out, but privacy considerations are hoped to be minimal

<rigo> npdoty, I think so

Frederik: Proximity spec would be a useful example to consider;

fjh: HTML Media Capture set of specs is a little more complicated, but will be simplified a little more; updated draft will be brought back for discussion

Frederik: Network Discovery and Web Intents specs are a little further down the line for discussion

<fjh> http://www.w3.org/TR/2012/WD-proximity-20121206/

fjh: (Frederik) So, Proximity:

<fjh> http://lists.w3.org/Archives/Public/public-privacy/2012OctDec/0212.html

fjh: This spec generates an event if something is sensed to be 'near the device' - but not what, or any idenifying data about the thing

(1) is something near? (2) distance, incl. max/min possible distance

<rigo> oh this is related to the k-anonymity problem of geolocation as defined by Samarati and recently re-assessed by Claudia Diaz

fjh: Only a rough indication of whether something is nearby - e.g. is a cellphone being held near to someone's face, and if so should some functions be attenuated in the interests of usability?
... No security/privacy considerations in the spec at the moment; *any* API will gie rise to some level of 'fingerprinting' risk - but keen not to include that in every single spec as a matter of course...

<rigo> http://www.cosic.esat.kuleuven.be/publications/article-1469.pdf -> paper from Claudia Diaz

*give

<npdoty> failure mode of not noting that a feature doesn't exist, but just not responding with functionality

<npdoty> ... good for minimizing fingerprinting

npdoty: Also don't necessarily see privacy implications in these specs - not proposing a privacy review of the specs, but there are some interesting areas to explore:

e.g. detection of co-location (as distinct from geo-location) by correlation of other variables

I agree with npdoty : correlation is an interesting area

some ATM systems use something similar, though I acknowledge that they tend also to use e.g. cell tower identifiers (but not geolocation)

<JoeHallCDT> one thing I can think of is if malware wants to run when there is no one proximate… but that's not necessarily privacy and probably out of scope of that spec

it's just correlation-based

<npdoty> absolutely -- standardizing small pieces, but some of the privacy issues are systemic, good point, fjh

fjh: acknowledge that individual pieces (like these specs) can have different privacy implications from the combination of multiple pieces into a system... *systemic* risk ought perhaps to be dealt with in a separate document
... Still not sure 'ambient light' is a strong identifier... there's a lot of light around...

npdoty: Agree: privacy risk more likely to arise from systemic factors/combinations

<npdoty> http://www.webplatform.org/

fjh: W3C put together a website for training: that might be a place to host material dealing with privacy considerations.

<fjh> http://www.webplatform.org/

npdoty: webplatform.org - though that isn't necessarily aimed at the web developer community.

<npdoty> aimed at the web developer community, but less at the browser vendor / spec author community

<JC> JC Cannon

<fjh> regrets from Frank Dawson today, holiday in Finland

<bblfish> Henry Story http://bblfish.net/

<christine> and regrets from Erin K

<npdoty> I have heard the suggestion that webplatform.org would be a good home for documentation for the many web developers out there on how best to handle privacy in their sites/apps

rigo: combination of (DAP) specs is potentially infinite, but there are some universalisable principles one can apply... those could be set out in a doc extending the DAP privacy considerations, or in a note via the PING wiki.

<fjh> http://www.iab.org/wp-content/IAB-uploads/2011/03/frederick_hirsch-revised.pdf

rigo: goal would be to raise developers' awareness of areas where they might 'hit the wall' on privacy issues

christine: ACTION: let's start by putting together a note, and then worry wbout where to lodge it (e.g. as an extension to the DAP, or elsewhere)
... volunteers?
...

<npdoty> volunteers to review Proximity and perhaps collect that in a note?

<npdoty> fjh: would be good just to get confirmation, just an email that says we're okay

fjh: Proximity does need looking at, but it would be best to add some other ["atomic"] specs to the mix, and particularly to look at the HTML Media Capture spec.

christine: So, volunteers for that specific task (looking at Proximity) as well as the other areas...

<JoeHallCDT> I volunteer with Proximity...

<JoeHallCDT> woulld like some help

<tara> Thanks!

<fjh> much thanks, proximity is very short...

christine: Apologies to bblfish for having run out of time: will add to the front of the next agenda

<JoeHallCDT> it's more about not knowing exactly what to do, which is why I want a tara/nick/christine

<fjh> yes 24 Jan ok

<JC> +1

<Frederik> 24th January some people are on CPDP

<npdoty> or 17 January/

<JoeHallCDT> WFM

<JoeHallCDT> 7 Feb

<rigo> 7 Feb

<Frederik> early Feb works for me as well

fjh: 7th Feb is Media Capture F2F

<JoeHallCDT> meh

<fjh> why not 17th jan?

<JoeHallCDT> same time

<JoeHallCDT> ?

<JoeHallCDT> thx

<fjh> doodle poll?

<JoeHallCDT> maybe poll between 1/17 and 1/24

<rigo> doodle poll!

7 Feb had fewest abssentees, I think

<JoeHallCDT> ok

<npdoty> :)

<fjh> thanks

christine: Next call date will be distributed via email

<bblfish> bye

<JoeHallCDT> bye

<tara> Thanks! (Tara Whalen)

<Frederik> Thanks all!

ending transcription - apologies again for the ropy start.

<Karima> Don't see my name on lis of attendees..

you're welcome - hope they ended up OK

- DRAFT -

Privacy Interest Group teleconference

06 Dec 2012

Attendees

Contents

Fingerprinting

DAP F2F summary

Summary of Action Items

Scribe.perl diagnostic output