- From: Matt Ivie <matt.ivie@gmail.com>
- Date: Mon, 01 Jul 2013 21:30:59 -0600
- To: Mark Watson <watsonm@netflix.com>
- Cc: John Foliot <john@foliot.ca>, piranna@gmail.com, Andreas Kuckartz <A.Kuckartz@ping.de>, public-restrictedmedia@w3.org
On Mon, 2013-07-01 at 08:38 -0700, Mark Watson wrote: > > > On Fri, Jun 28, 2013 at 7:53 PM, Matt Ivie <matt.ivie@gmail.com> > wrote: > What else can EME do? > > > First, to be clear, our interest is in using EME for DRM. There's been > no secret about this: it has been very clear from the start. > > > However, as with any standardization task, we try to standardize > capabilities that are generic - as far as makes sense - rather than > over-specific to a particular use-case. Also, there is clearly a > desire in some quarters to see deployment of solutions other than DRM > and so we are trying to leave space for that within the design. > > > The technical answer is that EME is intended for any application where > it's required to play back encrypted audio/video media in a web > browser, specifically any such application where it is necessary to > deliver the key separately from the content itself and where the > decryption is intended to be done in the browser (or OS) rather than > by the page's Javascript. We chose a design where the key delivery > takes place via the page's Javascript rather than via side-channel > network communication. > > > DRM is one such application. Playback of encrypted content where the > key is known to the user or available to the Javascript (for example > as with Apple's HLS, which is widely used) is another. > > > I could make up further examples, without implying anything about > their usefulness, since I am just making them up: client-side > watermarking, "live" services with key rotation where the keys are > made available at specific times but don't need to be strictly > controlled once available, "light-weight" content protection where the > key is obscured from the Javascript page, but there's no robustness to > the browser decryption components. > > > I'll make one quick comment to agree that for some of these cases > there may be other solutions. We tried to design a single API which > could be used for a variety of applications and which could deal with > content-format-specific encryption (e.g. ISO Common Encryption). > > > ...Mark > > > John Foliot <john@foliot.ca> wrote: > > >>Matt Ivie wrote: > >>> > >>> Being Free Software and being covered by a patent are two > different > >>> things. By confusing the two matters you're making more > downstream > >>> confusion as a result. We should think of copyright issues > and > >>patent > >>> issues as they are: two separate issues. > >> > >>I can meet you there when you meet me at EME is not DRM :-) > >> > >>(Both are examples of separate issues that have significant > linkages, > >>and related downstream confusion...) > >> > >>Besides, we're talking about "Open" standards here, and > bringing forth > >>x264 without acknowledging the fact that the software still > uses > >>technology that is not "open" is, I believe relevant, if for > no other > >>reason than an illustration of how "Open" software can still > use > >>non-open standards/technologies (unless you are going to > tell me that > >>you can freely modify the H.264 codec at will, with no > repercussions). > >> > >>JF > > > -- > Sent from my Replicant phone with K-9 Mail. Please excuse my > brevity. Visit replicant.us > I appreciate the response to the question and I appreciate the explanation of the thought behind adding functionality to EME. None of those other functions seem like they're going to add up to much though; Not enough to justify standardizing Digital Restrictions Management in W3C standards. Can you think of any other standard in the W3C that CAN'T be completely implemented using free software by anyone that wants to implement it? -- /* Free software is a matter of liberty, not price. Visit GNU.org * FSF.org * Trisquel.info */
Received on Tuesday, 2 July 2013 03:31:29 UTC