Are "Premium Media Extensions" also plugins? Because if so this didn't really get much better. It still means Linux users could be on the backburner until someone decides we can watch too. Until Mozilla and Google are on board this doesn't necessarily seem better from a "universally available" standpoint.
Yes. There is no reason to think that things which did not work on Linux before will suddenly start working just because this API is being crammed into HTML5.
I'm not necessarily saying that Linux will ever be a high priority, but having to only provide a PlayReady Media Extension for a few browsers on Linux is a much more reasonable effort then providing the whole Silverlight or Flash runtime.
Linux will never get a PlayReady Media Extension. Linux users control the kernel of the device. Even if hypothetically TPM technology or similar could be used to play video "securely" nevertheless (with hypothetical future tech), it would still be too great a risk to let it on to such a "compromised" system.
You could delegate decryption to the video-card itself. This would also prevent the attack vector of running a 'secure' system inside of a transparent VM.
Not to mention the fact that Linux has some very smart people, with a history of reverse engineering stuff for compatibility; and breaking any advanced DRM system is an honor onto itself.
That was the hypothetical future tech I had in mind. AFAIK, it does not exist. It would also need to integrate with the audio, while still letting DRM-unprivileged processes manipulate the location on the screen, volume, pause, fast forward, etc etc etc. It's a pretty tall order to make all this work on a system where the user is controlling the entire rest of the software stack, and absolutely, positively ensuring that there is no way whatsoever to get the audio or the video, even though the user has every other bit of hardware at their disposal, in what are presumably numerous distinct hardware configurations. It's certainly theoretically possible but it would take numerous released-to-the-public iterations to get right and probably a few more for this to be remotely stable.
>ensuring that there is no way whatsoever to get the audio or the video
I await the patent on how to DRM photons.
Relating to the rest of your points, I am not convinced that it is that difficult to mix protected and non-protected graphics. The untrusted software tells the graphics card a square region of the screen where the movie should be played, and streams the cipher text to the card. When the graphics card goes to render a frame for the physicall display, it first renders the the protected content, then renders any unprotected content from the software. Where the two overlap, the protected content simply gets hidden by the unprotected content. Obviously, all of this rendering would happen in an undisplayed buffer, so the user only sees the finished frame.
Yes... the spec is simple. I don't deny that. But in a world where the leading graphics vendors can barely write drivers that don't crash on their own hardware... who, exactly, is going to get it all right? On real hardware? That people will buy?
It's all simple and obvious until you try to implement it on real hardware.
They would have no control over the rest of the stack. If netflix created a linux build of a DRM binary that worked with their service then it would become the tool of choice for everyone that wanted to rip/upload to usenet the latest Netflix exclusive content. Also they frankly just don't care about linux users.
If this were something that they were interested in having, they would have had Netflix on Chrome on 'regular GNU desktop' Linux months ago when it started working with Chrome on a Linux kernel with ChromeOS.
If an extension to XvMC or the proprietary ATI/Nvidea equivalent supported a protected path for media content, which could theoretically bypass the kernel by sending ciphertext directly to the renderer, then Widevine or another DRM system could be supported on GNU/Linux.
Seems possible, though theoretical. I would not expect to see this unless somebody was paying for it (no particular reason for ATI/Nvidia/Whoever to go out of their way to support such a thing), meaning that I will not expect to ever see it in "normal" Linux distros (perhaps in "ChromeOS style" locked down distros being marketed with their own completely separate branding).
Proprietary graphics stuff in Linux has always been a world of hurt anyway (despite the lower performance it was a godsend when progress on the radeon drivers started to accelerate). I would expect few Linux users to be thrilled about compromising their streamlined modern Linux installation to watch netflix when a separate Roku or smartphone would do. (I know I would never go for this proposal. It would not be worth the grief to be plunged back into 2005. Not on the computer that I try to get work done on...)
This was the spoken about way of achieving the goal on the HTML WG mailing list, if that is required, on Linux (note Flash doesn't do that currently and many are happy to licence content for it despite that, so this may well never come to fruition).
Since DRM is all about making it inconvenient/difficult to delay the inevitable, yes.
They are not going to do anything that will only help a very fraction of their subscribers but would streamline, let alone automate, the ripping process.
Moreso than a few pipes and a hacked up curl? I doubt it. My impression is that the current preferred method is ripping the decoded video stream from an unsecured cable.
The situation for Linux users is better with Netflix on Silverlight, because Silverlight runs in Wine. With EME or PME or whatever they want to call it to make it sound less onerous, Linux users have no hope.
Premium Media Extensions (which we should probably just call Proprietary Media Extensions) sounds like a marketing name for EME+CDM. We should not let major media providers co-opt the term "premium" to mean "encrypted" or "blessed by Hollywood".
