Mozilla's Route For Implementing W3C EME (HTML5 DRM)

[erendorn]

No, the recipient is the person watching the movie, on a PC most often the same person as "the consumer". "the media player" is a man in the middle, several steps away from the actual recipient.
If DRM were about protecting the content (as opposed to protecting involved corporate entities) then the content would be decrypted as close to the recipient as possible,
Currently most likely in the video hardware.

The consumer never gets the binary data. He gets analogue data, but not the source. The screen gets binary data (sort of, uncompressed), that's why there is HDCP encryption between the player and the screen (which happen quite close to the end user, at hardware level).
If the person watching the movie gets the binary data, there is obviously no DRM. So no, he cannot be the recipient of the data if said data is DRMed.

But that's precisely what's happening: with DRMed media you do not get the media, you only get a performance of the media (which is definitely a loss for the consumer).

[droidhacker]

Side-note: Cost is 7.5 euros per month for access to a usenet service in the netherlands.

[droidhacker]

The consumer never gets the binary data. He gets analogue data, but not the source. The screen gets binary data (sort of, uncompressed), that's why there is HDCP encryption between the player and the screen (which happen quite close to the end user, at hardware level).
If the person watching the movie gets the binary data, there is obviously no DRM. So no, he cannot be the recipient of the data if said data is DRMed.

But that's precisely what's happening: with DRMed media you do not get the media, you only get a performance of the media (which is definitely a loss for the consumer).

The good news, is that HDCP was broken years ago.
So worst comes to worst, you stick a little box on your HDMI wire and capture the good stuff.

And post it all on the internet, just to SPITE the content distributors whose sole objective is to make life miserable.

[Luke]

Decrypting DRM for playback implies ability to decrypt to file

Exactly! Because it is not related to protecting the content at all. That could be handled via cryptography


And that basically proves that DRM has nothing to do, at all, with protecting the content.
Because doing that would be possible using crpytography, as widely demonstrated in areas which really require secret and secure data (e.g. finacial transactions, diplomatic or military communication).

No.
Decryption, as a use case of cryptography, does not require the key to be part of the software doing the decryption.
When you do online banking, neither you nor your bank need to run a component created and shipped by the other. Yet each side is able to decrypt the data sent by the other party.

But we have already established above that DRM has nothing to do with cryptography even if the narrative around it uses phrases that sounds like it does.

You are of course free to believe in these fairly tales, no matter how much scientific evidence stands against them. Sometimes its just nice to switch of rational thinking and dive into a make-believe world.

Cheers,
_

OK, one way or another the end user has to be able to decrypt the DRM stream to analog data. That implies the ability to decrypt to a file as well. If it can go to analog in the video card, it can go right back to digital within the same computer, by screen and audio capture. No way any DRM plugin can prevent this in Linux other than HDCP, which as another poster pointed out was itself cracked years ago.

Also, HDCP is rarely used to prevent standard-definition copying or playback because few people will buy a new monitor to watch any one movie. They just downsample-but guess what? A lot of movies crossing the Internet as pirate torrents or files are downsampled even further to 360p simply to keep the bandwidth down. I shoot my videos in 1080p but never publish above 720P, often at 360p, so real world people with slow connections and old computers can play them. If HD is useless due to bandwidth constraints, then HDCP is out of the picture as well.

The most effective DRM I can think of is this: publish only in 4K video with no downsampling. Make the movie a single long video file. Nobody can fileshare something that big, so you get a monopoly until someone can rerender it down to a sharable size file. People might not want to burn the electricity to run an 8-core video editor for 8 hours plus just to give away the resulting data. If you made the movie so everyone wanted to see it in the original 4K, the result is a file that can't be moved except by shipping hard drives or SSDs. If you are worried that the movie theaters themselves will fileshare it, watermark it and threaten to cut deliveries to any theater chain caught charging admission to shared file movies.

[liam]

The consumer never gets the binary data. He gets analogue data, but not the source. The screen gets binary data (sort of, uncompressed), that's why there is HDCP encryption between the player and the screen (which happen quite close to the end user, at hardware level).
If the person watching the movie gets the binary data, there is obviously no DRM. So no, he cannot be the recipient of the data if said data is DRMed.

