Privacy Interest Group Teleconference

04 Dec 2014

See also: IRC log


christine, +1.650.944.aaaa, npdoty, Katie_Haritos-Shea, BHill, [IPcaller], tara?, +1.857.209.aabb, karen_oDonoghue, +44.793.550.aacc, Joanne, +1.202.407.aadd, JoeHallCDT, Ryladog?
wseltzer, fjh, frank, karima
christine, tara


<trackbot> Date: 04 December 2014

<tara> Yes, that is right, Nick.

<christine> Agenda item 1 - Welcome and Introductions

<christine> Christine Runnegar, co-chair

christine, tara -- in AOB, I can talk briefly about charter extension approved by w3c

<tara> In AOB I have a item from Mike West on spec review.

<tara> Tara Whalen, co-chair

<scribe> scribenick: npdoty

tara: any newcomers to our Privacy Interest Group calls?

melinda: Melinda Shore, consultant for Verisign on DNS projects; active in IETF. was at STRINT workshop in London

Christian: Christian Hague, student at Harvard University, studying computer science and privacy; Berkman Center
... looking at privacy and online education platform

kodonog: Karen Donoghue, ISOC, might be new or not. active in Web Crypto and IETF work

hannes: not new, but welcome back.

<JoeHallCDT> Heard through the grapevine that Tara's at Google now… :)

<christine> 2. Moving the work on the privacy considerations document forward - topic for discussion: data minimisation and identifiers'

privacy considerations: data minimisation and identifiers

christine: I'm responsible for putting this one on the agenda
... had a useful and robust discussion at the TPAC f2f meeting, about the privacy considerations work
... we all still think it's very important and want to progress it

<Hannes_Tschofenig> how do I put myself on the speaker queue?

christine: but it's a big piece of work. could try breaking down into smaller areas, with discussion and raising points, and then add to the privacy considerations

<Hannes_Tschofenig> (Did I ever mention that I don't like IRC?)

christine: what are the privacy risks or vulnerabilities that might be addressed by web specifications?
... what are the better ways for using identifiers in web specifications?

Hannes_Tschofenig: mentioned interesting discussion at TPAC. are there notes on that discussion?

npdoty: forgot to send around minutes from the f2f meeting (though I did for the breakouts)

<scribe> ACTION: doty to clean up and send around PING TPAC friday minutes [recorded in http://www.w3.org/2014/12/04-privacy-minutes.html#action01]

<trackbot> Created ACTION-11 - Clean up and send around ping tpac friday minutes [on Nick Doty - due 2014-12-11].

christine: identifiers
... an understanding of how we see identifiers working in the web space, risks/vulnerabilities around those, and how we can do better

npdoty: should document current state on identifiers, scope and clearing, so that new specifications don't extend that functionality

Hannes_Tschofenig: two different audiences. 1) looks at the considerations as a way to improve privacy; 2) those trying to use as much data as possible.
... for the former group, document details about data minimization are useful
... document what identifiers there are in the document. WebCrypto identifies a really strong identifier and linkage back to a user identifier
... data minimization, and documenting what identifiers you pass around and under what circumstances

christine: +1 on usefulness for documenting. re WebCrypto are you mostly talking about key discovery?

Hannes_Tschofenig: the process from FIDO about identifying what data is present in the protocols, how much identification is allowed
... and specifically biometrics
... make the right trade-off decisions

christine: one topic we looked at at TPAC, could take general guidance from Privacy Considerations, and other guidance already given: for example, Device APIs document, other documentation from TAG etc.
... and thinking whether we could as a group and go further than "data minimization is generally good" and give specific guidance about how to implement it for web specifications

<christine> Idea: Specifications SHOULD make it easy for developers and implementers to request as little information data as needed for the intended use (“the minimal data necessary for use”).

Hannes_Tschofenig: examples from other specifications. for example, FIDO doesn't ever send biometric data to the server, a design decision that rules out certain solutions, but very positive from a data minimization point of view

christine: suggesting a principle about where possible data is stored locally, not shared beyond the UA ..?

