See also: IRC log
<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'
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
http://www.w3.org/TR/2014/WD-powerful-features-20141204/
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
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.
Hannes_Tschofenig: could we invite some Art 29 folks to present or discuss?
christine: yes, can ask Rob.
+1s
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
thanks
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
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
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
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]