5 ms·

DRM is fundamentally security by obscurity. Being closed source is the only way to maintain obscurity, and thus the illusion of security.

problems 9y ago
Yeah, this may change (in a somewhat scary way) with the Intel TXT and SGX extensions as then you'd only be relying on the obscurity of the hardware rather than the software.
ngneer 9y ago
I disagree. Technologically it is possible to build a content protection system without obscurity, using open source software and open source hardware (and suitable cryptographic bootstrapping). That no one chooses to do so is another matter.
- asdfpoiuqwer 9y ago
  If you plan on putting a chip in my head that speaks DRM, then yes. Ultimately my screen has to show me the pixels and my speakers have to play the audio.
  - kelnos 9y ago
    Sure, and you can point a camera at the display device, but you'll suffer lower quality. And you can also buy some expensive hardware to sit between the HDCP decoder chip and the output to the display panel, and buy some more expensive hardware to deal with the huge volume of raw, uncompressed video that comes out of it. But the content producers are betting that most people won't consider the first option good enough, and will find the second option prohibitively expensive. They're also betting that most people will opt for the convenience of getting it through the browser or mobile device (for a fee) and won't want to deal with getting it from not-so-legit sources. They're comfortable with these tradeoffs, for now, so they're doing what they're doing. They absolutely don't care about the small minority of people who will do anything to get hold of the content unencumbered. They know they can't control that group of people, but they aren't losing sleep over it. Because, for now, that minority is too small to hurt their bottom line. If that changes, I'm sure they'll pursue a new strategy. But for now, they don't need to.
- frivoal 9y ago
  How so? The effect of DRM is to prevent the user from doing things that would otherwise be technically possible, such as copying. Once the software has decrypted the media, it can do whatever it wants with it. It is just so designed that what it wants to do with it is not the same as whatever the user wants to do with it. Free or open-source software give the right and the ability to the user to modify what the software does. So if a feature is missing (save a backup copy), the user can add it (or pay someone to). I piece of software cannot at the same time: * be able to decrypt a video * be able to be changed at the users' will * be prevented from doing certain things the user wants. If you merely write a piece of open-source software that lacks the ability to save a copy, you merely have a missing feature that can be added by anyone who wants to fork it, you are not preventing copying. If the decryption is done in hardware, the problem is the same, just shifted. If people have the ability to change the hardware, then we're back to square one, and if they don't, then it's not a free/open-source system.
  - kelnos 9y ago
    I think the parent's point is that it's absolutely feasible to build hardware and software that successfully enforces a DRM scheme, and also release the specs for the hardware and the source of the software. That doesn't mean that a content producer will verify any old (modified) version of the software and allow it to play (and possibly "leak") their content. Put another way: it's possible to build a secure DRM pipeline and then release all the source to it while maintaining the security of _that particular version_ of the pipeline. It's perfectly possible (cryptographically) to set it up so an unmodified version of that pipeline will be able to play protected content, while modifying it to (for example) dump decrypted bits to disk will cause the content to fail to play at all.
    - chii 9y ago
      but what part of the pipeline is responsible for the verification of the 'unmodified' trait? If it's a part that's open-sourced (hardware or software), then won't it simply be _modified_ to allow it to pass and allow extraction of decrypted content? If it's _not_ open-source, then you don't have a fully open-source DRM scheme.

problems 9y ago

Yeah, this may change (in a somewhat scary way) with the Intel TXT and SGX extensions as then you'd only be relying on the obscurity of the hardware rather than the software.

ngneer 9y ago

I disagree. Technologically it is possible to build a content protection system without obscurity, using open source software and open source hardware (and suitable cryptographic bootstrapping). That no one chooses to do so is another matter.

asdfpoiuqwer 9y ago
If you plan on putting a chip in my head that speaks DRM, then yes. Ultimately my screen has to show me the pixels and my speakers have to play the audio.
- kelnos 9y ago
  Sure, and you can point a camera at the display device, but you'll suffer lower quality. And you can also buy some expensive hardware to sit between the HDCP decoder chip and the output to the display panel, and buy some more expensive hardware to deal with the huge volume of raw, uncompressed video that comes out of it. But the content producers are betting that most people won't consider the first option good enough, and will find the second option prohibitively expensive. They're also betting that most people will opt for the convenience of getting it through the browser or mobile device (for a fee) and won't want to deal with getting it from not-so-legit sources. They're comfortable with these tradeoffs, for now, so they're doing what they're doing. They absolutely don't care about the small minority of people who will do anything to get hold of the content unencumbered. They know they can't control that group of people, but they aren't losing sleep over it. Because, for now, that minority is too small to hurt their bottom line. If that changes, I'm sure they'll pursue a new strategy. But for now, they don't need to.
frivoal 9y ago
How so? The effect of DRM is to prevent the user from doing things that would otherwise be technically possible, such as copying. Once the software has decrypted the media, it can do whatever it wants with it. It is just so designed that what it wants to do with it is not the same as whatever the user wants to do with it. Free or open-source software give the right and the ability to the user to modify what the software does. So if a feature is missing (save a backup copy), the user can add it (or pay someone to). I piece of software cannot at the same time: * be able to decrypt a video * be able to be changed at the users' will * be prevented from doing certain things the user wants. If you merely write a piece of open-source software that lacks the ability to save a copy, you merely have a missing feature that can be added by anyone who wants to fork it, you are not preventing copying. If the decryption is done in hardware, the problem is the same, just shifted. If people have the ability to change the hardware, then we're back to square one, and if they don't, then it's not a free/open-source system.
- kelnos 9y ago
  I think the parent's point is that it's absolutely feasible to build hardware and software that successfully enforces a DRM scheme, and also release the specs for the hardware and the source of the software. That doesn't mean that a content producer will verify any old (modified) version of the software and allow it to play (and possibly "leak") their content. Put another way: it's possible to build a secure DRM pipeline and then release all the source to it while maintaining the security of _that particular version_ of the pipeline. It's perfectly possible (cryptographically) to set it up so an unmodified version of that pipeline will be able to play protected content, while modifying it to (for example) dump decrypted bits to disk will cause the content to fail to play at all.
  - chii 9y ago
    but what part of the pipeline is responsible for the verification of the 'unmodified' trait? If it's a part that's open-sourced (hardware or software), then won't it simply be _modified_ to allow it to pass and allow extraction of decrypted content? If it's _not_ open-source, then you don't have a fully open-source DRM scheme.