<Christine> Thomas, thanks for the help with Zakim.

<Christine> While we are waiting for the hour to start, would someone kindly volunteer to scribe?

<Christine> Apologies: Rob Van Eijk, Frederick Hirsch, and my co-chair Tara Whalen.

<Christine> 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

<Christine> We have received a request from Ashok to swap agenda item 3 and 4.

<Christine> Apologies all. I have been dropped from the call. Re-joining.

<Karima> yes

<manu> scribenick: manu

Christine: We have a full agenda today, welcome everyone. Maybe some introductions are in order.
... 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.
... We are trying to find out if there are privacy considerations in EME, that's what we should be focusing on today.
... Fingerprinting is after that. (scribe missed the rest of the Agenda) - link anyone?
... Name an affiliation - people introduce themselves in IRC.

<npdoty> http://lists.w3.org/Archives/Public/public-privacy/2013JanMar/0052.html

<npdoty> Nick Doty, W3C

<erin_k_> erin kenneally, elchemy

<Joanne> Joanne Furtsch with TRUSTe

<markw> Mark Watson, Netflix

<hsivonen> Henri Sivonen, consulting for Mozilla

<Christine> Christine Runnegar, co-chair

<joesteele> joesteele, Adobe Systems

<Karima> Karima Boudaoud, University of Nice Sophia Antipolis

<ddorwin> David Dorwin, Google

<wseltzer> Wendy Seltzer, W3C

<Ashok_malhotra> Ashok Malhotra, Oracle

manu: Hi, Manu Sporny from Digital Bazaar, concerned about EME specification, have a history implementing DRM systems - have some privacy concerns about EME today.

<adrianba> Adrian Bateman, Microsoft

<rigo> Rigo Wenning, W3C

<Christine> Note: Joe Hall CDT on the call but not in IRC

Zak: Zak Rogoff from Free Software Foundation

<Christine> Zack Rogoff from Free Software foundation on call but not IRC

Christine: Now that we have introductions out of the way, let's continue to main agenda - EME specification.

EME Specification

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.

Mark: Thanks for inviting us to join the call - it's important and timely topic.
... 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.

<yrlesru> yrlesru is Frank Dawson

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.
... Purpose of EME is to provide a framework for DRM components, or other components, can be integrated into HTML5 media element.
... Advantages for those CDMs (COntent Decryption Modules) is that these plugins can be more specific and smaller.
... We expect User Agents to have more control over what those CDMs are and what they can do over what plugins can do today.

<yrlesru> whois

Mark: So, we see this as an improvement over plugins. There are privacy implications to this that UAs will have to deal with.
... 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.
... One of the things we do in particular, which is a departure from traditional DRM, we have Javascript mediate connection between server and CDM.

<npdoty> communication between a CDM and a server-side has to be mediated through JavaScript -- does that mean through the UA?

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.
... So, that sort of stuff can be handled out of the CDM.
... 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.

<hsivonen> npdoty, CDM generates message, gives to browser, browser gives it to JS, JS XHRs it to server (and then the reverse)

Christine: Thanks, any question for Mark?

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.
... 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.

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.
... I expect UA implementers to understand what the privacy implications are.
... 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.
... The CDM might communicate with the graphics hardware, so that might be required.

<Zakim> wseltzer, you wanted to ask how user would verify the behaviors of the CDM

wseltzer: Does the specification consider how a user would verify what's being communicated through the CDM.
... How can users audit the flows of information from the browsers or web applications.

mark: We expect that browsers will pick and choose which CDMs they allow, it's up to the UA.
... If it becomes an issue for browser implementers, it's up to them to figure out how to provide that information to users.

<Zakim> rigo, you wanted to ask about tcg and relation to web crypto work

<adrianba> Users should use the same mechanisms they do today to monitor network traffic.

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.
... Last question, what about interoperability - if you just specify EME, and not the CDM... why?

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.

<joesteele> specifically we can support software based solutions

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.

<npdoty> 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)

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.
... re: Metadata systems, I'm not only sending metadata from A to B, I can represent that to the user.
... 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.
... In DRM systems, we have a long history of labeling where a user is aware that the DRM system allows them to do.
... 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.
... 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?

Mark: This is specific to the CDM and UA?

