16:54:47 RRSAgent has joined #privacy 16:54:47 logging to http://www.w3.org/2013/02/28-privacy-irc 16:54:50 zakim, this will be ping 16:54:51 ok, tlr; I see Team_(privacy)17:00Z scheduled to start in 6 minutes 16:54:58 rrsagent, make log public 16:55:16 Team_(privacy)17:00Z has now started 16:55:23 +[IPcaller] 16:55:58 zakim, IPcaller is me 16:55:58 +Christine; got it 16:56:11 manu has joined #privacy 16:56:21 Thomas, thanks for the help with Zakim. 16:56:47 While we are waiting for the hour to start, would someone kindly volunteer to scribe? 16:57:49 + +1.202.489.aaaa 16:58:02 Apologies: Rob Van Eijk, Frederick Hirsch, and my co-chair Tara Whalen. 16:58:24 +[IPcaller] 16:58:28 npdoty has joined #privacy 16:58:30 -Christine 16:58:43 Ashok_malhotra has joined #privacy 16:58:45 + +33.9.52.22.aabb 16:58:49 Zakim, code? 16:58:49 the conference code is 7464 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), npdoty 16:58:57 +??P1 16:59:02 zakim, I am ??P1 16:59:02 +manu; got it 16:59:15 Agenda:1. Welcome and introductions. 2. Discussion of Encrypted Media Extensions 3. Privacy Considerations and Guidance on Fingerprinting 4. TAG Privacy by Design document 5. AOB 16:59:28 zakim, + +33.9.52.22.aabb is me 16:59:28 I don't understand '+ +33.9.52.22.aabb is me', Karima 16:59:44 We have received a request from Ashok to swap agenda item 3 and 4. 16:59:55 ddorwin has joined #privacy 17:00:09 zakim, aabb is me 17:00:09 +Karima; got it 17:00:18 markw has joined #privacy 17:00:24 Apologies all. I have been dropped from the call. Re-joining. 17:00:28 erin_k_ has joined #privacy 17:00:30 zakim, mute me 17:00:30 Karima should now be muted 17:00:32 ddorwin_ has joined #privacy 17:00:36 +[IPcaller.a] 17:00:43 +OpenLink_Software 17:00:44 adrianba has joined #privacy 17:00:55 joesteele has joined #privacy 17:01:00 +??P14 17:01:12 +markw 17:01:12 Joanne has joined #privacy 17:01:26 +Oliver_Goldman 17:01:49 +??P8 17:01:52 +Joanne 17:02:04 zakim, ??P8 is me 17:02:04 +Ashok_malhotra; got it 17:02:04 zakim, call thomas-781 17:02:05 ok, tlr; the call is being made 17:02:05 +Thomas 17:02:06 yes 17:02:23 + +358.504.87aacc 17:02:24 +ddorwin 17:02:26 zakim, mute thomas 17:02:27 Thomas should now be muted 17:02:36 rigo has joined #privacy 17:02:44 +npdoty 17:02:45 scribenick: manu 17:03:01 - +358.504.87aacc 17:03:03 Christine: We have a full agenda today, welcome everyone. Maybe some introductions are in order. 17:03:22 hsivonen has joined #privacy 17:03:30 + +1.214.566.aadd 17:03:38 zakim, mute aadd 17:03:38 +1.214.566.aadd should now be muted 17:03:39 Christine: First up is discussion on EME - let's make it clear that the purpose of the discussion is not whether or not the EME spec is in scope. 17:03:54 Christine: We are trying to find out if there are privacy considerations in EME, that's what we should be focusing on today. 17:04:01 +[Microsoft] 17:04:06 + +358.504.87aaee 17:04:06 + +1.510.759.aaff 17:04:07 zakim, [Microsoft] is me 17:04:07 +adrianba; got it 17:04:09 +??P40 17:04:16 Christine: Fingerprinting is after that. (scribe missed the rest of the Agenda) - link anyone? 17:04:28 +[IPcaller.aa] 17:04:29 zakim, ??P40 is me 17:04:29 +rigo; got it 17:04:44 Christine: Name an affiliation - people introduce themselves in IRC. 17:04:46 zakim, who is on the phone? 17:04:46 On the phone I see +1.202.489.aaaa, [IPcaller], Karima (muted), manu, [IPcaller.a], TallTed (muted), ??P14, markw, Oliver_Goldman, Ashok_malhotra, Joanne, Thomas (muted), ddorwin, 17:04:46 http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0052.html 17:04:50 ... npdoty, +1.214.566.aadd (muted), adrianba, +1.510.759.aaff, +358.504.87aaee, rigo, [IPcaller.aa] 17:04:59 Nick Doty, W3C 17:05:00 erin kenneally, elchemy 17:05:02 Joanne Furtsch with TRUSTe 17:05:03 Present+ Joe Hall, CDT 17:05:04 Mark Watson, Netflix 17:05:05 Henri Sivonen, consulting for Mozilla 17:05:07 Christine Runnegar, co-chair 17:05:13 joesteele, Adobe Systems 17:05:13 Karima Boudaoud, University of Nice Sophia Antipolis 17:05:15 David Dorwin, Google 17:05:17 Wendy Seltzer, W3C 17:05:17 Ashok Malhotra, Oracle 17:05:18 manu: Hi, Manu Sporny from Digital Bazaar, concerned about EME specification, have a history implementing DRM systems - have some privacy concerns about EME today. 17:05:22 Adrian Bateman, Microsoft 17:05:23 Rigo Wenning, W3C 17:05:29 Present+ Frank_Dawson_Nokia 17:05:39 zakim, IPcaller.aa is wseltzer 17:05:40 +wseltzer; got it 17:05:43 Note: Joe Hall CDT on the call but not in IRC 17:05:55 Zack: Zak Rogoss from Free Software Foundation 17:05:55 present+ Zak_Rogoff_FSF 17:06:01 JoeHallCDT has joined #privacy 17:06:02 s/Rogoss/Rogoff/ 17:06:04 s/Zack/Zak/ 17:06:05 Zack Rogoff from Free Software foundation on call but not IRC 17:06:24 present+ Hannes_Tschofenig 17:06:42 Christine: Now that we have introductions out of the way, let's continue to main agenda - EME specification. 17:06:47 Topic: EME Specification 17:07:15 Christine: Thanks for all that joined this call to discuss the EME specification. Let's start with Mark Watson, brief introduction to what the specification is. 17:07:16 - +1.202.489.aaaa 17:07:31 Mark: Thanks for inviting us to join the call - it's important and timely topic. 17:07:42 -ddorwin 17:07:56 yrlesru has joined #privacy 17:08:04 Mark: First, the purpose of the specification - we started the spec at Netflix, people use plugins like Silverlight/Flash to deliver content to web users. One reason we use those plugins is because of the DRM they provide. 17:08:05 yrlesru is Frank Dawson 17:08:26 Mark: What we'd like to use is HTML5 natively, lifetime of some of the plugins is not certain... less use of plugins is good, more use of HTML5 is good. 17:08:33 TallTed has changed the topic to: Privacy Interest Group -- http://www.w3.org/wiki/Privacy -- current agenda http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0052.html 17:08:47 Mark: Purpose of EME is to provide a framework for DRM components, or other components, can be integrated into HTML5 media element. 17:08:56 +[Microsoft] 17:09:07 Mark: Advantages for those CDMs (COntent Decryption Modules) is that these plugins can be more specific and smaller. 17:09:25 Mark: We expect User Agents to have more control over what those CDMs are and what they can do over what plugins can do today. 17:09:36 whois 17:09:37 +ddorwin 17:09:42 Mark: So, we see this as an improvement over plugins. There are privacy implications to this that UAs will have to deal with. 17:10:37 Mark: In terms of scope of EME, the proposal doesn't try to define a DRM or particular CDM, that would be difficult to do for many reasons. We don't try to standardize on a particular one. We want to define a uniform API for those things. 17:11:13 Mark: One of the things we do in particular, which is a departure from traditional DRM, we have Javascript mediate connection between server and CDM. 17:11:32 communication between a CDM and a server-side has to be mediated through JavaScript -- does that mean through the UA? 17:11:44 Mark: So, all communication is mediated by Javascript web application - it enables some functionality like authetnication / authorization, to be done by the application rather than requiring CDM. 17:12:00 Mark: So, that sort of stuff can be handled out of the CDM. 17:12:25 Mark: I think that's a brief overview of the system. It's a uniform API, we don't try to specify what the CDM does or what it is. 17:12:35 npdoty, CDM generates message, gives to browser, browser gives it to JS, JS XHRs it to server (and then the reverse) 17:12:36 + +1.202.489.aagg 17:12:39 Christine: Thanks, any question for Mark? 17:12:45 q+ 17:13:13 ack npdoty 17:13:14 ack npdoty 17:13:42 npdoty: Thanks for the overview, Mark. I appreciate it. I'm new to this area. Need to understand constraints on the CDM. There are more constraints than in the plugin model. 17:14:03 q? 17:14:09 npdoty: Is all communication constrained through the UA? Or do we expect that some CDMs, since they can run arbitrary code, would be able to open up a connection. 17:14:22 Christine has joined #privacy 17:14:34 Mark: CDM is there to handle media in the HTML Media ELement, it's not there to do anything else... how to constrain what it does it up to the UA. 17:14:35 q+ to ask about tcg and relation to web crypto work 17:15:00 Mark: I expect UA implementers to understand what the privacy implications are. 17:15:40 Mark: That's something we'd like to understand better, the responsibility is on the UA to take action on that rather than us mandating things in the specification. I don't think we'd constrain CDMs to communicate directly with the UA. 17:16:00 q+ to ask how user would verify the behaviors of the CDM 17:16:05 Mark: The CDM might communicate with the graphics hardware, so that might be required. 17:16:07 q- later 17:16:23 ack wseltzer 17:16:23 wseltzer, you wanted to ask how user would verify the behaviors of the CDM 17:16:24 ack wseltzer 17:16:39 wseltzer: Does the specification consider how a user would verify what's being communicated through the CDM. 17:16:52 wseltzer: How can users audit the flows of information from the browsers or web applications. 17:17:35 mark: We expect that browsers will pick and choose which CDMs they allow, it's up to the UA. 17:17:51 Mark: If it becomes an issue for browser implementers, it's up to them to figure out how to provide that information to users. 17:18:04 ack rigo 17:18:04 rigo, you wanted to ask about tcg and relation to web crypto work 17:18:06 ack ri 17:18:09 Users should use the same mechanisms they do today to monitor network traffic. 17:18:58 -Karima 17:19:02 rigo: Does this API talk to a secured memory area? I work on the Web Crypto group / Trusted Computing Group - there are lots of connections there... fan of metadata systems, there is a lot of labeling needed here, if you mediate things through JavaScript API, you have limited functionality via the JavaScript API. 17:19:29 rigo: Last question, what about interoperability - if you just specify EME, and not the CDM... why? 17:20:09 +??P4 17:20:18 q+ 17:20:36 zakim, +??P4 is me 17:20:36 sorry, Karima, I do not recognize a party named '+??P4' 17:20:40 mark: The trusted memory area - there are DRM solutions that are based on trusted execution environments, mobile phones mostly. There is a motivations for a closed part and open part. If that's a technique, then the CDM will talk to that Trusted Computing area. EME specification doesn't say what CDMs can do. 17:20:59 specifically we can support software based solutions 17:21:06 zakim, mute me 17:21:06 Karima should now be muted 17:21:11 mark: This is out of scope from the EME specification. We just specify the APi that the JavaScript uses to talk to the CDM module. 17:21:34 off the top of my head, some of the concerns we've had with plugin effects on Web privacy in the past have been: maintaining state within a plugin (Flash LSOs), unmediated access to device sensors (microphone, file system, camera), maybe unrestricted Internet access (violating same-origin policy, say) 17:21:37 Zakim, who is on the phone? 17:21:37 On the phone I see [IPcaller], manu, [IPcaller.a], TallTed (muted), ??P14, markw, Oliver_Goldman, Ashok_malhotra, Joanne, Thomas (muted), npdoty, +1.214.566.aadd (muted), adrianba, 17:21:41 ... +1.510.759.aaff, +358.504.87aaee, rigo, wseltzer, [Microsoft], ddorwin, +1.202.489.aagg, Karima (muted) 17:22:05 zakim, aadd is yrlesru 17:22:05 +yrlesru; got it 17:22:12 rigo: I see a kind of an API, that instead of a plugin, it takes the plugin functionality into the browser. In this system, we now have privacy considerations because opening that API up would mean that relevant personal information is brought to the fore. That's a general question for the Web. 17:22:27 q+ 17:22:30 rigo: re: Metadata systems, I'm not only sending metadata from A to B, I can represent that to the user. 17:22:45 Zakim, +1.510.759.aff is me 17:22:45 sorry, JoeHallCDT, I do not recognize a party named '+1.510.759.aff' 17:22:57 rigo: To do that, you need to know the semantics - is this a personal name that I'm sending over (or an SSN) or is it something like a color. 17:23:03 Zakim, aaff is JoeHallCDT 17:23:03 +JoeHallCDT; got it 17:23:15 rigo: In DRM systems, we have a long history of labeling where a user is aware that the DRM system allows them to do. 17:23:48 rigo: If you have a metadata system , it allows a user to know what their permissions are. If this is just a dumb conduit, it allows anything to go through the conduit. There are no privacy considerations. 17:24:24 rigo: So, the CDM creates the privacy implications - what classes of data do you let through, what classes do you not let through. How are we going to make people aware of what information is being shared? 17:24:43 Mark: This is specific to the CDM and UA? 17:24:45 rigo: Yes 17:25:13 TallTed has joined #privacy 17:25:20 Mark: We don't specify the interface between the UI and the CDM, we expect browser implementers to decouple these sorts of things. They could make a closed system, or they could implement something that makes that information available to users. 17:25:54 Mark: I'd expect they'd take a more restrictive approach, so they can know when privacy implication issues are there. 17:26:16 rigo: That doesn't answer that question, but I give up. 17:26:32 Christine: Let's park the issue, we'll need more discussion about it, maybe on e-mail list. 17:26:44 adrianba: A couple of points to add to what Mark said. 17:26:47 Happy to discuss further offline 17:26:52 I'm not sure I entirely understand Rigo's question either, but I'd like to talk more offline about it 17:27:46 adrianba: There is some discussion about plugins and native implementation, not sure it's helpful to dwell on that. In a similar place, there are some browsers that support WebM - IE, we don't have that built in, but you can install a plugin that achieves that. It doesn't change the implications for the user. People don't seem to mind that the plugin comes from somewhere else. 17:28:33 adrianba: Many of the questions that we've heard today and in recent weeks are good questions for people implementing CDMs, but the goal of the EME spec is to abstract away the CDM implementation. It allows developers to focus on re-using HTML5 media components while adding a common approach to content protection. 17:28:47 adrianba: Rather than saying if you want to use content protection, then everything must be bespoke. 17:29:10 perhaps the point is that the UA (perhaps more likely in the native model) might constrain what the plugin can do (does it fit the Web's security model? does the UA know when state is being maintained?) as opposed to allowing arbitrary execution of code and storage 17:29:49 adrianba: re: interop, we expect that CDMs created that show up in multiple browsers, we expect EME to use ISO common encryption to use same media file to be playable across a variety of devices. 17:29:51 q+ 17:29:56 ack adrianba 17:29:56 ack adrianba 17:30:10 ack hsivonen 17:30:42 hsivonen: The questions I hear seem to assume that the browser doesn't know anything abou twhat the CDM does. If the browser doesn't have a clue about what the CDM does, then letting the CDM send messages through the browser could communicate anything. 17:30:56 Yes, this is what I mean: mere pipes 17:31:22 hsivonen: The API hands bytebuffers over, those buffers can contain anything. If the computer has been assigned a symmetric keypair, if it can decrypt what its sent, then that would uniquely identify that computer. 17:31:48 hsivonen: Potentially, over time (and at the same time), all sites would be able to track that computer. That sort of tracking is not supposed to be possible on the Web Platform. 17:32:26 hsivonen: It's also possible to design the CDM so that this issue doesn't arise. If the browser vendor and CDM vendor can communicate such that CDM doesn't communicate that sort of identifying information, then the browser allows things to happen w/o any sort of notification UI. 17:33:24 Bug 20965 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965) represents the bug about adding language to a privacy considerations section of the spec suggesting that implementers of CDMs should take steps to protect privacy following some of the approaches Henri suggests. 17:33:29 hsivonen: If the browser does know that CDM is communicating information that is private, then to keep the current properties of the web platform, then there would have to be geo-location-style User Authorization. That is, if sites collude, they can figure out who you are, where you are, etc. The solution has to be user notification or browser vendor trusting CDM to not do that sort of thing. 17:34:02 Browser implementers are all motivated to make sure they address these kind of issues but it is the implementation of the CDM that needs to consider this. 17:34:23 hsivonen: Where User Tracking becomes available - sites may be able to, over time, that browser reacts in a way that CDM knows something that's already stored, the browser vendor can establish trust with CDM? Potentially by sandboxing the CDM? Access to persistent storage must be browser-mediated. 17:34:24 I apologize that I am completely new to this area, but: is it possible to design the spec such that CDMs can't uniquely identify a user across sites? similarly, UAs don't just create business agreements with JavaScript app developers, they enforce a same-origin policy 17:34:41 hsivonen: The Privacy characteristics depends on what the CDM does, then if you must assume that you can't know, then there are privacy problems. 17:35:00 hsivonen: The browser could do without that sort of labeling if we knew this information 17:35:02 q? 17:35:30 scribenick: npdoty 17:35:39 adrianba, are there plans to integrate with DNT? 17:36:02 manu: I think hsivonen hit the nail on the head; something fundamental about EME that makes many people nervous that there is an abdication of responsibility to the CDM 17:36:04 q+ 17:36:23 ... either have to trust the CDM not to violate user privacy, or understand what it may do and restrict it in such a way that it doesn't create the privacy concerns 17:36:24 EME is a highly controversial specification: 17:36:26 http://wiki.whatwg.org/wiki/Encrypted_Media_Extensions_Impact 17:36:26 rigo, web sites using XMLHttpRequest would make network requests subject to DNT the same as any app that uses XHR 17:36:27 http://manu.sporny.org/2013/drm-in-html5/ 17:36:29 http://www.brucelawson.co.uk/2013/more-on-drm-in-html5/ 17:36:37 ack manu 17:36:38 ... fair to say that EME is controversial 17:36:40 The EME specification is silent on Do Not Track. It should contain text making it clear how CDMs are supposed to interoperate with DNT and honor privacy settings. 17:36:51 adrianba, this is encouraging 17:37:04 rigo, EME doesn't define any network communication so it can't intrinsically mention DNT 17:37:15 ... regarding privacy, silent on Do Not Track, no way to communicate a DNT signal to the CDM, no specification of how the CDM could read that information 17:37:45 ... with closed-source implementations, no way to verify CDM is respecting such a signal 17:37:50 The following might be of interest in overview of information privacy concerns with DRM/CRM: 17:37:51 http://epic.org/privacy/drm/ 17:37:54 q+ 17:37:57 q+ 17:38:02 q- later 17:38:08 npd: adrianba, rigo, we could expose the DNT signal to the CDM though, couldn't we? we've discussed providing a signal to plugins 17:38:16 The entertainment industry has a history of including software that reports usage back to media companies: http://en.wikipedia.org/wiki/Sony_BMG_copy_protection_rootkit_scandal. EME should ensure that network access is restricted to only what's necessary to decrypt the content. 17:38:27 npdoty: yep 17:38:38 manu: the other privacy concern is that entertainment has a history of software tracking users, e.g. the Sony rootkit example 17:38:41 I disagree with the assertion that CDMs will not voluntarily comply with DNT 17:38:57 some will -- some may not 17:39:04 ... probably a requirement restricting network access 17:39:19 ... no enforcement of JavaScript-mediated network access 17:39:21 but privacy is not the only issue they have to address if they put themselves in a midiator position between service, user and CDM 17:39:22 npdoty, it's for user agents to define how code that might have network communication interfaces to DNT 17:39:40 ... as hsivonen, could even put that information in a byte buffer and send it back encrypted 17:40:10 CDMs are outside of the browsers control, but can be used to control the browser. At present, nobody can verify how secure a CDM is. Does it have a backdoor for access to the browser cache or operating system? Is it restricted for only a subset of operations? Can it access your personal data? How prone to attack is it? There should be technical solutions to these questions, such as a certain... 17:40:12 ...sandboxing requirement that disallows any access to the underlying file system, for instance. 17:40:12 ... best interest for all to restrict network access more than it's restricted right now 17:40:20 q- 17:41:10 manu: CDMs being completely outside the browser control, DRM solution developers keep implementations private; unlikely that Mozilla would be able to "see inside" to determine how it works 17:41:18 ... question is what CDMs can do when they're installed 17:41:45 ... should be a requirement to sandbox, can't access file system, can't access network outside the browser, a number of other restrictions 17:41:55 ... have been hearing that this is out of scope, which I don't accept 17:42:07 ... network sandboxing and OS sandboxing is well within that discussion 17:42:08 adrianba: many, IMHO, we would have to ask Ashkan about it 17:42:15 -[IPcaller.a] 17:42:18 yes 17:42:18 it is Christine's connection 17:42:25 I can hear... 17:42:30 How are CDMs going to be audited by privacy groups? At the moment, there is no such organization that is capable of auditing these systems for privacy implications. 17:42:30 Oops, I have been dropped 17:42:45 manu: 4th, how CDMs could be audited by privacy groups 17:43:07 +[IPcaller.a] 17:43:13 ... might generally be outside the scope, but if we're going to talk about privacy, we would need to talk about possibilities of auditing 17:43:23 zakim, IPcaller.a is probably Christine 17:43:23 +Christine?; got it 17:43:24 Zakim, IP caller.a is me 17:43:24 I don't understand 'IP caller.a is me', Christine 17:43:51 ... there are a slew of other concerns about interop, particularly for a company like Mozilla 17:44:27 ... difficult to understand how it will be supported across platforms (OS's, device platforms) 17:44:42 A single CDM isn't required to be available on every architecture because of ISO Common Encryption 17:45:09 adrianba, that assumes that all content providers have server back ends for all Key Systems 17:45:10 q? 17:45:14 ... open-source browsers can be ported to any system, but for the CDM, users would be at the mercy of CDM developers 17:45:16 scribenick: manu 17:45:26 -Karima 17:45:31 Christine: I don't think we're going to be able to get to the TAG document in detail. 17:45:32 q? 17:45:35 q- 17:45:42 ack markw 17:45:43 Christine: Could you make comemnts on what Manu said? 17:46:06 Mark: I think the main response to many of the points that Manu raised, is that the approach that we're offering is a significant improvement over the situation today. 17:46:19 q+ to say that a solution should be more than just a small improvement. 17:46:23 +??P0 17:46:37 zakim, +??P0 is me 17:46:37 sorry, Karima, I do not recognize a party named '+??P0' 17:46:43 hsivonen, no, not all key systems but it does add additional flexibility 17:46:56 zakim, +??P0 is Karima 17:46:56 sorry, Karima, I do not recognize a party named '+??P0' 17:47:07 Mark: Mobile devices, tablets, TVs. Most of the questions raised, before a UA provides support for a CDM, they do need to understand that CDM. I don't think CDMs need network access. I don't expect browsers will allow that. 17:47:10 q+ 17:47:25 zakim, P0 is Karina 17:47:25 sorry, joesteele, I do not recognize a party named 'P0' 17:47:40 zakim, P0 is me 17:47:40 sorry, Karima, I do not recognize a party named 'P0' 17:47:57 Mark: We have an opportunity to do that with this system. As far as what the spec says, I don't think writing text in the specification will achieve what Manu wants to achieve. Just because we say CDMs shouldn't do XYZ, doesn't mean that they'll implement it. Specs are just words on paper. 17:48:04 zakim, P0 is Karima 17:48:04 sorry, Karima, I do not recognize a party named 'P0' 17:48:12 Mark: If browser integrators say that they will not work with a CDM if they won't do XYZ. 17:48:36 q? 17:48:47 ack manu 17:48:47 manu, you wanted to say that a solution should be more than just a small improvement. 17:48:55 adrianba, thanks for sharing that bug on the privacy considerations section, the discussion is very interesting 17:49:16 manu: markw is correct that this would be an improvement from the current state, have a chance here to design this correctly, otherwise this is just an incremental improvement 17:49:40 ... have to take the questions raised during this call, try to figure out technical solutions or spec requirements 17:49:53 ... true that they're words on paper, but browser implementers do care about them 17:50:14 ... negotiation that can happen where a CDM can exist with many lessened privacy impacts 17:50:23 -Ashok_malhotra 17:50:23 ack ri 17:50:24 ... Mark's points are valid, but I believe we can do better 17:50:36 scribenick: manu 17:50:52 rigo: For the moment, I see a pipe for the actual encryption format, how to tell the browser that the CDM can download something. 17:51:29 @manu: agreed - if we can provide text in the specification which gives browser and CDM implementors guidance about the privacy impacts they need to consider and understand, this is good 17:51:34 rigo: That's fine, I agree with Manu, we need to go beyond, perhaps not in a required way, but the people who really design this should think about the do's and don'ts... a CDM in the Web context. Users don't think about this very often. 17:51:53 how do CDMs operate with the web security model? 17:52:00 rigo: You can write this down in a non-normative way. I'm with Henri as well and Manu - as soon as you allow network access, you have to be very careful. 17:52:01 I'd really like to encourage people to propose spec text 17:52:16 adrianba, +1 17:52:19 Christine: Rigo, could you lead this group in a privacy review of this draft specification? 17:52:30 q+ 17:52:37 rigo: Depends on the timeframe, I have an important meeting in two weeks - as long as it takes longer than that, it's fine. 17:52:39 q? 17:52:51 q+ 17:52:53 Christine: What's the timeframe for the specification? How long for a privacy review? 17:52:57 q- later 17:52:58 adrianba, I have proposed spec text about CDM characteristics that call for geolocation-style flow 17:53:04 q? 17:53:18 ack ad 17:53:25 adrianba: On timing, I think that it's still early days in the specification. 17:53:36 adrianba: A FPWD doesn't require us to solve all of the problems. 17:53:40 specifically, if the UA implementor understands the privacy properties of the CDM they can choose between approaches: don't allow this CDM, only allow with explicit user authorization, allow always etc. 17:53:56 adrianba: The current ED includes a note in the status of the document highlighting the fact that we need to discuss privacy issues in the spec. 17:54:15 adrianba: I don't think you're faced with a deadline... far longer than that. 17:54:30 nope 17:55:02 npdoty: Thanks for sharing that bug Adrian - I think the experience we've had is that it's useful to have privacy discussions early on... good to know that it's a pressing deadline. 17:55:19 npdoty: Are there particular suggestions on how we can propose text for privacy considerations? 17:55:35 npdoty: Sounds like what we're talking about right now is changes to the design. 17:55:38 it would be good to call out privacy considerations that are not already in that bug -- as Henri has done 17:55:47 adrianba: File a bug if you think there is something that needs to be fixed. 17:56:16 hsivonen, yes, i see your comments - i think this is the key thing we will need to address but i think mostly what we can do is call out considerations for CDM implementers 17:56:38 Christine: An hour isn't sufficient time to fully understand the spec, we need to do some more thinking as a group... Rigo, I'm volunteering you to lead our privacy review of the specification. 17:56:43 Rigo: Works for me. 17:56:45 [bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965 ] 17:56:52 As to the agenda item Nick suggested for drafting of privacy considerations process, I am all-in and will discuss this with Nick later today, after the call 17:57:09 Christine: AOB? 17:57:22 since not all of us are far enough along in understanding the spec design to file bugs, I suggest we have some conversation on public-privacy@ as well 17:57:37 Topic: TAG Privacy by Design 17:57:44 Christine: We'll cover this on the next call. 17:57:54 Topic: Privacy Considerations and Fingerprinting 17:58:14 Christine: Can we cover this quickly? 17:58:31 Nick: Yes, some background. 17:58:52 Nick: TAG had worked on a privacy by design API. I was working on Fingerprinting document, maybe we should merge those. 17:59:04 Nick: This group might take over that work. 17:59:43 Nick: So, short answer - I think we should do that. I'm willing to take the lead. Real question - how are we going to split up those documents? Who are we going to work with in the TAG on this document? 18:00:10 Nick: We are getting some practice some privacy reviews - Frank Dawson has suggested some ideas on how to do privacy reviews (the process) 18:00:40 Christine: Frank, the implication is that you're leading the work on the process for this? 18:00:50 Frank: Yes, I will lead that work. 18:01:05 -Karima 18:01:20 ???: Nick has made during the last call to setup questions for these privacy reviews, I've tried to find those, but unable to do so. Where are these questions? 18:01:57 Nick: I don't think there is something specific, but we can pull them out of the document they were in. 18:02:00 ???: Name of thread? 18:02:07 -Oliver_Goldman 18:02:08 Nick: I'll volunteer to pull out a link to that. 18:02:16 Christine: Can somebody else volunteer to start putting the list together. 18:02:18 Sounds like a check-list approach to privacy review? 18:02:23 -adrianba 18:02:29 -wseltzer 18:02:29 Better than an "ad hoc" approach, I suppose... 18:02:30 No victims step forward. 18:02:39 Christine: Nick, get the link, please and we'll go from there. 18:02:47 Christine: Any comments on this? 18:02:52 s/???/Hannes/ 18:02:53 +1 (good idea) 18:03:02 agree 18:03:10 +1 18:03:29 +1 18:03:35 ZZZ: I'm a bit concerned about the content. 18:03:40 +1 for Nick 18:03:42 s/ZZZ/Hannes/ 18:03:46 Christine: I'm more concerned about process, not content right now. 18:03:59 as a side note, I might agree with Hannes about concerns on the content 18:04:13 Christine: AOB? 18:04:35 Christine: Thanks for those that joined to talk about EME. 18:04:42 yes, much thanks manu, adrianba, markw, hsivonen 18:04:43 -[IPcaller] 18:04:49 [ADJOURNED] 18:04:54 -Thomas 18:04:55 -Joanne 18:04:55 -[Microsoft] 18:04:57 -TallTed 18:04:58 -JoeHallCDT 18:05:00 -npdoty 18:05:01 -rigo 18:05:02 -manu 18:05:03 -??P14 18:05:05 -ddorwin 18:05:05 -Christine? 18:05:07 -markw 18:05:14 - +358.504.87aaee 18:05:40 - +1.202.489.aagg 18:05:44 (I guess ??P14 was me, in case it's needed for minutes) 18:06:21 rrsagent, draft minutes 18:06:21 I have made the request to generate http://www.w3.org/2013/02/28-privacy-minutes.html manu 18:06:27 RRSAgent, make logs public 18:10:41 disconnecting the lone participant, yrlesru, in Team_(privacy)17:00Z 18:10:42 Team_(privacy)17:00Z has ended 18:10:42 Attendees were Christine, +1.202.489.aaaa, [IPcaller], +33.9.52.22.aabb, manu, Karima, TallTed, markw, Oliver_Goldman, Joanne, Ashok_malhotra, Thomas, +358.504.87aacc, ddorwin, 18:10:42 ... npdoty, +1.214.566.aadd, +358.504.87aaee, +1.510.759.aaff, adrianba, rigo, wseltzer, [Microsoft], +1.202.489.aagg, yrlesru, JoeHallCDT, Christine? 18:13:45 npdoty: Is someone else going to clean up the minutes? I've prepared the draft... and made the logs public... I can't publish since I'm not in this group. 18:14:53 rrsagent, make minutes 18:14:53 I have made the request to generate http://www.w3.org/2013/02/28-privacy-minutes.html wseltzer 18:15:42 thanks manu 18:16:10 np :) 18:16:55 rigo has left #privacy 20:46:46 Zakim has left #privacy 20:51:53 manu has left #privacy 22:14:46 npdoty has joined #privacy