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: Tue, 12 Oct 2010 20:16:00 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1P5lGS-0002vj-12@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10902

Maciej Stachowiak <mjs@apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjs@apple.com

--- Comment #34 from Maciej Stachowiak <mjs@apple.com> 2010-10-12 20:15:59 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > EDITOR'S RESPONSE: 
> > 
> > Status: Rejected
> > Change Description: no spec change
> > Rationale: DRM is evil.
> 
> I respect the editor's right to have a personal opinion on the political
> aspects of DRM, but that is not a technical response.
> 
> Is there a technical reason why HTML5 cannot support a form of DRM?
>

I understand the desire of some content providers to have DRM. But I think DRM,
by nature, cannot be specified by an open standard. Openly publishing DRM
format information allows it to be trivially broken, as you cannot obfuscate
what you are doing when there is a published specification for it.

This is why existing DRM schemes involve secret information about how the DRM
mechanism works.

HTML5 could say something about proprietary DRM schemes that might be embedded
in the media format itself, but it's not really clear if anything like that is
useful at the HTML level.


Another possibility is to add some opt-in trivial barriers to casual piracy,
such as a "no save" flag. This would put a small stumbling block in the way of
casual piracy but would do nothing to determine anyone who is even slightly
determined.

-- 
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 Tuesday, 12 October 2010 20:16:05 UTC

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