rigo: Yes

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.
... I'd expect they'd take a more restrictive approach, so they can know when privacy implication issues are there.

rigo: That doesn't answer that question, but I give up.

Christine: Let's park the issue, we'll need more discussion about it, maybe on e-mail list.

adrianba: A couple of points to add to what Mark said.

<markw> Happy to discuss further offline

<npdoty> I'm not sure I entirely understand Rigo's question either, but I'd like to talk more offline about it

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.
... 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.
... Rather than saying if you want to use content protection, then everything must be bespoke.

<npdoty> 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

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.

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.

<rigo> Yes, this is what I mean: mere pipes

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.
... 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.
... 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.

<adrianba> 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.

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.

<adrianba> 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.

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.

<npdoty> 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

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.
... The browser could do without that sort of labeling if we knew this information

<npdoty> scribenick: npdoty

<rigo> adrianba, are there plans to integrate with DNT?

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
... 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

<manu> EME is a highly controversial specification:

<manu> http://wiki.whatwg.org/wiki/Encrypted_Media_Extensions_Impact

<adrianba> rigo, web sites using XMLHttpRequest would make network requests subject to DNT the same as any app that uses XHR

<manu> http://manu.sporny.org/2013/drm-in-html5/

<manu> http://www.brucelawson.co.uk/2013/more-on-drm-in-html5/

manu: fair to say that EME is controversial

<manu> 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.

<rigo> adrianba, this is encouraging

<adrianba> rigo, EME doesn't define any network communication so it can't intrinsically mention DNT

manu: 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
... with closed-source implementations, no way to verify CDM is respecting such a signal

<yrlesru> The following might be of interest in overview of information privacy concerns with DRM/CRM:

<yrlesru> http://epic.org/privacy/drm/

npd: adrianba, rigo, we could expose the DNT signal to the CDM though, couldn't we? we've discussed providing a signal to plugins

<manu> 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.

<rigo> npdoty: yep

manu: the other privacy concern is that entertainment has a history of software tracking users, e.g. the Sony rootkit example

<joesteele> I disagree with the assertion that CDMs will not voluntarily comply with DNT

<joesteele> some will -- some may not

manu: probably a requirement restricting network access
... no enforcement of JavaScript-mediated network access

<rigo> but privacy is not the only issue they have to address if they put themselves in a midiator position between service, user and CDM

<adrianba> npdoty, it's for user agents to define how code that might have network communication interfaces to DNT

manu: as hsivonen, could even put that information in a byte buffer and send it back encrypted

<manu> 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...

<manu> ...sandboxing requirement that disallows any access to the underlying file system, for instance.

manu: best interest for all to restrict network access more than it's restricted right now
... 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
... question is what CDMs can do when they're installed
... should be a requirement to sandbox, can't access file system, can't access network outside the browser, a number of other restrictions
... have been hearing that this is out of scope, which I don't accept
... network sandboxing and OS sandboxing is well within that discussion

<rigo> adrianba: many, IMHO, we would have to ask Ashkan about it

<Karima> yes

<tlr> it is Christine's connection

<yrlesru> I can hear...

<manu> 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.

<Christine> Oops, I have been dropped