But that's precisely what's happening: with DRMed media you do not get the media, you only get a performance of the media (which is definitely a loss for the consumer).

It seems you could use all oss by using signed binaries. The binaries would be responsible for handling the key, decrypting the stream, and sending it to directly to the sink. So, it would be a pretty complicated piece of software which would need to reimplement parts of the display system for protected playback.
Why wouldn't something like that work, regardless of how difficult it might be to do?

[curaga]

It would require Restriced Boot, otherwise you could just switch the part that verifies signatures.

[erendorn]

It seems you could use all oss by using signed binaries. The binaries would be responsible for handling the key, decrypting the stream, and sending it to directly to the sink. So, it would be a pretty complicated piece of software which would need to reimplement parts of the display system for protected playback.
Why wouldn't something like that work, regardless of how difficult it might be to do?

Signing wouldn't help in this case (unless, as curaga said, your computer is not under your control and is trusted by the media provider).
You could do OSS without the decryption key, and any media provider (or its trusted partners) could ship binaries with the key included.
That's actually what some anti-DRM OSS software do (bluray and ebooks IIRC): they ship without the key because the method is legal but shipping the key is not.
That's also how you do OSS that access a controlled web API: you publish the source, but obviously without your API key. Then you provide builds that include the key.

The only issue with OSS without key is that source access makes it much easier to retro-engineer the builds that include the key, and extract the key from the media provider published builds.
As this is a significant downside, and OSS without key is not that useful (unless you want to add DRM to your family movies with your own keys ), DRM is only done in closed source.

[liam]

Signing wouldn't help in this case (unless, as curaga said, your computer is not under your control and is trusted by the media provider).
You could do OSS without the decryption key, and any media provider (or its trusted partners) could ship binaries with the key included.
That's actually what some anti-DRM OSS software do (bluray and ebooks IIRC): they ship without the key because the method is legal but shipping the key is not.
That's also how you do OSS that access a controlled web API: you publish the source, but obviously without your API key. Then you provide builds that include the key.

The only issue with OSS without key is that source access makes it much easier to retro-engineer the builds that include the key, and extract the key from the media provider published builds.
As this is a significant downside, and OSS without key is not that useful (unless you want to add DRM to your family movies with your own keys ), DRM is only done in closed source.

Are you referring to curaga's restricted boot comment? I'm not sure why that's necessary. Yeah, it would make things easier, but I don't see how you can fake the signing (unless you, miraculously, find a collision). Perhaps the problem you're speaking of is that of actually verifying that the hash provided is coming from the binary?
To be clear, I'm viewing this as purely a streaming service, so it's only going to be resident within the binary's process memory, and, presumably, a protected path through the display server to the sink.

[erendorn]

Are you referring to curaga's restricted boot comment? I'm not sure why that's necessary. Yeah, it would make things easier, but I don't see how you can fake the signing (unless you, miraculously, find a collision). Perhaps the problem you're speaking of is that of actually verifying that the hash provided is coming from the binary?
To be clear, I'm viewing this as purely a streaming service, so it's only going to be resident within the binary's process memory, and, presumably, a protected path through the display server to the sink.

I think I don't understand how you want to do it :S
Do you mean the streaming service would check that the binary is the one they signed? That's not possible, you would just give the service the official binary data, and then reroot the stream to you unsigned binary.
The signature seems useless to me, unless the local platform can be trusted to verify the signature and enforce protection accordingly.

[liam]

I think I don't understand how you want to do it :S
Do you mean the streaming service would check that the binary is the one they signed? That's not possible, you would just give the service the official binary data, and then reroot the stream to you unsigned binary.
The signature seems useless to me, unless the local platform can be trusted to verify the signature and enforce protection accordingly.

Yeah, that was the scenario I was talking about, but implementation would seem to be important. For instance, the service could, periodically, recheck the binary during service (say, as part of the encrypted stream format), that's why I mentioned the, incredibly unlikely, possibility of finding a collision to exploit this method.
Is that a bit clearer?
Rerouting the process might be tricky since, iirc, web sockets are tied to the receiving process.