<trackbot> Date: 22 August 2013

<christine> Zakim [IPcaller] is me

<christine> Agenda: 1. Welcome and introductions 2. Introduction to the draft Web Cryptography API and discussion of privacy considerations 3. Update re privacy guidance documents (Privacy Considerations; Fingerprinting; Process) 4. Update re getUserMedia privacy review 5. Update re EME privacy review 6. AOB

<npdoty> rsleevi, can you scribe, and I'll scribe during the Crypto discussion?

<rsleevi> npdoty: I'm not in a place to scribe atm

<npdoty> scribenick: npdoty

virginie: Virginie Galindo, chairing the Web Crypto WG

markw: Mark Watson, from Netflix

<virginie> virginie is virginie galindo, chairing web crypto WG, working for gemalto

rsleevi: Ryan Sleevi, editing

Karen Donohoe, Internet Society

<fjh> Frederick Hirsch, Nokia

<JoeHallCDT> Joe Hall, CDT!

<JC> JC Cannon, Microsoft Online Services

<christine> Christine Runnegar, co-chair

<karen_odonoghue> Karen O'Donoghue, Internet Society

npd: Nick Doty, W3C

<tara> Welcome, newcomers! Tara Whalen, Apple (co-chair for PING).

<karen> Karen Lu from Gemalto

<christine> 2. Introduction to the draft Web Cryptography API and discussion of privacy considerations

Web Crypto

christine: request from Crypto WG for review, some work in design decisions regarding privacy considerations
... someone from Web Crypto to give us a walkthrough

rsleevi: try to summarize, 3 documents under active development: Web Crypto, named pre-provision key, non-normative use cases
... lot of discussion early on regarding persistent identifiers, identify and address keys
... API provides basic cryptographic services, encrypt/decrypt, sign, hash
... opaque key handles, not dealing with the raw key material, may or may not be able to extract the key material
... the privacy mitigations we've tried to work through: key material is extremely random
... and not shared with anyone in the world
... has a privacy risk of a very long persistent identifier with a strong mathematical binding for example for non-repudiation
... the storage of these keys is treated as the same Web storage technologies
... IndexedDB or PostMessage
... choice of that design is to leverage the same privacy characteristics as those
... if the user clears them, clears the others
... lifetime of the key to lifetime of existing storage mechanisms
... under discussion is extractability, can strongly identify particular user agents
... leave that discussion to Mark

<virginie> the recent draft is available here : https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html

<JoeHallCDT> npdoty: great job documenting privacy considerations…

<virginie> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#privacy

<JoeHallCDT> … is what you described as a supercookie really a canonical super cookie?

<JoeHallCDT> … there is a long list of ennumerated algorithms, are we expecting a lot of diversity in implementation?

npd: +1, I think those persistent (perhaps permanent?) identifiers are a serious concern, I just wasn't sure about calling that "super-cookie" -- is that what we usually mean?

npdoty: pre-provisioned keys, or other keys generated outside of this API itself
... has use cases, Mark has worked on privacy considerations for that
... could be tied to a smart card, or a particular user's identity

rsleevi: realistically, expect to see a choice of algorithms, not enabled/disabled by a specific user, not installed arbitrarily like fonts
... no plans in this version for extending that list of algorithms programmatically, plugins for browser vendors
... realistically the choice is going to be fixed by User Agent and Operating System and potentially User Agent version
... and that information is currently leaked through other means, so not adding to it

<JoeHallCDT> npdoty: privacy considerations are all non-normative… shouldn't there be some normative requirements about same-origin?

rsleevi: don't define a storage mechanism, this is done via existing mechanisms, like IndexedDB, so origin protections would be handled by those specs
... can arbitrarily send across origins via PostMessage, so same risks and mitigations

markw: Web Crypto Key Discovery, named origin-specific pre-provisioned keys

<virginie> Web Crypto Key Discovery API is available here : http://www.w3.org/TR/webcrypto-key-discovery/

