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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10902

--- Comment #25 from Shelley Powers <shelleyp@burningbird.net> 2010-10-06 18:38:22 UTC ---
(In reply to comment #24)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: 
> 
> Ok so apparently "DRM is evil" was a little too pithy, so let me be more
> long-winded:
> 
> * DRM is mathematically impossible. You can't create a tool that
>   simultaneously allows the user to access data while preventing the
>   user from accessing that data. It's just not possible. It doesn't
>   matter if it's hardware-based (HDCP is broken), run purely by a
>   private vendor (FairPlay is broken), a trivial protocol (CSS is
>   broken), or a complicated protocol (AACS is broken).

So you're saying here there is no implementation of DRM?

> 
> * One can't even make a pretence that DRM is possible in an open
>   standard with open source implementations. By definition DRM assumes
>   that there is a shared secret involved, at minimum a secret
>   per-vendor key shared between a coordinating entity and the user
>   agent implementor. That is completely incompatible with a world
>   where anyone can recompile their browser.
>

Not all browsers are open source. 

And there have open DRM specifications. Are you arguing from a philosophical
perspective, or a technical one?


> * Actually working DRM, were it possible, would be user-hostile. Its
>   entire purpose is to prevent users from doing anything they want
>   with the content.
>

Oh that is definitely philosophical -- the longer version of "DRM is evil". 

> * DRM, even in its broken state, is user-hostile. It adds a "ripping"
>   stage to any unusual use case.
> 

ditto

> * Any kind of encryption intended for content protection may lead, in
>   some jurisdictions, to implementors being liable if they can be
>   argued to allow the user to circumvent that encryption.
>

> * DRM is intended to prevent piracy, but in practice content that is
>   protected by DRM is uniformly and regularly available without such
>   protection on file sharing networks, often long before the
>   DRM-protected content is actually released to the market. Thus DRM
>   doesn't actually work to solve the problem it's intended to solve.
>

Philisophical.

> * The DRM technology space is heavily patented, and it is quite
>   possible that it would be unreasonably difficult to create a
>   specification for a DRM scheme that was unimpeded by patents, which
>   is incompatible with W3C policy.
>

This is a valid concern. Of course, one could also say that the W3C's patent
policy would serve to protect implementors. 


> * In any case, defining a DRM format is out of scope for HTML, since
>   it is a video format issue.
> 
> Any one of these points would be sufficient grounds to reject this bug.

Actually, only the last one reason is one approaching sufficient grounds to
reject the bug, but not necessarily with WONTFIX. A better approach might be to
list it as NEEDSINFO, because as others have noted, there's more than one part
to this question. 

The IDPF doesn't integrate a specific DRM into the ePub specs, but it does
provide a framework for DRM[1][2]. In addition, the spec also states that a
specific DRM format may be incorporated into a future version of the spec.
However, the OCF spec is the ePub container specification, so it is reasonable
to assume that it may incorporate a DRM format at some later time. The question
is, is it reasonable to say the same of HTML5?

If HTML5 only incorporates syntax and parsing rules, no, not really. But HTML5
incorporates media objects, specifications for the browser context models, and
even at one time, the Canvas object. So the spec isn't really just syntax and
parsing rules. 

So, asking whether such a framework should be provided in HTML5 is, in my
opinion, a good question. An interesting question. However, I think it's too
complex a question for a discussion in a bug. But that's just my opinion. 

This would be a good inter-group discussion item between the HTML WG and the
Web Apps people. And I think it's important to discuss DRM rationally, rather
than emotionally. 

[1] http://www.idpf.org/forums/viewtopic.php?t=22
[2]

-- 
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 18:38:25 UTC