Hannes_Tschofenig: in geolocation, API would need to accomodate for users who only want city-level granularity, not just always sharing the highest resolution

christine: does the proposed text cover that case?

<Hannes_Tschofenig> The text proposed by Christine earlier works for me.

npdoty: make it possible, and make it easy, as separate steps

<JoeHallCDT> it would be great if whomever is making those noises could stop

<JoeHallCDT> tyvm

<JoeHallCDT> ah, it's a keyboard

Ryladog: regarding accessibility, it's very useful to have geofencing to help users with visibility issues
... need very granular geolocation information, but also want control

christine: any ideas for how to achieve that with architectural design, that would be helpful
... have talked about data minimization, please share thoughts on the mailing list.
... continuing on identifiers

<christine> Ideas: 1. Specifications MUST use non-persistent identifiers unless a persistent identifier is required for their functionality (“non-persistent identifiers”). 2. Specifications that require identifiers for their functionality SHOULD use randomly generated identifiers (“randomly generated identifiers”).

<JoeHallCDT> woo!

<Ryladog> Thanks Nick, for further clarification users with disabilities who use geolocation information for transversing roooms and obsticals their home and neighborhoods would want to able to be offered the choice of GepFencing options

npdoty: 3 questions I think tend to come up when we're talking about identifiers in a protocol
... 1) how unique (across all users, or just per window, or whatever)
... 2) how persistent (can they be changed)
... 3) who can access (is it tied to a specific origin, or is it available elsewhere)

Hannes_Tschofenig: identification at the transport layer or above, via encrypted communications. may be difficult to address at the Web layer
... not that many that use identifiers to begin with at w3c, right?

<JoeHallCDT> there is an issue here that is an analog of one we're dealing with in the IETF IAB privacy and security program: we have been thinking about correlation across network layers of communications… that is, encryption must fire in a coordinated manner or an observer with access to each layer may see some leakage of cleartext.

npdoty: I see lots of identifiers in W3C specifications, to identify cameras, microphones, game controllers, configured geofences

<JoeHallCDT> It seems that this might work with identifiers across layers too… if you randomize one in the web but a lower identifier persists, boo!

Hannes_Tschofenig: need to catch up on W3C work, but see issues regarding authenticated origins or authenticated identifiers

christine: topic of authenticated/secure origins for certain features, like geolocation access
... TAG might be looking at this

<bhill2> sorry getting off mute

<Hannes_Tschofenig> Whenever work spawns across working groups and organizations (IETF/W3C/FIDO/etc.) these cross layer problems are likely going to show up with less than ideal consequences for privacy. I just wanted to raise that issue since I see a lot of work going on in that area right now.

<Ryladog> URL?

bhill2: a concept that was recently published under the mixed content draft


bhill2: mixed content had gone to Last Call, but split off this discussion into a separate spec
... features that require a certain identifier should go over a secure transport, to prevent leaking a persistent identifier, for example with EME
... just published a First Public Working Draft today
... can take it to Last Call fairly rapidly, depending on public comment. much of the work has already been done

christine: yes, worth looking at that, everyone
... please share your thoughts on the email list so that we can keep the discussion going

<tara> http://mikewest.github.io/spec-questionnaire/security-privacy/

tara: mkwest working on a document independently, for a checklist of questions for putting together a first draft of a spec

<Hannes_Tschofenig> +q

tara: figuring out whether this is useful for w3c. should this be standalone or combined? work with other groups?
... share with the group and see whether it would be useful

Hannes_Tschofenig: thanks for the pointer. what triggered work on this?

tara: via WebApps WG discussion, and repeated internal questions

Hannes_Tschofenig: sounds similar to the discussion of same-origin policy questions in charters

christine: scheduling difficulties about getting him present on the call

<tara> Article 29 WP Opinion regarding device fingerprinting

Article 29 WP Opinion regarding device fingerprinting

not-scribe: npdoty: I think the mike west checklist looks great, though I need to read in more detail. it sounds very much of a kind with other work we've been doing here.

<christine> http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/wp224_en.pdf

Hannes_Tschofenig: could we invite some Art 29 folks to present or discuss?