markw: for services like Netflix's or similar, devices like televisions, set-top boxes, etc.
... manufacturers pre-provision those with keys for a specific service, so that we can identify those devices
... which we need to do for business purposes
... for video services, access those keys which have been pre-provisioned
... named keys but we expect to pre-define what the name would be with those manufacturers

<JoeHallCDT> the line is very tinny

markw: origin-specific named pre-provision keys, have a bunch of privacy considerations described

<virginie> http://www.w3.org/TR/webcrypto-key-discovery/#privacy-considerations

markw: can identify the user to a service
... just generates an object that otherwise is defined by Web Crypto
... privacy considerations section, but still ask for review

christine: PING calls are a chance to get an overview, with a chance to think over in order to give specific feedback

virginie: is there a timeline on review of the spec? when can we check the box that it's reviewed by the PING? is one month feasible?

christine: ask for a volunteer or two to lead a review of the specs
... anyone on the call? or I have some people I could tap on the shoulder
... will ask some people offline for review. is the deadline hard?

virginie: would be good to solve issues by Last Call, which is planned for fall, around TPAC, so good to get issues earlier to get technical solutions in the WG

christine: good to know, different groups have tended to have different timelines

<JoeHallCDT> npdoty: key discovery could allow an extremely persistent identifier...

<JoeHallCDT> … won't really be like clearing cookies which is how we deal with local storage

<JoeHallCDT> … any ideas about how to solve these problems or handle this situation?

<scribe> scribenick: JoeHallCDT

rsleevi: from the UA side, we are concerned about this and currently don't have plans to implement this...

… this is probably more intended for the embedded device scenario

… we do have reservations about this, even when connected to a user's cookie store

… the user interaction should allow the user to understand the risks

markw: would say the UA/Device that has an anonymity mode should not respond with this information

… this can be a mechanism for controling the exposure of this resource

