Jobs on “Open DRM”

by on February 6, 2007 · 36 comments

You should really read Jobs’ essay in its entirety, but here’s one other passage from it that’s worth highlighting (this one immediately precedes the one I quote below):

The second alternative is for Apple to license its FairPlay DRM technology to current and future competitors with the goal of achieving interoperability between different company’s players and music stores. On the surface, this seems like a good idea since it might offer customers increased choice now and in the future. And Apple might benefit by charging a small licensing fee for its FairPlay DRM. However, when we look a bit deeper, problems begin to emerge. The most serious problem is that licensing a DRM involves disclosing some of its secrets to many people in many companies, and history tells us that inevitably these secrets will leak. The Internet has made such leaks far more damaging, since a single leak can be spread worldwide in less than a minute. Such leaks can rapidly result in software programs available as free downloads on the Internet which will disable the DRM protection so that formerly protected songs can be played on unauthorized players.

An equally serious problem is how to quickly repair the damage caused by such a leak. A successful repair will likely involve enhancing the music store software, the music jukebox software, and the software in the players with new secrets, then transferring this updated software into the tens (or hundreds) of millions of Macs, Windows PCs and players already in use. This must all be done quickly and in a very coordinated way. Such an undertaking is very difficult when just one company controls all of the pieces. It is near impossible if multiple companies control separate pieces of the puzzle, and all of them must quickly act in concert to repair the damage from a leak.

Apple has concluded that if it licenses FairPlay to others, it can no longer guarantee to protect the music it licenses from the big four music companies. Perhaps this same conclusion contributed to Microsoft’s recent decision to switch their emphasis from an “open” model of licensing their DRM to others to a “closed” model of offering a proprietary music store, proprietary jukebox software and proprietary players.