christine: yes, can ask Rob.


npdoty: a summary or particularly important issues we should be looking at?

christine: definition comes from rfc6973 :)
... document is mostly directed at websites that might use fingerprinting, and legal status of whether fingerprinting fits under the EU Cookie directive

<Hannes_Tschofenig> Great to hear that they reference RFC 6973!

christine: refers to expressed DNT preferences
... so would be relevant to Do Not Track work
... documents different use cases (including first-party analytics, online behavioral advertising, security, etc.)
... useful for us to look at the technical background from a Web perspective
... if there are improvements, we could let them know.
... and worth reading, if fairly dense


Hannes_Tschofenig: we should definitely drop them a note if we have any disagreements. our interests may align, and they would appreciate feedback from a technical community

christine: can collect comments here and then see how to get them back
... just know that public-privacy can be a much wider mailing list, including people involved in this work

Web Security Interest Group

tara: had discussions with Virginie about possible coordination with the Web Security Interest Group
... our intention would be a conference call between the two groups to talk about how to do that work

W3C workshop on Privacy and User-Centric Controls

attendees at that workshop?

christine: rigo will be producing a full report, and unfortunately I missed the session of conclusions
... very interesting discussions, and very broad representation from the browser vendors
... lots of comments that PING would be the place to do something, and as a result have some new organizations formally joining PING

<tara> Hooray for new PING members coming from that workshop!

christine: I went to present PING, to convince of the importance and need for resources on doing privacy from an architectural perspective
... should have the report and formal outcomes by the next meeting

minutes and papers are available


<JoeHallCDT> npdoty: nick's job is to deal with these little bureaucratic things...

<tara> Thank you for dealing with "bureaucratic things."

<JoeHallCDT> … wendy seltzer reported that w3c management supported extending version of current charter for two years

<JoeHallCDT> … mgmt thinks the work is important and wanted to continue it

<JoeHallCDT> … They are also very interested in increasing the breadth and depth of privacy work

<tara> Thanks, everyone, for making us an effective group!

<JoeHallCDT> … this includes privacy reviews work, but also privacy in general

<JoeHallCDT> … we should include wendy in these conversations

<JoeHallCDT> npdoty: as a formal matter charter is extended for two years with minor changes

<JoeHallCDT> … that doesn't mean we couldn't recharter or make changes if we wanted to do that

<JoeHallCDT> to be clear I (Joe) wasn't suggesting we change it

January 8, 15, 22?

February 12?

<JoeHallCDT> unlikely

JoeHallCDT: could have more informal conversations, just to catch up on privacy and web issues

<christine> good idea Joe

<tara> (Have to drop off IRC...thanks!)

JoeHallCDT: can have occasional calls that are less about detailed progress

tara: placeholder for doing that in mid-January, and progress on work to be discussed 12 February

have a great holiday

trackbot, end meeting

Summary of Action Items

[NEW] ACTION: doty to clean up and send around PING TPAC friday minutes [recorded in http://www.w3.org/2014/12/04-privacy-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2014-12-04 18:04:34 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/3 Article/Topic: Article/
Succeeded: s/4. Web/Topic: Web/
Succeeded: s/5. W3C workshop/Topic: W3C workshop/
Found ScribeNick: npdoty
Inferring Scribes: npdoty
Default Present: christine, +1.650.944.aaaa, npdoty, Katie_Haritos-Shea, BHill, [IPcaller], tara?, +1.857.209.aabb, karen_oDonoghue, +44.793.550.aacc, Joanne, +1.202.407.aadd, JoeHallCDT, Ryladog?
Present: christine +1.650.944.aaaa npdoty Katie_Haritos-Shea BHill [IPcaller] tara? +1.857.209.aabb karen_oDonoghue +44.793.550.aacc Joanne +1.202.407.aadd JoeHallCDT Ryladog?
Regrets: wseltzer fjh frank karima
Found Date: 04 Dec 2014
Guessing minutes URL: http://www.w3.org/2014/12/04-privacy-minutes.html
People with action items: doty

[End of scribe.perl diagnostic output]