[PavlovsCat]

To "properly" lock it down, you'd have to close the entire stack, and then you'd have to outlaw open source implementations.

ORLY? How does encryption work then? One could say "in order to properly encrypt your stuff, you actually need to make sure nobody is outside your window with binoculars", but that's not the job of encryption is it. I guess it would ultimately boil down to possession of private and public keys, and making it illegal to transmit those. So? As you said, they can deliver their stuff in proprietary apps already, what is lost when they use proprietary keys instead?

[anonymous]

YARLY! If you encrypt content, it's not DRM-protected. When you use a normal everyday encryption solution, you send me the encrypted data, encrypted with my public key and I decrypt it with my private key and then I CAN DO WHAT I WANT with it. That is what the entertainment companies want to protect against - the ability to move the plain bits once you have them decrypted. With any open-source software, you can change it to do whatever you want with the decrypted bits. Honestly, the only way for them to get what they want is to have a piece of special hardware, which you install in your pc, that does decryption of the media and outputs it only via secure connection to an a/v setup that contains a camera which does facial recognition to make sure only you are sitting in front of the PC.

Fortunately, that's still a bit too expensive to consider. Also, it will be broken by the first bored hacker with a soldering iron.

[jshen]

Most entertainment companies accept the current flash based solutions as sufficient. In this case they are trying to bring html5 to te same level as flash.

[icebraining]

Exactly; closed source and patented.

[jshen]

I'm pretty sure something similar to Adobe Access can be implemented for html 5 without requiring us to close source browsers, or patent them. I fail to see why you think otherwise.

[icebraining]

Because I still have faith that the W3C wouldn't sell out to a closed solution owned by a single company.

We're talking about a web standard, not some company's broken software.

[jshen]

They aren't talking about using adobe's software. They want to do something similar for html5.

[ajb]

And you expect them to stop there?

[jshen]

I don't think much of slippery slope arguments.

That aside, not having DRM for html5 would likely do more harm to the open web than not doing it. Take ABC for example, they only let you view their content through flash or through a native app. This hurts the open web more than giving them DRM in html5.

[EdiX]

> I don't think much of slippery slope arguments.

They are already closing the "analog loophole" everywhere else with HDCP and DRM enabled theater projectors, it's pretty clear that's where "content owners" want to be.

[jshen]

That is not what the bbc is asking for here!

[Udo]

Yes, really. Encryption in the browser today works exactly the other way around. It's sole purpose is to ensure data integrity on my behalf as things are transmitted between me and my chosen endpoint. The endpoint is not protected from me, and I can do whatever I want with this data once it arrives in my browser. DRM would be the antithesis of that. The problem is not they keys, it's what they keys can control or not.

[PavlovsCat]

That you'd need a closed source browser or plugin to access the draconian DRM content that insists on protecting the render path wouldn't mean anyone would have to consume said DRM content, or use such a browser for anything else. As you said, they could as well "put out an app", they already do; and adding a "content protection provider", a black box ultimately, to a browser just turns that browser into that app. But, and that's kind of my point, it doesn't affect my browser in any way I can discern, at worst it would mean somtimes seeing "sorry, your browser (or lack of plugins/dongle/whatever) does not support playback of this content", as opposed to that page not being there in the first place.

[jshen]

They aren't trying to "properly" lock it down. They are trying to bring html5 up to the same level as current flash based solutions.

[xj9]

I'm pretty sure you can do that already. HTTP has authentication, HTTPS gives you content encryption, rate limiting can prevent content scraping, I mean if you really wanted to you could do something with canvas (the hardware acceleration stuff that's being worked on could even make it perform fairly well, I suppose). Its not the same way but it could give the same result.

[jshen]

You can't do it already. What you described is not the same level as current flash solutions.

[xj9]

Well, I'm not particularly familiar with DRM apart from not liking it. What exactly does flash do that makes the DRM-loving lawyers consider it acceptable? From my point of view the kind of control offered by HTTPS and normal browser authentication is enough but the MPAA and RIAA (or the BBC, for that matter) clearly don't agree.

[jshen]

In flash, the bits that are coming down over HTTPS are DRMed. If you save them to your local disk you can't play it directly.