- From: Norbert Bollow <nb@bollow.ch>
- Date: Mon, 17 Jun 2013 13:29:04 +0200
- To: Henri Sivonen <hsivonen@hsivonen.fi>
- Cc: Jeff Jaffe <jeff@w3.org>, public-restrictedmedia@w3.org, timbl@w3.org
Henri Sivonen <hsivonen@hsivonen.fi> wrote: > My reading of the above is that #1, #2 and #4 involve some sort of DRM > (with the DRM part either inside or outside of a W3C spec) and, > therefore, don't illustrate a difference between "content protection" > and "DRM" except to the extent #2 distinguishes "breakable DRM" from > robust DRM. In this whole discussion, all kinds of DRM systems that have been mentioned have the property that the potential adversary has access to the encrypted content data and to computer code capable of decrypting it, when that computer code is executed in a certain context. Hence, if the adversary has sufficient interest and the ability to spend a sufficient number of skilled person-hours on the project, the protection measures can be reverse engineered and circumvented, no doubt about that. The distinction is just how easy it is to do that. If the source code is available, circumvention is of course much easier and quicker than in the case of an obfuscated binary executable where lots of checks that the code is executed in the expected kind of environment are intermixed with the actual decryption computation. So I would propose to refer to those two types of DRM systems as “easily circumventable DRM” and “obfuscated DRM”, respectively. > Password-based access control to all types of Web > resources has already been developed, so it would be weird for > "content protection" as a new chartered item to mean #3. > > It seems to me that "content protection" is just a synonym for "DRM". I agree - especially as long as EME is *the* spec for enabling "content protection" that is pushed forward in W3C, and it is clear that those who want this want some kind of DRM (even if there open to alternative architectural suggestions besides EME), that is the reasonable interpretation. Even if there is a theoretical possibility that at some point in the future, a non-DRM-oriented spec might be developed under the banner of (differently interpreted) "content protection". Greetings, Norbert FreedomHTML.org
Received on Monday, 17 June 2013 11:29:33 UTC