What's the reason DRM can't be implemented as an open-source solution? Is the closed source just to prevent people from easily accessing the secret key or are there other reasons it needs to be closed source?
Not to be a pedant (who am I kidding), but this is actually one of the examples where distinguishing between "free software" and "open source" is more than a philosophical disagreement.
You actually can create an open source DRM solution, because none of the OSI definition[1] makes reference to user freedom or other issues that DRM violates. As far as the OSI is concerned, DRM is can be released under an OSI license. Of course, you have to consider that according to the Digital Millenium Copyright Act, breaking DRM is _very_ illegal (regardless of whether or not the DRM'd media is still under copyright -- which means that DRM has no expiry).
However, if you subscribe to the free software definition[2], then you run into a problem. DRM in principle violates freedom #0: the freedom to run the program for any purpose. Now, there exist free software licenses that don't protect you against this threat (I believe only the GPLv3 actually addresses this issue), but note that just because a piece of software is under a free software license doesn't make it free software (there are whole classes of programs that might be GPLv3 but are still not considered by the FSF to be truly free -- DRM falls under that example).
Another reason is that I guarantee their EME implementations are going to be full of bugs and making the source available would just make it easier to find them. This is the same AAC conspiracy that gave us the Sony rootkit after all[3] (which then went on to be used by other viruses).
It runs in a separate process. I don't think that process is sandboxed in Firefox. And you probably can't restrict it too much or most Flash apps wouldn't work.
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.
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.
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.
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.
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.
> The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
I was thinking along the lines of Kerckhoffs' principle.
You seem to be conflating open source with key extraction or decryption ability. You seem to be saying that if a specification is known then that implies an ability to modify the system to a degree that allows those things.
You can have a system whose workings you know precisely, without obscurity, where the SW/HW specifications are open and the only secret is the key material. For instance, you could have keys be embedded in processor fuses. How would a user extract the keys in that scenario?
For DRM systems the user or consumer is the adversary, but the principles of secure system design still apply. You can still place an asset outside of adversary reach. For example, by ensuring that they need a super expensive FIB machine to read keys. Or, more traditionally, by tailoring cryptography to their computational power.
You seem to be conflating the malleability of software with its modifiability in a given system, but in reality those can be controlled. Yes, you can fork the software, but why are you assuming you can replace it on a given system?
Consider a black box with an LED. The box has an internal power supply and the LED emits light pulses in a given pattern pleasing to the user who purchased it. I could give you its physical properties and circuit diagrams. The box has data stored in internal memory. You can call parts of this data software if you like, as long as we agree that the output of the box is a function of this data and time.
The only contradiction inherent in DRM systems is that knowledge of the data/function needs to be given to the adversary and not given to the adversary at the same time. This has less to do with open or closed source, and more to do with whether the user can open the box.
I think that the "solution" to this contradiction has been reduction in fidelity, where the user/adversary is only given an approximation of the function (analog outputs that they have a hard time spreading to other would be users).
DRM sucks, but is not fundamentally at odds with open source.
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.
A DRM solution could be implemented with disclosed source code (though it would be more difficult than with concealed source code) but the key thing a DRM implementation does is to attest that the user hasn't modified the implementation--i.e. that the user hasn't exercised the freedoms provided by Open Source.
