W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2010

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 06 Oct 2010 16:15:46 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1P3Weg-00009T-I2@jessica.w3.org>

--- Comment #23 from John Foliot <jfoliot@stanford.edu> 2010-10-06 16:15:44 UTC ---
(In reply to comment #17)
> We generally speak for ourselves, as Opera generally doesn't have any official
> position on these things.
> But as far as support for DRM in the HTML layer is concerned, there appears to
> be no support for that among those of us who are at Opera. 

It seems that both Charles McCathieNevile (Comment 13) and Philip Jägenstedt
(Comment 15) are actually taking this issue seriously enough to discuss the
technical problem and issue (as opposed to effluenting about their
philosophical stand) so even here your "Royal We" seems somehow inflated beyond
yourself, and perhaps 1 or 2 others. I suggest you remain realistic and stick
with the first person "I".

(Bringing it closer to home, I think it is no secret that Nokia and Opera have
a strong bond and symbiotic relationship. If Nokia cannot accept a solution
that does not support some form of DRM [as they have previously stated] then
how will Opera support your client's need?) 

> From a purely
> technical perspective, it just doesn't belong in here at all, as explained in
> comment 1 and reiterated by others.

And as I have responded, if the 'handling' of DRM is done by the player, and
<video> seeks to make the browser the player, then the browser must be able to
process and support content that authors want to have protected. I have offered
no suggestion as to how to do this, as honestly I am not sure exactly, but I
recognize the need exists so I put forth the problem statement to the

So I will ask the Royal We's this question: how, using HTML5's <video> element,
can content creators ensure rights retention and fair compensation for their
creative work? 

If the entire point of the <video> element is to remove the need for plugins
such as Flash and Silverlight, yet both Flash and Silverlight *DO* allow for
this real world, oft articulated author need, then where is the value in
working on and promoting <video> as the replacement for Flash and Silverlight? 
DRM might not be perfect, but nobody seems to have come up with a better
solution yet. You are deliberately crippling the element simply on the grounds
of philosophy.

> The question of DRM within the media formats supported by browsers is a
> separate issue to be addressed in a different forum, but as I said, I'm fairly
> sure there will be strong resistance to it.

Really? I have it on first person confirmation that currently Apple is
promoting "...H.264 with the m3u8 format for HTTP streaming with optional AES
encryption..." to commercial content producers in North America. Either that
gets supported directly in the browser, or gets handed off to a third party
(QT)player... Frankly at this point I could care less if Opera, Mozilla and
Google see this as a problem or not - it's your business models, not mine.
Apple will profit by selling their iDevices that *do* support encryption, as
will Roku, Wii, X-Box and other companies who understand the real business
needs at the intersection of the multi-billion dollar industry that is "the
Internet" (delivering content over the global network) with the multi-billion
dollar industry that is the Entertainment Industry. 

I have repeatedly stated that I too am *personally* opposed to DRM. All content
I create and post to the web comes with a Creative Commons license (and I have
used CC licenses since the emergence of CC as an option in 2002). I purchase my
music from online retailers who provide content without DRM encryption (so that
means I *don't* purchase from iTunes) and I left the music industry over a
decade ago (after a 15 year career at EMI/Capitol Records) because I saw the
writing on the wall then, so I don't need any lessons from you or others on
what the issues and problems are.

None of this removes the fact that many content owners will want a means to
secure their content (a point not missed by Apple, Microsoft or Adobe), and
either HTML5 provides to that need, or the content owners will look elsewhere
and the <video> element will be relegated to the category of "nice idea but no
cigar". The only real losers there will be the browsers, as video will continue
to be delivered via the web, but via more robust solutions developed "in other

Lead, follow, or be left behind - it's really your choice.

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 Wednesday, 6 October 2010 16:15:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:59 UTC