This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
If < video > is to see widespread adoption by commercial content providers, then there must be a means to support some form of native DRM if it is to compete with Flash (http://opensource.adobe.com/wiki/display/osmf/DRM+Support) or Silverlight (http://www.microsoft.com/playready/default.mspx)
HTML is a presentation layer that can embed flash, silverlight, MP4, Ogg, AVI, or a host of other formats, They are formats. The problem of DRM belongs to them, not this layer.
I formally object to adding this.
(In reply to comment #1) > HTML is a presentation layer that can embed flash, silverlight, MP4, Ogg, AVI, > or a host of other formats, They are formats. The problem of DRM belongs to > them, not this layer. Does HTML5 'embed' MP4/OGG/WebM content, or does it render it, by using the browser as a native player and linking (using SRC=) to the file? Assuming a video which has some form of DRM solution (MP4 with AES encryption?) is linked using the video element, how does the browser know that the end user is authorized (or not authorized) to see this video? Embedding Flash or Silverlight into a webpage *does* hand off DRM to the player, but with <video> the browser *is* the player (complete with native and scripted controls, etc.). I'll pose this as a question: How would Limelight Networks (http://www.limelightnetworks.com/) use the <video> element to stream videos to the web, yet at the same time prevent piracy of their clients' commercial investment? I am sensitive to the many voices that are opposed to DRM (and in fact I am philosophically opposed to that idea myself), however this is a topic which must be answered in some way or other if the <video> element is to be used by more than just hobbyists. I have heard first hand that HTML5's lack of DRM solutions is a major impediment to commercial adoption. (http://www.streamingmedia.com/Webevents/263-Making-Sense-of-the-HTML5-Buzz-HTML5-Q%26A-with-Industry-Experts.htm)
anything you can reference by URL can be placed in a web page, including protected images and movies. the browser might well incorporate some built-in capability, but how the browser plays the URLs is out of scope. we don't specify file format or codec or DRM or access protocol (http vs rtsp vs proprietary) or anything else. the html layer stops at saying "here is the video".
DRM is mathematically impossible, plenty of methods for obfuscation already exist.
I get that this is an unpopular topic, but that won't make it go away. I offer as proof that this is an important issue the following: http://forums.sun.com/thread.jspa?threadID=674699 (which talks about DRM using AES: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard - also used by Apple I believe to supply DRM in H.264 encoded content) http://odrl.net/2.0/WD-ODRL-Vocab.html http://en.wikipedia.org/wiki/Marlin_(DRM) I have very little stick in this topic, but I can also see and hear where this *is* an issue for content owners and creators. If we want <video> to become ubiquitous, we need to ensure that DRM can be supported. The following 2 URLs might also be informative: Position - http://data.daisy.org/publications/docs/positionpapers/position_paper_protecting_content.html Solution - http://www.daisy.org/project/pdtb
I reiterate the comments made in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/026955.html I'd like to draw particular attention to the observation about Hollywood movies being routinely broadcast over DVB-T/C without DRM.
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: DRM is evil.
(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? The current rationale is not a rationale, it is an opinion, and as such is unacceptable. Commercial content licensees (such as Netflix or Blockbuster) will require a means to protect content they want to stream over the web, and without a means to do so they will continue to turn to 3rd-party solutions such as Flash or Silverlight to achieve this. Failing to compete *on features* currently available in competitors to <video> artificially retards the potential for take-up - all because of a philosophical stance of the editor? REOPENED, and I respectfully request that this discussion remain focused on technical issues, and leave opinion and politics out of it. (In reply to comment #7) > I reiterate the comments made in > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/026955.html Your 'observation' has no references that can be independently verified, while I can point definitively to Netflix in the US as having a DRM solution in place as part of their license agreements with Major film studios. "Netflix says the move to PlayReady DRM will make it easier to get content providers (movie studios and the like) to supply a steady stream of, well, content...The first devices making use of this new DRM should hit stores early this summer." http://www.crunchgear.com/2010/05/25/netflix-goes-with-microsoft-playready-drm-for-upcoming-streaming-devices/
(In reply to comment #9) > (In reply to comment #7) > > I reiterate the comments made in > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/026955.html > > Your 'observation' has no references that can be independently verified http://digitv.fi/sivu.asp?path=9;1235 shows which channels in Finland are unscrambled ("free-to-air" on the chart). http://telkku.com/telkku?p=20101022 is a TV schedule showing Blade Runner airing on one of the unscrambled channels. http://telkku.com/telkku?p=20101018 shows Casino Royale, which is a newer big money movie, though maybe not a "Hollywood" movie. E.g. EyeTV for Mac makes it technically possible to record content from these channels and to export it without DRM to any format supported by QuickTime. Evidently, the movie studios do supply "premium" content to digital distribution channels that don't use DRM.
Regardless of the undeniable fact that DRM is a stupid idea, documenting support for any paticular DRM scheme is out of scope of HTML5, just like codecs and container formats are out of scope. Not only that, but requiring any form of DRM scheme in HTML5 would more than likely not succeed because: * The decryption algorithm would have to be public, and any implementation would need access to the keys, defeating the delusion about stopping piracy. * It would make implementers subject to the licensing fees of the DRM provider * It would expose browser vendors to legal nightmare that is DMCA compliance, and similar draconian anti-circumvention laws around the world dealing with TPMs; * It would make it impossible for free and open source implementations to implement the DRM scheme. * Browser vendors would be at the mercy of the demands of the entertainment industry as they continually attempt to introduce tougher legal restrictions and compliance requirements, or risk being unfairly locked out of their content. So the only thing DRM does is let the entertainment industry control innovation and participation in the market, under their own terms and conditions, and any one who doesn't comply with their demands is locked out. We absolutely do not want that. So, no, we will not support any form of DRM in HTML5, and I'm fairly sure we will strongly resist any attempt to introduce such measures into WebM or Ogg media. Please close this bug.
What a DRM solution requires is that authorized clients should be able to easily access the content, but unauthorized clients should not. In the case of a single proprietary application such as Flash, "authorized clients" are the official binaries, and "unauthorized clients" are everyone else. In those conditions, DRM is possible to some extent -- you can at least force unauthorized applications to subvert or reverse-engineer your binary. However, the goal of a W3C standard is to permit any client to implement the standard royalty-free. If the way to extract the content is specified such that anyone can do it, you don't have DRM à la Flash and Silverlight. Much more limited DRM is possible here -- like "browsers agree to not allow 'Save As...' if some flag is set, so you have to view source to get the contents, and content providers can blacklist browsers that are known to ignore the flag". However, this can already be emulated pretty well by just sticking a transparent div over the player and handling right-clicks via JS, which is what YouTube does last I checked. That method has the benefit of requiring no extra implementer work and having no possibility of implementers ignoring it. I suggest that the editor reclose this bug as NEEDSINFO until such time as the reporter can clarify what kind of DRM is being requested -- DRM such as Flash and Silverlight implement ("try to stop anyone from accessing other than our closed-source binaries") is clearly impossible in an open standard. If the desired DRM is narrow enough, like just a flag on <video> elements that says "Don't provide 'Save As...'", it might fall within the scope of HTML5. It could then be evaluated like any other feature -- although I think the likely result would be WONTFIX. I can't think of a DRM feature that's narrow enough to fall within HTML5 but useful enough (compared to just doing something in JS) that it's worth adding. I don't think it's necessary to consider the question of whether we want to support DRM in principle (the editor's position), if we can rule out the proposal even assuming DRM support is desirable. It seems very likely we can resolve this without ever addressing the contentious issue of whether we want to support any DRM. Compare to the incredibly lengthy bickering that occurred in the Web Fonts WG on this issue -- we should avoid that if possible.
(In reply to comment #4) > anything you can reference by URL can be placed in a web page, including > protected images and movies. the browser might well incorporate some built-in > capability, but how the browser plays the URLs is out of scope. we don't > specify file format or codec or DRM or access protocol (http vs rtsp vs > proprietary) or anything else. the html layer stops at saying "here is the > video". Almost. It also has terminations points when it says "here isn't the video". I am not sure that HTML should try to specify a DRM mechanism, any more than it should specify a format (in part because I don't think it is ever effective enough in practice to be good enough to include in a standard as important as HTML, even if there were agreement that we wanted to do so). But I think it makes sense to allow a DRM-protected video to provide a known error which can be trapped, so you can make whatever request might allow the user to see it, since this is a clearly different error to something based on a parental control block, or a basic network failure. In any event, "DRM is evil" plumbs a new depth of discussion even in this group. Whatever you think of it there are very clear industry use cases for DRM. I note that for example Apple's product developers seem to have decided this was important enough to ship everywhere.
(In reply to comment #11) > Regardless of the undeniable fact that DRM is a stupid idea, Again, Lachlan, Ian and the rest of the clubhouse can hold whatever opinion they wish in regards to DRM; it is also an undeniable fact that DRM exists today, that some content creators and owners insist on DRM associated to their content, and HTML5 (the specification) needs to address this issue as an undeniable business requirement for the modern web infrastructure - philosophy and opinion aside. <blockquote>Nokia to W3C: "from our viewpoint, any DRM-incompatible video related mechanism is a non-starter with the content industry (Hollywood). There is in our opinion no need to make DRM support mandatory, though."</blockquote> - http://boingboing.net/2007/12/09/nokia-to-w3c-ogg-is.html > We absolutely do not > want that. > > So, no, we will not support any form of DRM in HTML5, and I'm fairly sure we > will strongly resist any attempt to introduce such measures into WebM or Ogg > media. I am curious to know who this "we" is you are speaking for. Is Lachaln speaking on behalf of the W3C, Opera Software, or himself, the editor and a small group of engineers who want to pretend DRM out of existence by placing their hands over their ears and chanting "lalalalalala"? Both Aryeh & Chaals have started a dialog that looks at the issue from a technical perspective, acknowledging that DRM exists and that the HTML WG should be investigating this from a technical perspective, and not from one of personal philosophy. I thank them and encourage the rest of the Working Group to discuss this issue as adults responsible for getting this technology figured out right.
An easy way to provide obfuscation was suggested by Chris Blizzard at FOMS. If it's possible to feed <video> with binary blobs from JavaScript, then people can implement whatever "DRM" they want in JavaScript. What is sent over the network (using XHR, WebSockets or some such) could be obfuscated, or not. So, we could allow DRM to be implemented as a side-effect of supporting video.write(blob) or some such interface, for which there are also other use cases.
I think this should be resolved as WORKSFORME without any change to the spec due to the reason stated in comment 1. HTML5 already allows arbitrary video formats. Thus, you could create e.g. a container format (e.g. ".webdrm" for the sake of example) which would have its contents obfuscated in some way. As for comment 13, I think it's not important to distinguish between the error situation "the video didn't play because the format was unsupported due to the licensing policies of the proprietors of the format" and "the video didn't play because the format was unsupported due to DRM". If you are the JavaScript author and you try to play a .mp4 file and it doesn't play, you can pretty much guess why. If you are the JavaScript authors and you try to play a .webdrm file and it doesn't play, you can pretty much guess why. There's no use in the browser providing different error codes. After all, providing different error codes would require browsers to have a table of formats they *don't* support with reasons of non-support encoded into it.
(In reply to comment #14) > (In reply to comment #11) >> We absolutely do not want that. >> >> So, no, we will not support any form of DRM in HTML5, and I'm fairly sure we >> will strongly resist any attempt to introduce such measures into WebM or Ogg >> media. > > I am curious to know who this "we" is you are speaking for. Is Lachlan speaking > on behalf of the W3C, Opera Software, or himself... 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. From a purely technical perspective, it just doesn't belong in here at all, as explained in comment 1 and reiterated by others. 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.
<video> DOES support DRM already. I've been able to play FairPlay-encrypted MP4 file (.m4p) via <video> in WebKit (r69082 - haven't tested other versions).
I should point out that although I think DRM in HTML is undoable on technical grounds alone, "major browsers will refuse to implement it" is also a valid reason to not spec it. Even if there are only non-technical reasons for refusing to add a feature, they can be definitive anyway, if they're held by major browser vendors. Compare to the requirement for Theora support being removed from the spec. So acting as though ideological opposition to DRM doesn't matter, and that this should be purely a technical discussion, is also a form of placing your hands over your ears and chanting "lalalalalala".
There are a few different issues here, and although the issues in general are relevant to a significant proportion of people who follow HTML5 goings-on, that doesn't necessarily mean that the issue itself is directly applicable to HTML5. First: media delivered by way of the video element needs some sort of DRM (or otherwise "protection") -- not because that's a good or a bad thing for it to have per se, but because it's a constraint of many large-scale applications of online delivery. For background, the agreements between rightsholders and publishers/broadcasters for delivery of media on the Web are tortuous, and not uncommonly negotiated over periods of many months, if not years; "content protection" features heavily in the discussions. There is often not a single rightsholder for a given piece of media: just the list of people and organisations who have some kind of legal interest in a single episode of a TV show can stretch into the hundreds, if not more. It really is quite, quite crazy, but it is the state of the landscape at the moment. It is certainly true that the same content is regularly broadcast free-to-air in a form with anybody with half a brain and $30 USB stick can capture, but this doesn't negate the agreements (even if it arguably /should/). Thus, the question is: is widespread adoption of the video element by mainstream media companies a goal of proponents of the video element? Personally, I believe it is, but others may of course have different views (and if so, you may as well stop reading here). Assuming you believe it is, then there's the question as to whether the path of sanity and least-resistance is to support some sort of content protection for that video, or whether it's easier to persuade all of the rightsholders to stop asking for something that's demonstrably so utterly worthless. Again, my opinion is that the former is a damned sight easier than the latter, even if it has some ideological "wrinkles" in many cases. This is made somewhat more difficult by the fact that the terms of the agreements between rightsholders and publishers are confidential, so we can never be /entirely/ sure what protections are going to be required. We can make some educated guesses, though, and discount the things which are completely infeasible (because they would only apply to closed-source systems). It's worth stressing that any restrictions which would be supported would realistically be a gamble: just as people can leech stuff from RTMP servers today, avoiding any protections the Flash plugin puts in place, people would be able to do the same with HTML5 video (or, for that matter, audio). What DRM is about, and has always been about, is this weird notion of "keeping people honest" by making it just that little bit too inconvenient to bother with. I should stress again that I think this is logically flawed in and of itself, but pitched against changing the minds of the people who own the content is a lot (possibly infinitely in the short-to-medium-term) harder than making these kinds of concessions. Now, the really important part: is this something which should happen in HTML5, or is it something which should be part of the media formats themselves? My take on it is that baking this stuff into HTML5 itself is more than a little bonkers. There are a couple of reasons why I think this (off the top of my head): first, as soon as we get into the realms of plugins doing the rendering of media, interfaces get very messy very quickly; second, if the restrictions don't prevent media from be saved locally, then any other restrictions which apply (such as expiration) need to be handled by whatever deals with the media outside of the browser. "No 'Save video as...'" is very likely to be *one* restriction of several which would be required, but is the only one which conceivably could be implemented as part of HTML5 itself. It doesn't make much sense to implement most of this stuff in the media players and just one aspect in HTML5, and it can't all be done in HTML5. Thus, the most sensible course of action would seem to be to make this a format-dependent thing. Now, this doesn't mean that it's not something which browsers would need to not care about, because if they play back media then they'll need to, and I'd love to see further discussions on how to actually go about doing all of this with the various kinds of video format that are being chucked around the Internet. It does, however, mean that it's out of scope for HTML5, and so *this* particular forum.
(In reply to comment #19) > I should point out that although I think DRM in HTML is undoable on technical > grounds alone, "major browsers will refuse to implement it" is also a valid > reason to not spec it. Even if there are only non-technical reasons for > refusing to add a feature, they can be definitive anyway, if they're held by > major browser vendors. Compare to the requirement for Theora support being > removed from the spec. So acting as though ideological opposition to DRM > doesn't matter, and that this should be purely a technical discussion, is also > a form of placing your hands over your ears and chanting "lalalalalala". I can agree that some solid discussion has been provided about the technical infeasibility of not directly supporting DRM in video. I disagree with the assertion that "major browsers will refuse to implement it" is a valid reason to immediately reject the idea. HTML is not specific only to "major browsers". Major browsers aren't the only ones who should be allowed to dictate the course of the web. And I also question whether the fact that "major browsers will refuse to implement it" will withstand the test of time if a way is found, and becomes popular, and browser customers demand such support. Ultimately the boss in the end is the customer. Anything else is "lalalalala".
Oops, should be I can agree that some solid discussion has been provided about the technical infeasibility of directly supporting DRM in HTML5.
(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 engineers. 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 forums". Lead, follow, or be left behind - it's really your choice.
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). * 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. * 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. * DRM, even in its broken state, is user-hostile. It adds a "ripping" stage to any unusual use case. * 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. * 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. * 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.
(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]
Sorry, item #2 was the OCF spec: http://www.idpf.org/ocf/ocf1.0/download/ocf10.htm
I am still not happy spec'ing DRM. *However* it may well make sense for us to be able to say (at the HTML level) "you will need 'this' DRM system in order to play this content" (in addition to the codecs etc.). Can this be part of the MIME type, like the codecs parameter?
(In reply to comment #27) > I am still not happy spec'ing DRM. *However* it may well make sense for us to > be able to say (at the HTML level) "you will need 'this' DRM system in order to > play this content" (in addition to the codecs etc.). Can this be part of the > MIME type, like the codecs parameter? It seems to me that it would be best to come up with a concrete proposal here, with specific use-cases, that could be considered on its technical merits.
Indeed, there is a lot of opinions everywhere the DRM issue is raised. But the question shouldn't be WHY do it; it should be WHERE to do it. 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". 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. Don't ask CIA agents to use RDFa in their Echelon databases. They're not supposed to do database engineering, and they don't care about RDFa, much like Hixie doesn't care about DRM. If you want it to happen, join the NSA engineering team and do it.
(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 (http://boingboing.net/2006/02/14/google-video-drm-why.html). 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 bug > > 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 WANT DRM!) DRM exists. How does HTML5 plan to deal with it?
(In reply to comment #30) > 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? HTML5 doesn't specify UI, so the browser can report the error to the user however it wants. For script, this is specified in the loading algorithm -- it's no different from any other case where the UA can't decode the video correctly. > 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? They should discuss their options with the content sites and try to find a way to get the content to work that's compatible with how HTML5 works. If that requires no spec changes, then they should go ahead and implement it, possibly in cooperation with browsers or DRM producers or whatnot. If it requires spec changes, they should present the details of what spec changes they need, along with use-cases, same as any desired spec change. Something as vague as "HTML5 needs to have DRM support" is not actionable -- it does not describe what spec change is needed precisely enough for anyone to do it. I don't think anyone in this discussion has any practical experience with these DRM schemes, so we can't possibly figure out what spec changes (if any) are needed by ourselves. The ones who actually want the feature need to tell us what changes they want. Until then, nothing can happen. In fact, John Harding of YouTube did discuss some details of what he'd like to see for DRM support: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/026947.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027069.html In the end, it seemed that all he cared about was having a consistent API to do the player UI in, so they don't need to code one UI in JS for non-DRM video and another in ActionScript (or whatever) for DRM video. The most plausible way for that to happen would be to persuade the DRM people to get their stuff to work with HTML5's API, which is what he said he'd do in the end. So it doesn't look like there's a problem here for us to solve, but if there is, I expect the content providers will tell us in due course. Again, we can do nothing until then, because we don't know what to do. I observe that if this is escalated, it will not be able to progress further unless someone writes up a change proposal that includes the exact spec changes they'd like to see. It appears to me that no one knows what the exact spec changes should be here, so I don't think this can progress any further.
A proposal. The idea would be to follow the vision of John Harding (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027069.html). Append, at the end of the "source-default-media" section", the following note. Note: HTML-intended DRM plugins should implement an interface that mimics that of the video element. The scrambled media resource, located in an embed element, should then be handled by the DRM plugin, which should trigger an error event on the corresponding embed element if viewing of the resource is not allowed. That event can then be handled as seen above. (In this case, "above" refers to an example of the use of onerror="" in a source element). Anyway, I don't think that having DRM mentioned in the spec in any other form than a note and a lot of "should"s is a good idea. We're not the implementors, after all.
I might be being dim, but surely a source which can't be played because of DRM is no different to a source which can't be played for any other reason (i.e., missing codec, whatever)? I can see the value in adding a MIME type parameter to hint that some kind of DRM system is required, such that canPlayType() can do the right thing, but beyond that, I struggle to see how HTML5 itself actually needs to cater for DRM any more than it needs to cater for a particular codec or container format (which, given the present specification, it doesn't).
(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.
No mechanism, in real terms, stands in the way of somebody who is determined -- by nature you're handing over both the encrypted data *and* the key to decrypt. That's a fundamental part of the DRM proposition. And, however much people don't like to admit it, the point of DRM _isn't_ to stand in the way (save for some minor inconvenience) of those who seed on BitTorrent today, but to prevent Joe Consumer from getting in on the act. (The pros [which are few] and cons [which are numerous] of this approach can be debated until you're blue in the face, but it doesn't really alter the demands for its support -- I speak from experience in saying that). So, considering this in purely technical terms, what aspects of such a barrier (be it involving encrypted media, or otherwise) require support from HTML5 in the first instance in order to work? It would be tempting to say none: in that a browser will behave entirely properly today if it comes across some unsupported DRMd content which is served via the <video> or <audio> elements: it will simply report that it's unable to play back the source. However, there is an argument that there should be some means of specifying the DRM scheme in advance in much the same way as codecs are specified. While this doesn't have any bearing on playability of a particular source, it does allow scripts or a user agent to determine playability in advance, smoothing the process somewhat. a "drm" parameter would seem sensible, with either a globally-unique value (a URI, perhaps) as the value, or a registry maintained somewhere (WHATWG Wiki, perhaps, as with link relations)? By nature, I don't believe the actual nitty-gritty of any particular scheme is relevant to HTML5: if a UA supports a scheme (e.g., FairPlay), it's going to be bound by the rules of that scheme; if it doesn't support it, those rules are irrelevant; and, of course, most schemes are container-specific, and HTML5 doesn't specify any particular container formats, so specifying scheme detail would be silly (not to mention a political nightmare, and a case of the cart leading the horse). Does this seem reasonable [philosophical objections to DRM in general notwithstanding]?
(In reply to comment #35) > DRM scheme in advance in much the same way as codecs are specified. While this > doesn't have any bearing on playability of a particular source, it does allow > scripts or a user agent to determine playability in advance, smoothing the > process somewhat. a "drm" parameter would seem sensible, with either a > globally-unique value (a URI, perhaps) as the value, or a registry maintained > somewhere (WHATWG Wiki, perhaps, as with link relations)? > > By nature, I don't believe the actual nitty-gritty of any particular scheme is > relevant to HTML5: if a UA supports a scheme (e.g., FairPlay), it's going to be > bound by the rules of that scheme; if it doesn't support it, those rules are > irrelevant; and, of course, most schemes are container-specific, and HTML5 > doesn't specify any particular container formats, so specifying scheme detail > would be silly (not to mention a political nightmare, and a case of the cart > leading the horse). > > Does this seem reasonable [philosophical objections to DRM in general > notwithstanding]? Assuming you mean canPlayType("video/ogg; drm=NoPlay") then this will have the wrong fallback behavior in existing clients. At least both Opera and Firefox ignore unknown parameters and would return "maybe" for this. It would be simpler to change the media type to reflect that it uses DRM, both Opera and Firefox will correctly report their non-support for 'video/ogg+drm'. However, this is completely hypothetical, I suggest that the first browser that supports DRM and wants to expose it somehow deal with the problem.
(In reply to comment #36) > Assuming you mean canPlayType("video/ogg; drm=NoPlay") then this will have the > wrong fallback behavior in existing clients. At least both Opera and Firefox > ignore unknown parameters and would return "maybe" for this. It would be > simpler to change the media type to reflect that it uses DRM, both Opera and > Firefox will correctly report their non-support for 'video/ogg+drm'. Yup, that's pretty much what I mean. I would have thought (and I could be wrong) that the behaviour you describe (returning "maybe") is, as a fallback, pretty much the ideal -- the UA says "maybe", and upon loading the source itself it turns out that it can't play it.
(In reply to comment #37) > (In reply to comment #36) > > > Assuming you mean canPlayType("video/ogg; drm=NoPlay") then this will have the > > wrong fallback behavior in existing clients. At least both Opera and Firefox > > ignore unknown parameters and would return "maybe" for this. It would be > > simpler to change the media type to reflect that it uses DRM, both Opera and > > Firefox will correctly report their non-support for 'video/ogg+drm'. > > Yup, that's pretty much what I mean. > > I would have thought (and I could be wrong) that the behaviour you describe > (returning "maybe") is, as a fallback, pretty much the ideal -- the UA says > "maybe", and upon loading the source itself it turns out that it can't play it. It works, but doesn't make browsers that don't support DRM fail early, which was the whole point, right? In any case, this is something for browsers actually supporting DRM to figure out.
> It works, but doesn't make browsers that don't support DRM fail early, which > was the whole point, right? Yes, very true -- but the browsers which don't understand the query at all (for the time being, that is; they hypothetically would in the future) will fail gracefully with a "maybe". i.e., they would be no worse off. > In any case, this is something for browsers > actually supporting DRM to figure out. how? serious question, incidentally: as an author, this suggestion would appear to be that I file a ER against WebKit asking for "a means to determine that a particular DRM scheme is supported", and do the same for (say) IE, wait several years, and then come back to the HTML WG and say "well, WebKit now does this, IE does this, Gecko doesn't support any DRM, some embedded deployments of Opera do, but don't have a way to detect it, can we reach some consensus and maybe stick something in the spec?"
(In reply to comment #39) > > In any case, this is something for browsers > > actually supporting DRM to figure out. > > how? > > serious question, incidentally: as an author, this suggestion would appear to > be that I file a ER against WebKit asking for "a means to determine that a > particular DRM scheme is supported", and do the same for (say) IE, wait several > years, and then come back to the HTML WG and say "well, WebKit now does this, > IE does this, Gecko doesn't support any DRM, some embedded deployments of Opera > do, but don't have a way to detect it, can we reach some consensus and maybe > stick something in the spec?" Yes, this is pretty much how I expect it to work. Given the lack of input from browsers that want to support DRM, standardizing anything right now would be premature. It's better if those who understand (and care about) the issues solve them.
(In reply to comment #40) > (In reply to comment #39) > > > In any case, this is something for browsers > > > actually supporting DRM to figure out. > > > > how? > > > > serious question, incidentally: as an author, this suggestion would appear to > > be that I file a ER against WebKit asking for "a means to determine that a > > particular DRM scheme is supported", and do the same for (say) IE, wait several > > years, and then come back to the HTML WG and say "well, WebKit now does this, > > IE does this, Gecko doesn't support any DRM, some embedded deployments of Opera > > do, but don't have a way to detect it, can we reach some consensus and maybe > > stick something in the spec?" > > Yes, this is pretty much how I expect it to work. Given the lack of input from > browsers that want to support DRM, standardizing anything right now would be > premature. It's better if those who understand (and care about) the issues > solve them. Please don't take offense at this, but this almost seems like you're saying that we should just wait until the browsers determine what we should have, and then they'll let us add this to a future version of HTML. I definitely think that one of the key aspects of the success of the video element is allowing those who want to use the element the ability to restrict access to the video, and one way to do so is some form of DRM. We may not like it, but it is a reality. If there are technical reasons why we can't incorporate at least a framework into HTML5 that accounts for DRM, we should focus on these technicalities. But I don't consider "browsers don't currently support it, or don't like it" to be such a technicality. Remember, HTML isn't only consumed by browsers. And browsers aren't the only gatekeeper for the spec. However, I think that Aryeh's point is good: we can't expect the discussion to focus on technicalities if we don't start with technicalities. Bugs about DRM should be about specific changes. Bugs are not a particularly good place to have general discussions. Unfortunately, with the HTML WG procedures, I'm not sure what other venue is available for these discussions to take place.
Okay... should anybody be interested, I've filed an ER against WebKit requesting a detection mechanism: https://bugs.webkit.org/show_bug.cgi?id=47591
(In reply to comment #41) > Please don't take offense at this, but this almost seems like you're saying > that we should just wait until the browsers determine what we should have, and > then they'll let us add this to a future version of HTML. Basically, yes, that's what he's saying. It's part of the normal spec development process for HTML5: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Interest by some notable implementers is essential in getting things added to the spec. Otherwise you end up speccing things that no one cares about. > Remember, HTML isn't only consumed by browsers. And browsers aren't the only > gatekeeper for the spec. If there were a substantial non-browser implementation that was interested, that would count too. But hypothetical implementations that may or may not exist don't count. Otherwise you wind up wasting your time writing a spec that almost no one will use in practice. This is one of the core philosophical differences between HTML5 and XHTML2: spec what implementers want to implement, nothing more or less. > Bugs are not a particularly good place to have general discussions. > Unfortunately, with the HTML WG procedures, I'm not sure what other venue is > available for these discussions to take place. public-html is the correct place within the HTML WG. The whatwg list would also work, although of course that's part of the WHATWG and not the W3C. However, you aren't going to make progress without a specific proposal, or list of goals and detailed explanation of the use-case, drafted with the input of someone who wants to implement it in a major implementation -- most likely a browser.
(In reply to comment #43) > (In reply to comment #41) > > Please don't take offense at this, but this almost seems like you're saying > > that we should just wait until the browsers determine what we should have, and > > then they'll let us add this to a future version of HTML. > > Basically, yes, that's what he's saying. It's part of the normal spec > development process for HTML5: > > http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F > > Interest by some notable implementers is essential in getting things added to > the spec. Otherwise you end up speccing things that no one cares about. > True, but there are other groups that are impacted by changes to HTML. We need implementation, yes, but we can't be constrained to asking five browser companies their permission on how the web advances. > > Remember, HTML isn't only consumed by browsers. And browsers aren't the only > > gatekeeper for the spec. > > If there were a substantial non-browser implementation that was interested, > that would count too. But hypothetical implementations that may or may not > exist don't count. Otherwise you wind up wasting your time writing a spec that > almost no one will use in practice. This is one of the core philosophical > differences between HTML5 and XHTML2: spec what implementers want to implement, > nothing more or less. > Not necessarily. We need to also be a little visionary in our outlook, too. We need to look not only at what we have today, but what we'll have, or need to have, in a few years. And what you're saying doesn't match what we have now in HTML5. Tell me, what browser has implemented color input type? How about the Details element? Yet many of these have been in HTML5 for over six years. There doesn't seem to be any expressed concern about unimplemented objects when these were questioned. Consistency has always been my primary concern when it comes to specifications. > > Bugs are not a particularly good place to have general discussions. > > Unfortunately, with the HTML WG procedures, I'm not sure what other venue is > > available for these discussions to take place. > > public-html is the correct place within the HTML WG. The whatwg list would > also work, although of course that's part of the WHATWG and not the W3C. > However, you aren't going to make progress without a specific proposal, or list > of goals and detailed explanation of the use-case, drafted with the input of > someone who wants to implement it in a major implementation -- most likely a > browser. I agree that the email list would be okay, and one can also use public-html-comment, in order to invite those who are not part of the HTML WG. However, this approach has been discouraged by the HTML WG co-chairs, so John has taken about the only approach he can--he submitted a bug. I can agree on a more detailed use case and specific suggestions, but I don't agree that we have to then ask, pretty please, permission of the browser companies in order to submit the idea to the group. I would hate that the W3C become nothing more than a rubber stamp tool to the five browser companies. It wouldn't serve the needs of the community if it did. This has been marked as WONTFIX. John, are you going to add the TrackerRequest keyword?
Although I personally dislike DRM, it's clearly not something Apple is entirely opposed to as a vendor. However, I don't really see what could be added at the HTML level to support DRM. If in the future browsers choose to support DRM-capable formats in the <video> element, I suspect the best way to express that would be a custom MIME type or a custom codecs paramater value. A custom MIME type would have the intended effect that non-supporting browsers wouldn't try to load the DRM'd resource. It would also allow selection from multiple possibly vendor-specific DRM schemes. It would not require any changes at the HTML level. Adding a drm= MIME parameter would also not require any changes at the HTML level - it should be defined for the specific MIME types that it applies to, not by HTML. If anyone believes that HTML5 should change to add some form of DRM support, I think there needs to be an example of what kind of change at the HTML level (as opposed to inside individual media formats) would actually be helpful. That being said, it's likely to be hard to evaluate whether any given feature is helpful until at least one implementor is ready to add DRM support. DRM schemes tend to be extraordinarily complicated, and making a guess in a vacuum about what HTML may need is unlikely to be successful.
Should anyone wander in here looking for a "DRM solution", I provided a little cookbook: http://www.webkitchen.be/2011/01/26/stealing-content-was-never-easier-than-with-html5/comment-page-1/#comment-26043 (I'd rather you didn't bother, of course, the point is just that it's already possible to make it pretty hard to rip <video>, if one has the determination.)