More about the Chrome HTML Video Codec Change (The Chromium Blog) [LWN.net]

More about the Chrome HTML Video Codec Change (The Chromium Blog)

Posted Jan 16, 2011 7:51 UTC (Sun) by drag (subscriber, #31333) [Link]

Yes. It's easy to break DRM since it's such a bad idea. Flash's DRM is really pathetic and it's even documented online.

To get a idea: a stripped down version of SSL with all the stuff that makes it secure from man-in-the-middle gone and the 'cert' for a application is derived from a number sent from the server during connection hashed against the physical size of the application.

That's how bad it is.

But nobody is allowed to talk about it in detail because laws protect it. Since we have laws protecting DRM then those laws trump reality.

I really have no problem with DRM, per say. If somebody wants to use it then they can use it. The problem is caused by the laws. If it was not for the laws then DRM cracking software and hardware would be a entire industry in the USA. New DRM schemes would generate as much money for the people breaking the DRM as the people making the DRM.

But it can be made to work both ways. With HTML5 and Javascript it should be possible to make a DRM scheme that is on par, or is even better, then what Flash provides. If any pro-flash entity then tries to point out how stupid and pointless such protections are then you can just have the government persecute them for violating the DMCA.

It's just to bad it can't be open source. Not that anybody would be missing much. Just as long as anybody with anything that is actually important (that is instead of reruns of old TV shows and bad movies) doesn't actually trust it with anything.

More about the Chrome HTML Video Codec Change (The Chromium Blog)

Posted Jan 16, 2011 19:30 UTC (Sun) by krake (subscriber, #55996) [Link]

Wouldn't it be better to come up with a way of doing DRM in the actual receiving hardware (video/audio chip) and let player/browser only be part of the transmission chain?

All this "needs to be closed source" non-sense comes from the wrong assumption that any host software needs to see the unencrypted content, doesn't it?

More about the Chrome HTML Video Codec Change (The Chromium Blog)

Posted Jan 17, 2011 0:25 UTC (Mon) by drag (subscriber, #31333) [Link]

> Wouldn't it be better to come up with a way of doing DRM in the actual receiving hardware (video/audio chip) and let player/browser only be part of the transmission chain?

Not for my purposes, no. The higher it stays in the stack the better it is for all of us.

> All this "needs to be closed source" non-sense comes from the wrong assumption that any host software needs to see the unencrypted content, doesn't it?

If you looking at finding a replacement for Adobe flash trying then to convince people that they should drop 300 dollars on non-existent hardware that can decrypt and process media entirely on it's own is probably not the right approach.

More about the Chrome HTML Video Codec Change (The Chromium Blog)

Posted Jan 17, 2011 11:36 UTC (Mon) by krake (subscriber, #55996) [Link]

Not for my purposes, no. The higher it stays in the stack the better it is for all of us.

My line of thinking is that decryption in the output hardware does not require any special kind of software in the operating system or higher up, making content accessible even by users of alternative operating systems, media players and browsers.

If done higher up we end up with crap like Microsoft's "secure media path".

...trying then to convince people that they should drop 300 dollars on non-existent hardware...

I didn't get that part. My understanding is that very specific data processing, e.g. media decoding, is first implemented in software to be easily deployable to the mass market even if it more efficient to be implemented in hardware.

So after a pure software base period there is a transitional period where hardware implementation become common. Some customers might even prefer a hardware based solution and buy devices offering such in favor over ones with host software based solutions.

But I could be mistaken and deployment of host software based solution is always delayed until a significant portion of the market has hardware based solutions available as well. My personal impression was that it doesn't work that way though.

More about the Chrome HTML Video Codec Change (The Chromium Blog)

Posted Jan 17, 2011 12:14 UTC (Mon) by drag (subscriber, #31333) [Link]

> I didn't get that part. My understanding is that very specific data processing, e.g. media decoding, is first implemented in software to be easily deployable to the mass market even if it more efficient to be implemented in hardware.

The hardware you talk about doesn't exist. That's what I mean. I am sure that it's all fine and dandy in some abstract theoretical sense.

Remember the problem domain here: we are looking for a flash replacement. I know I am in fantasy land also, but it's just really speculation. It's probably a horrible idea to try to obfuscate decryption in javascript, but requiring people to purchase new hardware is even less likely to work.

More about the Chrome HTML Video Codec Change (The Chromium Blog)

Posted Jan 18, 2011 11:51 UTC (Tue) by krake (subscriber, #55996) [Link]

The hardware you talk about doesn't exist. That's what I mean.

I see. As I said, my impression was that hardware gets replaced at some point by newer one, introducing capabilities formerly available only in software.

But I might be mistaken and all graphics chips always had video decoding in them, even for codecs that didn't exist yet.

As a software engineer I surely would appreciate some of that fairy dust these hardware engineers seems to have at their disposal, being able to deploy algorithms before they are invented.