This echoes a point I’ve made before: there is no such thing as an open DRM standard. By definition, an open standard is available for anyone to look at. And by its nature, DRM requires that at least some details of a DRM standard be secret, which means that it cannot be open. “Open DRM” is simply a contradiction in terms.

  • http://bennett.com/blog Richard Bennett

    “Open DRM” is simply a contradiction in terms.

    Not, it isn’t. There are DRM schemes where the content and operation of the protocols is completely open, but any given piece of content is still protected by a serial number and a set of keys. If media companies are willing to do the kind of thing Microsoft does with Windows and Office, where you have to unlock by entering a key, they can have DRM and an open protocol.

  • http://bennett.com/blog Richard Bennett

    “Open DRM” is simply a contradiction in terms.

    Not, it isn’t. There are DRM schemes where the content and operation of the protocols is completely open, but any given piece of content is still protected by a serial number and a set of keys. If media companies are willing to do the kind of thing Microsoft does with Windows and Office, where you have to unlock by entering a key, they can have DRM and an open protocol.

  • http://weblog.ipcentral.info/ Noel Le

    Interesting that Jobs uses an example from MSFT to explain why licensing DRM doesn’t work.

    I wonder if Apple and Microsoft are on good terms. I was reading this book on the history of the software industry, which explained that in the early days Bill Gates had a “red phone” in his office in Redmond that was dedicated to Steve Jobs. Whenever Jobs called and wanted to talk to Gates, Gates would fly to California.

    Interestingly, Gates wrote a letter to the author of the book. Gates stated something along the lines of: “I think I’m treated unfairly on pages XX and YY, you say that Jeff Raikes has all-American good looks, does that mean he doesn’t look like me.”

  • http://weblog.ipcentral.info/ Noel Le

    Interesting that Jobs uses an example from MSFT to explain why licensing DRM doesn’t work.

    I wonder if Apple and Microsoft are on good terms. I was reading this book on the history of the software industry, which explained that in the early days Bill Gates had a “red phone” in his office in Redmond that was dedicated to Steve Jobs. Whenever Jobs called and wanted to talk to Gates, Gates would fly to California.

    Interestingly, Gates wrote a letter to the author of the book. Gates stated something along the lines of: “I think I’m treated unfairly on pages XX and YY, you say that Jeff Raikes has all-American good looks, does that mean he doesn’t look like me.”

  • http://www.techliberation.com/ Tim Lee

    Richard, you’re confusing DRM with vanilla encryption. I discuss why it’s different here:

    With ordinary cryptography, you’ve got a sender, Alice; a recipient, Bob; and an eavesdropper, Connie. Alice encrypts her message with an encryption key, and transmits the encrypted message to Bob. Bob has a secret decryption key that he uses to decrypt the message. If the encryption algorithm is secure, Connie won’t be able to decode the message, even if she is able to record the entire conversation between Alice and Bob, and even if she knows everything about the algorithm they used to encrypt and decrypt the messages. Open cryptography works well because the more people who’ve looked at it, the lower the likelihood that someone will find a flaw. With an algorithm that’s been around for decades, such as RSA or DES, you can be reasonably confident that, barring a major mathematical breakthrough, Connie won’t be able to read Alice’s message without Bob’s key. The challenge of DRM is that Bob and Connie are the same person. Or rather, “Bob” is software running on Connie’s computer–for example, a copy of iTunes. We want to transmit content in a way that “Bob” (let’s say “Bob” is iTunes software) can access it, but Connie can’t decrypt it for unapproved uses. If Connie has the ability to examine or modify the software, that’s logically impossible. Because if the Connie’s software has the key, she can modify it to share the key with her. Or she can study what the software does and write her own software to perform the same series of steps. On a general-purpose computer it simply doesn’t make sense to treat a user and his or her software as separate entities, since the user can always modify the software to do what she wants it to.

  • http://www.techliberation.com/ Tim Lee

    Richard, you’re confusing DRM with vanilla encryption. I discuss why it’s different here:

    With ordinary cryptography, you’ve got a sender, Alice; a recipient, Bob; and an eavesdropper, Connie. Alice encrypts her message with an encryption key, and transmits the encrypted message to Bob. Bob has a secret decryption key that he uses to decrypt the message. If the encryption algorithm is secure, Connie won’t be able to decode the message, even if she is able to record the entire conversation between Alice and Bob, and even if she knows everything about the algorithm they used to encrypt and decrypt the messages. Open cryptography works well because the more people who’ve looked at it, the lower the likelihood that someone will find a flaw. With an algorithm that’s been around for decades, such as RSA or DES, you can be reasonably confident that, barring a major mathematical breakthrough, Connie won’t be able to read Alice’s message without Bob’s key. The challenge of DRM is that Bob and Connie are the same person. Or rather, “Bob” is software running on Connie’s computer–for example, a copy of iTunes. We want to transmit content in a way that “Bob” (let’s say “Bob” is iTunes software) can access it, but Connie can’t decrypt it for unapproved uses. If Connie has the ability to examine or modify the software, that’s logically impossible. Because if the Connie’s software has the key, she can modify it to share the key with her. Or she can study what the software does and write her own software to perform the same series of steps. On a general-purpose computer it simply doesn’t make sense to treat a user and his or her software as separate entities, since the user can always modify the software to do what she wants it to.

  • http://weblog.ipcentral.info/ Noel Le

    Tim, Richard has a point.

    I don’t see how encryption does not constitute a kind of DRM.

  • http://weblog.ipcentral.info/ Noel Le

    Tim, Richard has a point.

    I don’t see how encryption does not constitute a kind of DRM.

  • http://bennett.com/blog Richard Bennett

    Tim, did you study math or software engineering in school, or do you just play a technical dude on the web?

    You’re peddling a civilian’s understanding of DRM and encryption – software by analogy – to an audience that includes some real engineers. So when you say “Open DRM is contradiction in terms” we know you’re really saying “I don’t understand how Open DRM could possibly work.”

    I can see that you don’t understand this, but take my word for it that “security through obscurity” isn’t the only – or even the best – way for DRM to be accomplished.

    All that DRM requires in the final analysis is means of tying a licensed work to a license holder. Once you’ve established the identity of the license holder, you can embed crypto in the work that can only be unlocked by the license holder. There are several ways of doing this, and it’s pretty straightforward in any system in which a single copy is downloaded to a known user to mangle the work appropriately. A simple system of public and private keys will do the trick.

    Dissing the security professionals at Sun and elsewhere who have solved this problem doesn’t alter the fact that it’s doable.

    Now it is certainly the case that the critical dimension of DRM is the ability to unlock the work for playback but not for copying, hence it’s necessary to view the license holder as a piece of software rather than an individual. And hence it’s necessary to authenticate the relevant piece of software and reject software written by third parties that tries to impersonate it. I don’t know how this is done in commercial systems, but I can imagine several ways of doing it that would survive open source scrutiny, some of them almost trivial.

    Your argument against DRM begins to sound like some of the arguments against network prioritization: “it will never work.” If that were really the case, you’d have nothing to worry about but a little temporary inconvenience, would you?

  • http://bennett.com/blog Richard Bennett

    Tim, did you study math or software engineering in school, or do you just play a technical dude on the web?

    You’re peddling a civilian’s understanding of DRM and encryption – software by analogy – to an audience that includes some real engineers. So when you say “Open DRM is contradiction in terms” we know you’re really saying “I don’t understand how Open DRM could possibly work.”

    I can see that you don’t understand this, but take my word for it that “security through obscurity” isn’t the only – or even the best – way for DRM to be accomplished.

    All that DRM requires in the final analysis is means of tying a licensed work to a license holder. Once you’ve established the identity of the license holder, you can embed crypto in the work that can only be unlocked by the license holder. There are several ways of doing this, and it’s pretty straightforward in any system in which a single copy is downloaded to a known user to mangle the work appropriately. A simple system of public and private keys will do the trick.

    Dissing the security professionals at Sun and elsewhere who have solved this problem doesn’t alter the fact that it’s doable.

    Now it is certainly the case that the critical dimension of DRM is the ability to unlock the work for playback but not for copying, hence it’s necessary to view the license holder as a piece of software rather than an individual. And hence it’s necessary to authenticate the relevant piece of software and reject software written by third parties that tries to impersonate it. I don’t know how this is done in commercial systems, but I can imagine several ways of doing it that would survive open source scrutiny, some of them almost trivial.

    Your argument against DRM begins to sound like some of the arguments against network prioritization: “it will never work.” If that were really the case, you’d have nothing to worry about but a little temporary inconvenience, would you?

  • http://www.techliberation.com/ Tim Lee

    Now it is certainly the case that the critical dimension of DRM is the ability to unlock the work for playback but not for copying, hence it’s necessary to view the license holder as a piece of software rather than an individual. And hence it’s necessary to authenticate the relevant piece of software and reject software written by third parties that tries to impersonate it. I don’t know how this is done in commercial systems, but I can imagine several ways of doing it that would survive open source scrutiny, some of them almost trivial.

    There are at least two problems with this. First, on a general-purpose computer, no matter what authentication mechanism you use, it will always be possible to write software that emulates the authentication portions of an authorized copy of the software but then does unauthorized things with the results.

    Secondly, you can just let the authorized version of the software run, but then use a debugger or other low-level tool to extract the relevant keys after they’ve been handed over to the legitimate software. The key has to be stored in plain text somewhere in the computer, so the best the software can do is obfuscate its location somehow. That means that retrieving the key is always possible, it’s just a question of how long it takes to reverse-engineer the software in order to find it. This means that “security through obscurity” lies at the heart of the software’s “security” model.

    Now, the “general purpose” caveat is important. It’s conceivable that this sort of thing could be made to work with a “trusted computing” platform where the authentication key is stored in hardware, and the operating system prohibits any unauthorized software from running on the system. But this is hardly “trivial,” and such a system is likely to have a variety of problems of its own.

    Even if you can overcome those objections, you’re practically conceding my point when you say that it’s “necessary to authenticate the relevant piece of software.” This means that you need to have a centralized authority that examines each instance of the software and verifies that it complies with the rules of the DRM scheme. But that means you’re stretching the definition of “open,” because while you might be allowed to write software that complies with the spec, it won’t actually work until it’s been submitted to the relevant DRM bureaucracy for verification that it follows the rules. And if experience is any guide, DRM bureaucracies tend to charge thousands of dollars for their testing services, and they tend to make very specific demands regarding how the software is allowed to work. Although this might be “open” in some pedantic sense, it’s certainly not open in the sense that HTML or PDF are open standards–free for anyone to implement without asking anyone’s permission.

  • http://www.techliberation.com/ Tim Lee

    Now it is certainly the case that the critical dimension of DRM is the ability to unlock the work for playback but not for copying, hence it’s necessary to view the license holder as a piece of software rather than an individual. And hence it’s necessary to authenticate the relevant piece of software and reject software written by third parties that tries to impersonate it. I don’t know how this is done in commercial systems, but I can imagine several ways of doing it that would survive open source scrutiny, some of them almost trivial.

    There are at least two problems with this. First, on a general-purpose computer, no matter what authentication mechanism you use, it will always be possible to write software that emulates the authentication portions of an authorized copy of the software but then does unauthorized things with the results.

    Secondly, you can just let the authorized version of the software run, but then use a debugger or other low-level tool to extract the relevant keys after they’ve been handed over to the legitimate software. The key has to be stored in plain text somewhere in the computer, so the best the software can do is obfuscate its location somehow. That means that retrieving the key is always possible, it’s just a question of how long it takes to reverse-engineer the software in order to find it. This means that “security through obscurity” lies at the heart of the software’s “security” model.

    Now, the “general purpose” caveat is important. It’s conceivable that this sort of thing could be made to work with a “trusted computing” platform where the authentication key is stored in hardware, and the operating system prohibits any unauthorized software from running on the system. But this is hardly “trivial,” and such a system is likely to have a variety of problems of its own.

    Even if you can overcome those objections, you’re practically conceding my point when you say that it’s “necessary to authenticate the relevant piece of software.” This means that you need to have a centralized authority that examines each instance of the software and verifies that it complies with the rules of the DRM scheme. But that means you’re stretching the definition of “open,” because while you might be allowed to write software that complies with the spec, it won’t actually work until it’s been submitted to the relevant DRM bureaucracy for verification that it follows the rules. And if experience is any guide, DRM bureaucracies tend to charge thousands of dollars for their testing services, and they tend to make very specific demands regarding how the software is allowed to work. Although this might be “open” in some pedantic sense, it’s certainly not open in the sense that HTML or PDF are open standards–free for anyone to implement without asking anyone’s permission.

  • Terry Steichen

    Steve Jobs faces several very serious problems:

    (1) DRM maintenance is very high and becoming even higher, the cost of which Apple bears (curbing iTunes profits);

    (2) DRM vulnerabilities puts the entire iTunes inventory at constant risk, a major Apple business risk; and,

    (3) Europe may block use of DRM, which could be catastrophic for Apple (iPods, Macs and iTunes).

    I suspect he realizes that Apple has milked about all the business benefits can from DRM, with its commanding market share fairly well-established. For the reasons mentioned above, future Apple business prospects are negative, potentially seriously so. So, there’s nothing principled about Job’s new positioning: jettisoning DRM makes total business sense for Apple.

    Some (including commentors, above) argue for an open standards, open source approach to IP rights management. But in Jobs’ manifesto, he argues that “[n]o one has ever implemented a DRM system that does not depend on ..secrets for its operation.” Further, he argues, “[t]here is no theory of protection content other than keeping secrets.” Finally, he states that “even if one uses the most sophisticated cryptographic locks to protect the actual music,one must still ‘hide’ the keys which unlock the music on the user’s computer or portable music player.

    Job’s arguments (which I, and I think Tim, agree with) on the necessity of keeping secret part of your encrypting mechanism seems contrary to any “open standards, open source approach”. Economic, secure, mass-market-oriented key distribution is an oxymoron (or, at the very least, an unrealistic dream).

    What bugs me about DRM is that it imposes more restrictions on consumer use (compared to conventional non-DRM-protected material), yet demands the same copyright protection. When copyright was established (in our Constitution), there was an implied quid-pro-quo that balanced protections to creators with usage options for consumers. DRM disrupts that balance. Either it should go away, or DRM-protected content should not be given full legal copyright protection.

  • Terry Steichen

    Steve Jobs faces several very serious problems:

    (1) DRM maintenance is very high and becoming even higher, the cost of which Apple bears (curbing iTunes profits);

    (2) DRM vulnerabilities puts the entire iTunes inventory at constant risk, a major Apple business risk; and,

    (3) Europe may block use of DRM, which could be catastrophic for Apple (iPods, Macs and iTunes).

    I suspect he realizes that Apple has milked about all the business benefits can from DRM, with its commanding market share fairly well-established. For the reasons mentioned above, future Apple business prospects are negative, potentially seriously so. So, there’s nothing principled about Job’s new positioning: jettisoning DRM makes total business sense for Apple.

    Some (including commentors, above) argue for an open standards, open source approach to IP rights management. But in Jobs’ manifesto, he argues that “[n]o one has ever implemented a DRM system that does not depend on ..secrets for its operation.” Further, he argues, “[t]here is no theory of protection content other than keeping secrets.” Finally, he states that “even if one uses the most sophisticated cryptographic locks to protect the actual music,one must still ‘hide’ the keys which unlock the music on the user’s computer or portable music player.

    Job’s arguments (which I, and I think Tim, agree with) on the necessity of keeping secret part of your encrypting mechanism seems contrary to any “open standards, open source approach”. Economic, secure, mass-market-oriented key distribution is an oxymoron (or, at the very least, an unrealistic dream).

    What bugs me about DRM is that it imposes more restrictions on consumer use (compared to conventional non-DRM-protected material), yet demands the same copyright protection. When copyright was established (in our Constitution), there was an implied quid-pro-quo that balanced protections to creators with usage options for consumers. DRM disrupts that balance. Either it should go away, or DRM-protected content should not be given full legal copyright protection.

  • http://bennett.com/blog Richard Bennett

    The key has to be stored in plain text somewhere in the computer, so the best the software can do is obfuscate its location somehow.

    Not necessarily, and most of our modern-day encryption schemes use pairs of keys in any event. Open DRM systems apparently pass keys from a rights enforcement entity to a codec, and codecs are typically implemented in hardware, at least in video systems. Readers have pointed this out in response to your previous posts on open DRM.

    So don’t worry too much about whether Open DRM or any other kind of DRM can be done – it can be, your issue is simply whether it should be.

  • http://bennett.com/blog Richard Bennett

    The key has to be stored in plain text somewhere in the computer, so the best the software can do is obfuscate its location somehow.

    Not necessarily, and most of our modern-day encryption schemes use pairs of keys in any event. Open DRM systems apparently pass keys from a rights enforcement entity to a codec, and codecs are typically implemented in hardware, at least in video systems. Readers have pointed this out in response to your previous posts on open DRM.

    So don’t worry too much about whether Open DRM or any other kind of DRM can be done – it can be, your issue is simply whether it should be.

  • http://www.techliberation.com/ Tim Lee

    Richard,

    Not necessarily, and most of our modern-day encryption schemes use pairs of keys in any event. Open DRM systems apparently pass keys from a rights enforcement entity to a codec, and codecs are typically implemented in hardware, at least in video systems.

    If you’ll recall, I specifically said I was talking about general purpose computers. I believe you that if you build a format that doesn’t support playback on a general purpose computer, that that can be done in a way that’s more difficult to crack. But all the DRM schemes we’ve been discussing here support playback on general purpose computers. As far as I know, for example, most PCs don’t have a specialized FairPlay decryption chip. So how is that relevant to the example we were discussing in the first place?

    Even if you do have special-purpose hardware to do the decryption, you’ve still got a problem if that hardware passes the unscrambled content to the CPU (or other open hardware) for playback. Therefore, in order to make this “open” standard work, you would also have to require that it only play back on approved video or sound cards. I suppose those too would be built on “open” standards.

    “Open DRM” is only possible if you twist the meaning of “open” beyond recognition. In the real world, “open” means that anyone is free to implement the standard without anyone else’s permission. A system that only works on custom hardware, and that only allows you to build hardware after a DRM bureaucracy has approved the design, is a peculiar kind of “open.”

  • http://www.techliberation.com/ Tim Lee

    Richard,

    Not necessarily, and most of our modern-day encryption schemes use pairs of keys in any event. Open DRM systems apparently pass keys from a rights enforcement entity to a codec, and codecs are typically implemented in hardware, at least in video systems.

    If you’ll recall, I specifically said I was talking about general purpose computers. I believe you that if you build a format that doesn’t support playback on a general purpose computer, that that can be done in a way that’s more difficult to crack. But all the DRM schemes we’ve been discussing here support playback on general purpose computers. As far as I know, for example, most PCs don’t have a specialized FairPlay decryption chip. So how is that relevant to the example we were discussing in the first place?

    Even if you do have special-purpose hardware to do the decryption, you’ve still got a problem if that hardware passes the unscrambled content to the CPU (or other open hardware) for playback. Therefore, in order to make this “open” standard work, you would also have to require that it only play back on approved video or sound cards. I suppose those too would be built on “open” standards.

    “Open DRM” is only possible if you twist the meaning of “open” beyond recognition. In the real world, “open” means that anyone is free to implement the standard without anyone else’s permission. A system that only works on custom hardware, and that only allows you to build hardware after a DRM bureaucracy has approved the design, is a peculiar kind of “open.”

  • http://bennett.com/blog Richard Bennett

    Actually, you made a sweeping claim about Open DRM that wasn’t qualified by any language about “special purpose” or “general purpose” computers. Read the last two sentences of your post.

    I already mentioned codecs. That’s the part of the audio or video controller that renders sound and/or images. Hence when you say: “you would also have to require that it only play back on approved video or sound cards” you’re saying what I already said. I guess the term “codec” didn’t ring a bell for you. There are degrees of openness just as there are degrees of general-purposeness. If the movie studios wish to keep their material off general-purpose computers, it’s up to the market to punish them. Unless they’re right after all and it really is sound business, in which case the market will reward them for being so smart.

    But again, if your complaint is with DRM in the abstract, that’s fine, go ahead and vent. I’d suggest you don’t spend too much time criticizing any particular scheme, however, as you end up skating on ice so thin that any breeze can send you for a cold bath.

  • http://bennett.com/blog Richard Bennett

    Actually, you made a sweeping claim about Open DRM that wasn’t qualified by any language about “special purpose” or “general purpose” computers. Read the last two sentences of your post.

    I already mentioned codecs. That’s the part of the audio or video controller that renders sound and/or images. Hence when you say: “you would also have to require that it only play back on approved video or sound cards” you’re saying what I already said. I guess the term “codec” didn’t ring a bell for you. There are degrees of openness just as there are degrees of general-purposeness. If the movie studios wish to keep their material off general-purpose computers, it’s up to the market to punish them. Unless they’re right after all and it really is sound business, in which case the market will reward them for being so smart.

    But again, if your complaint is with DRM in the abstract, that’s fine, go ahead and vent. I’d suggest you don’t spend too much time criticizing any particular scheme, however, as you end up skating on ice so thin that any breeze can send you for a cold bath.

  • http://bennett.com/blog Richard Bennett

    For example, you’ve used the phrase “security through obscurity” here. Software engineers use this phrase to mean systems where the source code isn’t published, like the Diebold voting machine, and contrast it with systems where the source code is published and the thousand eyes can look for flaws in their free time and plug them. It doesn’t really describe DRM systems well. While there are parts of these systems that have to be obscured, they tend to be small bits like keys, not the entire system of code that carries them around in encrypted form. Hiding keys from prying eyes by putting then in write-only memories and special purpose hardware registers isn’t the same thing, although there is an element of obscurity in it.

  • http://bennett.com/blog Richard Bennett

    For example, you’ve used the phrase “security through obscurity” here. Software engineers use this phrase to mean systems where the source code isn’t published, like the Diebold voting machine, and contrast it with systems where the source code is published and the thousand eyes can look for flaws in their free time and plug them. It doesn’t really describe DRM systems well. While there are parts of these systems that have to be obscured, they tend to be small bits like keys, not the entire system of code that carries them around in encrypted form. Hiding keys from prying eyes by putting then in write-only memories and special purpose hardware registers isn’t the same thing, although there is an element of obscurity in it.

  • Terry Steichen

    I think commentors that brag about their engineering expertise are so full of their “expertise” that they can’t (or, perhaps won’t) get in touch with plain, simple, logical common sense. Steve Jobs, whose company is perhaps the most active practitioner of DRM has stated flatly (for his own purposes, of course) that DRM depends on keeping key parts of the process secret. That’s completely opposite of what “open source” means to just about anyone in the world (apparently other than some of your commentors).

    DRM is very, very logical – which is probably why rigid engineering types cannot see past this point – they get trapped in it. But DRM is also very, very impractical. It hurts business (though the effects may take a while to manifest) and that’s a very hard hurtle to overcome.

    The comment about Tim never mentioning “special purpose” or “general purpose” is truly off-base (to put it as mildly as I can). The whole discussion is about DRM for the masses, not for some tiny hypothetical niche with special-purpose computers. Making general, obvious comments about this topic (like Tim has) isn’t ‘venting’ and certainly isn’t skating on thin ice.

  • Terry Steichen

    I think commentors that brag about their engineering expertise are so full of their “expertise” that they can’t (or, perhaps won’t) get in touch with plain, simple, logical common sense. Steve Jobs, whose company is perhaps the most active practitioner of DRM has stated flatly (for his own purposes, of course) that DRM depends on keeping key parts of the process secret. That’s completely opposite of what “open source” means to just about anyone in the world (apparently other than some of your commentors).

    DRM is very, very logical – which is probably why rigid engineering types cannot see past this point – they get trapped in it. But DRM is also very, very impractical. It hurts business (though the effects may take a while to manifest) and that’s a very hard hurtle to overcome.

    The comment about Tim never mentioning “special purpose” or “general purpose” is truly off-base (to put it as mildly as I can). The whole discussion is about DRM for the masses, not for some tiny hypothetical niche with special-purpose computers. Making general, obvious comments about this topic (like Tim has) isn’t ‘venting’ and certainly isn’t skating on thin ice.

  • http://bennett.com/blog Richard Bennett

    Yes, let’s all take care of the Great Unwashed, the hapless souls oppressed by the great monopolistic Telco-entertainment Complex. And let’s be so passionate in our defense of their liberties that we don’t worry about doing violence to the facts, to the English Language, or to the fundamental principles of mathematics. And most of all, let’s develop the most flimsy arguments we possibly can in the defense of their freedoms.

    Is that about it, Terry?

    I’m not arguing that DRM is good or bad, I’m pointing out that when discussing it it’s best to remain accurate and to refrain from making broad, sweeping claims that we can’t support. Because DRM, and every system in which cryptography plays a part, depends in part on secrecy, that doesn’t really mean that all good Open Source-loving freedom fighters are required to cast derision on every pronouncement regarding its implementation. If Sun finds it worthwhile to develop something they call Open DRM and that approach has some merit, let’s evaluate it according to the proper standard, not according to some pseudo-standard that says all DRM is screwed up by its very nature.

    Open DRM is more open than other DRN systems, and less open than gcc.

    So what?

  • http://bennett.com/blog Richard Bennett

    Yes, let’s all take care of the Great Unwashed, the hapless souls oppressed by the great monopolistic Telco-entertainment Complex. And let’s be so passionate in our defense of their liberties that we don’t worry about doing violence to the facts, to the English Language, or to the fundamental principles of mathematics. And most of all, let’s develop the most flimsy arguments we possibly can in the defense of their freedoms.

    Is that about it, Terry?

    I’m not arguing that DRM is good or bad, I’m pointing out that when discussing it it’s best to remain accurate and to refrain from making broad, sweeping claims that we can’t support. Because DRM, and every system in which cryptography plays a part, depends in part on secrecy, that doesn’t really mean that all good Open Source-loving freedom fighters are required to cast derision on every pronouncement regarding its implementation. If Sun finds it worthwhile to develop something they call Open DRM and that approach has some merit, let’s evaluate it according to the proper standard, not according to some pseudo-standard that says all DRM is screwed up by its very nature.

    Open DRM is more open than other DRN systems, and less open than gcc.

    So what?

  • Terry Steichen

    “Open DRM is … less open than gcc.”

    That is PRECISELY my point (or, at least one of them). Thank you for putting it so succinctly.

  • Terry Steichen

    “Open DRM is … less open than gcc.”

    That is PRECISELY my point (or, at least one of them). Thank you for putting it so succinctly.

  • http://bennett.com/blog Richard Bennett

    Well yeah, but like I said, “so what?” Open Source isn’t the one and only source of true virtue, is it?

  • http://bennett.com/blog Richard Bennett

    Well yeah, but like I said, “so what?” Open Source isn’t the one and only source of true virtue, is it?

  • http://www.techliberation.com/ Tim Lee

    Actually, you made a sweeping claim about Open DRM that wasn’t qualified by any language about “special purpose” or “general purpose” computers. Read the last two sentences of your post.

    Well, I think the term “open,” as used in this context, implies that it can be implemented on a general-purpose computer. You seem to concede in the subsequent discussion with Terry that I’m right–DRM schemes are less open than things like TCP/IP and HTML that we normally would call “open”–they’re not available for anyone to implement without asking anybody’s permission. Maybe some DRM schemes are more “open” than others, but no DRM scheme is completely open, and that’s what I meant in my post.

    I already mentioned codecs. That’s the part of the audio or video controller that renders sound and/or images. Hence when you say: “you would also have to require that it only play back on approved video or sound cards” you’re saying what I already said. I guess the term “codec” didn’t ring a bell for you. There are degrees of openness just as there are degrees of general-purposeness. If the movie studios wish to keep their material off general-purpose computers, it’s up to the market to punish them. Unless they’re right after all and it really is sound business, in which case the market will reward them for being so smart.

    You’re implying here that the entire DRM scheme would be embedded in the sound card? The CPU would simply hand the encrypted content (and any keys provided by the server) to the sound card, and the sound card would be responsible for verifying that the holder of the key is an authorized user and then playing the sound if the user is authorized.

    I don’t understand how you could possibly describe such a DRM scheme as “open.” Certainly, no one who’s not a sound card manufacturer could implement it. If by “open” you just mean that anyone’s free to license the technology from the company that created it, that’s only “open” in a trivial sense.

    If you’re just interested in quibbling over the definition of “open,” well fine: my sense of “open” is more restrictive than yours apparently is, and I apologize if my initial statement was unclear. I mean “open” in the sense that HTML, TCP/IP, or PGP are open: all the implementation details are public, and anyone is free to implement them. If you use the word “open” in some other, less restrictive sense, then “open” DRM schemes are certainly possible, but then we’re just quibbling over semantics.

  • http://www.techliberation.com/ Tim Lee

    Actually, you made a sweeping claim about Open DRM that wasn’t qualified by any language about “special purpose” or “general purpose” computers. Read the last two sentences of your post.

    Well, I think the term “open,” as used in this context, implies that it can be implemented on a general-purpose computer. You seem to concede in the subsequent discussion with Terry that I’m right–DRM schemes are less open than things like TCP/IP and HTML that we normally would call “open”–they’re not available for anyone to implement without asking anybody’s permission. Maybe some DRM schemes are more “open” than others, but no DRM scheme is completely open, and that’s what I meant in my post.

    I already mentioned codecs. That’s the part of the audio or video controller that renders sound and/or images. Hence when you say: “you would also have to require that it only play back on approved video or sound cards” you’re saying what I already said. I guess the term “codec” didn’t ring a bell for you. There are degrees of openness just as there are degrees of general-purposeness. If the movie studios wish to keep their material off general-purpose computers, it’s up to the market to punish them. Unless they’re right after all and it really is sound business, in which case the market will reward them for being so smart.

    You’re implying here that the entire DRM scheme would be embedded in the sound card? The CPU would simply hand the encrypted content (and any keys provided by the server) to the sound card, and the sound card would be responsible for verifying that the holder of the key is an authorized user and then playing the sound if the user is authorized.

    I don’t understand how you could possibly describe such a DRM scheme as “open.” Certainly, no one who’s not a sound card manufacturer could implement it. If by “open” you just mean that anyone’s free to license the technology from the company that created it, that’s only “open” in a trivial sense.

    If you’re just interested in quibbling over the definition of “open,” well fine: my sense of “open” is more restrictive than yours apparently is, and I apologize if my initial statement was unclear. I mean “open” in the sense that HTML, TCP/IP, or PGP are open: all the implementation details are public, and anyone is free to implement them. If you use the word “open” in some other, less restrictive sense, then “open” DRM schemes are certainly possible, but then we’re just quibbling over semantics.

  • Terry Steichen

    I think we all seem to agree that a DRM system can’t work if it’s truly ‘open’. Part of it must be kept secret for it to work. I hope we can also agree (with Steve Jobs, among others) that keeping such secrets secret is costly and will inevitably fail, at which point new secrets must somehow be introduced into the system.

    What Jobs is saying (and I fully realize he has a strong vested interest here) is that the cost of maintaining DRM in terms of fixing disclosures (replacing the disclosed secrets with new ones), customer service headaches, adverse market reactions, and legal implications (ala EU), is simply too high. It’s not sustainable. (As I mentioned, I happen to feel DRM is incompatible with the underlying copyright concept, but that’s not the point here.) Jobs also points out that it’s illogical to carry these large burdens on some music, given that the bulk of music is sold without DRM protection (through the costly CD package).

    I don’t see what there is left to argue about.

  • Terry Steichen

    I think we all seem to agree that a DRM system can’t work if it’s truly ‘open’. Part of it must be kept secret for it to work. I hope we can also agree (with Steve Jobs, among others) that keeping such secrets secret is costly and will inevitably fail, at which point new secrets must somehow be introduced into the system.

    What Jobs is saying (and I fully realize he has a strong vested interest here) is that the cost of maintaining DRM in terms of fixing disclosures (replacing the disclosed secrets with new ones), customer service headaches, adverse market reactions, and legal implications (ala EU), is simply too high. It’s not sustainable. (As I mentioned, I happen to feel DRM is incompatible with the underlying copyright concept, but that’s not the point here.) Jobs also points out that it’s illogical to carry these large burdens on some music, given that the bulk of music is sold without DRM protection (through the costly CD package).

    I don’t see what there is left to argue about.

  • http://bennett.com/blog Richard Bennett

    If Jobs were really serious about abandoning DRM, wouldn’t he offer free downloads from iTunes? I mean, if it’s wrong for the evil capitalistic record companies to profit from The People’s Music, surely it’s wrong for Apple to sell it.

    Besides, Apple doesn’t need the revenue from iTunes, Jobs could just go around and give live performances. The faithful would surely pay good money to see him perform, and that would be the end of world hunger.

  • http://bennett.com/blog Richard Bennett

    If Jobs were really serious about abandoning DRM, wouldn’t he offer free downloads from iTunes? I mean, if it’s wrong for the evil capitalistic record companies to profit from The People’s Music, surely it’s wrong for Apple to sell it.

    Besides, Apple doesn’t need the revenue from iTunes, Jobs could just go around and give live performances. The faithful would surely pay good money to see him perform, and that would be the end of world hunger.

Previous post:

Next post: