This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Two open source DRM systems have been mentioned in the discussions on the HTML WG: OpenIPMP: http://sourceforge.net/projects/openipmp/ DReaM: https://github.com/papyromancer/DReaM/ I think it would be useful and instructive to analyse their approaches and compare them to the approach taken in EME - and potentially adapt any sensible features into EME. Such an analysis would not be part of the EME spec itself, but an informative note that will help the HTML WG to come to a decision on EME.
(In reply to comment #0) > OpenIPMP: > http://sourceforge.net/projects/openipmp/ FWIW, I think this one isn't particularly interesting to analyze. It says it's an implementation of OMA DRM and it explicitly warns about 3rd-party patent claims. If the exact values of certain private keys are withheld, it's not suprprising that you can publicly specify a Key System and show its source code if it depends on Tivoization for robustness. In general, being able to show source code excluding a private key or two is not much of a trick if the code runs on a Tivoized system. On the technical level, designing a Key System for streaming use cases is a back-of-a-napkin exercise. The things that are the true obstacles: * Patents starting with H.264 royalties if a design where elementary streams don't leave the CDM is a requirement. * Software-only CDMs on general-purpose computers depend on obfuscation of the object code and its run-time memory and tooling for Hollywood-grade obfuscation does not appear to be available as Open Source. * Inability to allow end users to build a compatible software-only CDM binary from source. (This breaks down to two things: having to hand over the private keys for true compatibility and robustness depending on the user not having built the CDM box themselves.)
It maybe that DRM is not possible where the context in which the CDM, and the output path, execute in a software stack controlled by the user, which includes open source software. If the CDM output path is controlled by the user then the output can be copied and stored. If this is the case then the primary goal of EME, which is strong content protection, is only applicable to proprietary operating systems which represent only a fraction of the population of web browsers. I believe this bug is actionable by including a discussion of this matter in the EME specification. This might be appropriate in qualifications of the use cases, and in the abstract. It also has implications for security and privacy given the absence of user control over a DRM-CDM, all of which also warrant mention in the EME specification.
Discussed on the telcon: http://www.w3.org/2013/02/26-html-media-minutes.html We think this is good data to feed into the discussion of CDM interop in bug 20944. If there is feedback that results from the analysis of these systems that results in changes to EME to ensure interoperability then this can be proposed in resolving that open issue.
(In reply to comment #3) > Discussed on the telcon: > http://www.w3.org/2013/02/26-html-media-minutes.html > > We think this is good data to feed into the discussion of CDM interop in bug > 20944. If there is feedback that results from the analysis of these systems > that results in changes to EME to ensure interoperability then this can be > proposed in resolving that open issue. Adrian: it doesn't help to ask me for input - I'm not the one who wants to introduce this feature and I am not an expert with DRM systems, nor do I understand DReaM sufficiently. My request was for someone that does understands these features to take a deeper look and make a summary statement about DReaM, how it's similar or different to EME and whether it might be useful as a open source DRM system that EME could make use of. I may be completely misunderstanding what DReaM does, so feel free to clarify that, too. I don't seem to be the only one asking for more due diligence, because there were at least two other WG members that asked about it. This bug indeed needs info, but not from me, but rather from the proponents of EME to help the larger group understand the problem space.
I was reporting the discussion from the Task Force meeting. In general, I think the task force believes that bug 20944 adequately captures the issue and this is called out in the draft as an open issue. If you or anyone else wants to perform this analysis to contribute to that discussion you are welcome to.
The Imperfect is the Enemy of the Good: Anticircumvention Versus Open User Innovation, Wendy Seltzer states on page 956: "Anticircumvention provides the hook by which to demand some DRM, and no matter how open the process by which the DRM standard was developed, devices implementing it will have to be closed." Corresponding footnote 198: "This is the flaw in the purportedly “open source” model behind Sun’s DReAM platform. Even if anyone can build an implementation of the specification, it would win “authorization” to play protected content only after proving its un-modifiability by others as a prerequisite to obtaining permission. Developers writing such code would be unable to comply with the downstream “freedom to modify” condition of the Free Software Foundation GPL. Cf. Gerard Fernando, Tom Jacobs & Vishy Swaminathan, PROJECT DREAM, AN ARCHITECTURAL OVERVIEW (2005), http://www.openmediacommons.org/collateral/DReaM-Overview.pdf." http://wendy.seltzer.is/writing/seltzer-anticircumvention.pdf
(In reply to comment #6) > http://wendy.seltzer.is/writing/seltzer-anticircumvention.pdf Thank you. I think there is now sufficient analysis of both OpenIPMP and DReaM to see that neither offers any new insight that would show how a CDM that satisfies the purpose of EME could be implemented in such a way that the end-user can build the CDM from the preferred form for making modifications. It's no surprise that DRM can be implemented in such a way that the preferred form for making modifications except some key material can be shown to the public if robustness relies either on Tivoization or on obfuscated compilation performed by someone trusted by content providers other than the end-users. I think we should proceed with the assumption that the purpose of EME cannot be satisfied with CDMs that end users are allowed to build from the preferred form for making modifications, and actual existence proof to the contrary would be needed to refute this assumption.