npdoty: (didn't understand the q)

<npdoty> npd: but it could still be transmitted across origins, I could start a business with a hardware embedded key and share it with PostMessage, right?

rseelvi: as far as comm. to users, e.g., what Moz does with FF users, the incognito or private browsing modes are not seen as anonymity

… they are not modes that prevent tracking

… by granting access to a key to an origin, that could include multiple origins

… exists elsewhere

… e.g., in a geolocation API an origin can surely postmessage to another origin

… (essentially it's hard to constraint server-side sharing of tracking elements)

<npdoty> except the random number could be a hardware-embedded device identifier in this case, right?

+1

markw: origins can collude on server side using information from the client side… there's no additional issue raised by this that is different

<npdoty> thanks markw and rsleevi; I still have concerns, but they're much better informed now :)

<christine> 3. Update re privacy guidance documents (Privacy Considerations; Fingerprinting; Process)

<scribe> agenda: update on various privacy consideration documents

Update re privacy guidance documents (Privacy Considerations; Fingerprinting; Process)

neither Hannes nor Frank appear to be on the call

npdoty to give quick update on fingerprinting doc

<npdoty> http://w3c.github.io/fingerprinting-guidance/

npdoty: have lots of good input

… WebCrypto gives yet another set of things to consider in the space of cookie-like stuff

… this document tries to describe both passive (no code) and active (ship code to the UA) fingerprinting

… then cookie-like fingerprinting that involves storing state in the UA

… passive fingerprinting are the most dangerous, hard to detect, block

… so we should avoid increasing this capability

… wrt to active, if you run enough code on the UA, you can do arbitrary fingerprinting

<npdoty> http://w3c.github.io/fingerprinting-guidance/#clearing-all-local-state

… have a new section that talks about clearing local state

…. any spec that enables setting and retrieving local state, needs to note that

… must call that out so that UAs can knowingly clear state with their mechanism

… UAs may not be able to clear all local state

… e.g., pre-specified keys, I may lose my ability to see netflix videos

q

<fjh> joeHallCDT: surprised passive mentioned as more dangerous, hard to detect but active can be amazing attacks

npdoty: when I say danger, danger! the height of the concern is related to prevention on the client and hard to externally detect

… the way to address this is to say that maybe the entropy is not as high and web specs should not increase the entropy unless not strictly necessary

… there may be mitigations for active fp that aren't as effective

… in part, what we're hearing that the attacks are so sophisticated that why should we deal with this at all in *our* spec?

<npdoty> yes, I'll help anyone who wants to contribute with pull requests on github

<christine> 4. Update re getUserMedia privacy review 5. Update re EME privacy review 6. AOB

christine: Hannes is leading getUserMedia and Frank has given input

… also have EME privacy review and been tapped on the shoulder

… Joe has offered to help

wseltzer: no update, but excitement!

<Zakim> npdoty, you wanted to comment on EME

<markw_> Content Decryption Modules

npdoty: are we just talking about CDMs or other things
... is this review about CDMs or other parts that we're trying to review?

wseltzer: haven't scope it, but are looking for places that the use of EME could raise privacy concerns

… some of those could be outside EME per se, in CDMs, or in exchange of information described by EME specifically

christine: one problem is a lot of our privacy experts have been working in the TPW (DNT) WG

<npdoty> JoeHallCDT: question for markw, are there places you would specifically like to see input in particular on EME? that mailing list has been on/off topic. what would you like to see from PING?

markw: probably not a great deal in the EME spec itself

… big question, providing constraints, guidances as to what CDMs should/shouldn't do wrt privacy

… we see it as what people do today with proprietary DRM and don't know what's going on

… but might we have some common constraints around them?

<christine> Note: it would also be useful to review the earlier PING discussion re EME in the informal chairs summary

… don't have a lot of suggestions, but there is quite a bit of conversation on that list about options.

<npdoty> this might be a chance for us to think about privacy guidelines for Web plugins in general

oh boy, no ambition, npdoty

<npdoty> why solve a problem when you can solve all problems simultaneously

punk

<christine> AOB - discovery of privacy policies

<karen_odonoghue> +q

ack

<wseltzer> [ http://tosback.org/ ]

ndoty: part of the impetus for the discussion of privacy policy discovery and simplification is to make those projects easier

<christine> examples of work - EFF TosBack and WSJ Data transparency hackathon

karen_odonoghue: we thought it would be helpful to separate the TOS archive and analysis, and standardize the interface

… if there were a way to create that interface/API, that would be neat

… Inet Soc. and EFF had discussed developing that API, but haven't made a lot of progress

npdoty: for this imagined API, what would the interaction be?

karen_odonoghue: this is more along the lines of analyzing changes over time and getting specific policies for a specific site

… as part of the data transparency hackathon, TOSback went from 50 to 500 policies

… as far as a standardized location for a PP on a site, that would be another aspect, not currently what we're looking at

npdoty: please put us in touch with TOSBack2 folks

karen_odonoghue: will send a note to the list

christine: adjorned

<npdoty> September 19th or October 3rd?

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/Gemaldo/Galindo/
Succeeded: s/Micrsoft/Microsoft/
Succeeded: s/guidance for//
Found ScribeNick: npdoty
Found ScribeNick: JoeHallCDT
Inferring Scribes: npdoty, JoeHallCDT
Scribes: npdoty, JoeHallCDT
ScribeNicks: npdoty, JoeHallCDT
Default Present: [IPcaller], npdoty, christine, fjh, [Microsoft], tara, Karen, JoeHallCDT, markw, +1.512.257.aaaa, Virginie?, kodonog, +1.650.275.aabb, rsleevi, +358.504.87aacc, Wendy
Present: [IPcaller] npdoty christine fjh [Microsoft] tara Karen JoeHallCDT markw +1.512.257.aaaa Virginie? kodonog +1.650.275.aabb rsleevi +358.504.87aacc Wendy Frederick_Hirsch
Found Date: 22 Aug 2013
Guessing minutes URL: http://www.w3.org/2013/08/22-privacy-minutes.html
People with action items: