[Bug 10902] <video> element needs to support some form of DRM solution


--- Comment #30 from John Foliot <jfoliot@stanford.edu> 2010-10-09 20:56:50 UTC ---
(In reply to comment #29)
> Please, stop this thread! DRM is not something that should *first* be spec'ed,
> *then* implemented: as Mark Pilgrim says, "those that ship are those that win".

But this is just the point. DRM has shipped - a long time ago

It's not even whether or not the encryption method is bullet-proof or not (it's
likely not), it's not about the philosophical debate over whether or not DRM is
Evil or not (and my *opinion* would likely surprise some), it's about what will
browsers do when fed a video file that has DRM encryption (say perhaps Apple's
supported AES encryption) in the wrapper? It seems there is two choices, ignore
the encryption (how? why? really?) or throw an error.  

Since HTML5 is supposed to also be defining error handling, can we please know
how to handle this error? A blue lego block? A blank black box? Can we have
this standardized please? 

Further, if commercial content sites (Hulu?) want to use the <video> element,
but the owners of their source of content insist on some form of encryption,
what are they to do?

a) Ignore that request? No business model there
b) Use a plugin solution that supports an encryption/decryption scheme? Flash
and Silverlight allow this today
c) Ask for a native HTML5 solution to this real problem? Why I submitted this

> If you want DRM, go here: https://bugzilla.mozilla.org/, and there:
> https://bugs.webkit.org/, and ask for implementations in development builds.
> THERE will the real discussion be. Once experimentations come to a working
> implementation, we won't even need to spec it, because IE will be eager to
> follow.

*I* DON'T WANT DRM! (allow me to repeat that for the hard of reading: *I* DON'T

DRM exists. How does HTML5 plan to deal with it?

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 9 October 2010 20:56:52 UTC