manu: 4th, how CDMs could be audited by privacy groups
... might generally be outside the scope, but if we're going to talk about privacy, we would need to talk about possibilities of auditing
... there are a slew of other concerns about interop, particularly for a company like Mozilla
... difficult to understand how it will be supported across platforms (OS's, device platforms)

<adrianba> A single CDM isn't required to be available on every architecture because of ISO Common Encryption

<hsivonen> adrianba, that assumes that all content providers have server back ends for all Key Systems

manu: open-source browsers can be ported to any system, but for the CDM, users would be at the mercy of CDM developers

<manu> scribenick: manu

Christine: I don't think we're going to be able to get to the TAG document in detail.
... Could you make comemnts on what Manu said?

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.

<adrianba> hsivonen, no, not all key systems but it does add additional flexibility

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.
... 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.
... If browser integrators say that they will not work with a CDM if they won't do XYZ.

<Zakim> manu, you wanted to say that a solution should be more than just a small improvement.

<npdoty> adrianba, thanks for sharing that bug on the privacy considerations section, the discussion is very interesting

<npdoty> 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

<npdoty> ... have to take the questions raised during this call, try to figure out technical solutions or spec requirements

<npdoty> ... true that they're words on paper, but browser implementers do care about them

<npdoty> ... negotiation that can happen where a CDM can exist with many lessened privacy impacts

<npdoty> ... Mark's points are valid, but I believe we can do better

<npdoty> scribenick: manu

rigo: For the moment, I see a pipe for the actual encryption format, how to tell the browser that the CDM can download something.

<markw> @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

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.

<wseltzer> how do CDMs operate with the web security model?

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.

<adrianba> I'd really like to encourage people to propose spec text

<npdoty> adrianba, +1

Christine: Rigo, could you lead this group in a privacy review of this draft specification?

rigo: Depends on the timeframe, I have an important meeting in two weeks - as long as it takes longer than that, it's fine.

Christine: What's the timeframe for the specification? How long for a privacy review?

<hsivonen> adrianba, I have proposed spec text about CDM characteristics that call for geolocation-style flow

adrianba: On timing, I think that it's still early days in the specification.
... A FPWD doesn't require us to solve all of the problems.

<markw> 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.

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.
... I don't think you're faced with a deadline... far longer than that.

<tlr> nope

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.
... Are there particular suggestions on how we can propose text for privacy considerations?
... Sounds like what we're talking about right now is changes to the design.

<joesteele> it would be good to call out privacy considerations that are not already in that bug -- as Henri has done

adrianba: File a bug if you think there is something that needs to be fixed.

<adrianba> 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

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.

Rigo: Works for me.

<wseltzer> [bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20965 ]

<yrlesru> 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

Christine: AOB?

<npdoty> 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

TAG Privacy by Design

Christine: We'll cover this on the next call.

Privacy Considerations and Fingerprinting

Christine: Can we cover this quickly?

Nick: Yes, some background.
... TAG had worked on a privacy by design API. I was working on Fingerprinting document, maybe we should merge those.
... This group might take over that work.
... 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?
... We are getting some practice some privacy reviews - Frank Dawson has suggested some ideas on how to do privacy reviews (the process)

Christine: Frank, the implication is that you're leading the work on the process for this?

Frank: Yes, I will lead that work.

???: 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?

Nick: I don't think there is something specific, but we can pull them out of the document they were in.

Hannes: Name of thread?

Nick: I'll volunteer to pull out a link to that.

Christine: Can somebody else volunteer to start putting the list together.

<yrlesru> Sounds like a check-list approach to privacy review?

<yrlesru> Better than an "ad hoc" approach, I suppose...

No victims step forward.

Christine: Nick, get the link, please and we'll go from there.
... Any comments on this?

+1 (good idea)

<erin_k_> agree

<Joanne> +1

<JoeHallCDT> +1

Hannes: I'm a bit concerned about the content.

<yrlesru> +1 for Nick

Christine: I'm more concerned about process, not content right now.

<npdoty> as a side note, I might agree with Hannes about concerns on the content

Christine: AOB?
... Thanks for those that joined to talk about EME.

<npdoty> yes, much thanks manu, adrianba, markw, hsivonen

[ADJOURNED]

<hsivonen> (I guess ??P14 was me, in case it's needed for minutes)

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.

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Rogoss/Rogoff/
Succeeded: s/Zack/Zak/
Succeeded: s/???/Hannes/
Succeeded: s/ZZZ/Hannes/
Found ScribeNick: manu
Found ScribeNick: npdoty
Found ScribeNick: manu
Found ScribeNick: manu
Inferring Scribes: manu, npdoty
Scribes: manu, npdoty
ScribeNicks: manu, npdoty
Default Present: 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, npdoty, +1.214.566.aadd, +358.504.87aaee, +1.510.759.aaff, adrianba, rigo, wseltzer, [Microsoft], +1.202.489.aagg, yrlesru, JoeHallCDT, Christine?
Present: 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 npdoty +1.214.566.aadd +358.504.87aaee +1.510.759.aaff adrianba rigo wseltzer [Microsoft] +1.202.489.aagg yrlesru JoeHallCDT Christine? Joe_Hall CDT Frank_Dawson_Nokia Zak_Rogoff_FSF Hannes_Tschofenig

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 28 Feb 2013
Guessing minutes URL: http://www.w3.org/2013/02/28-privacy-minutes.html
People with action items: