<i>>Some people have protested “no”, but in fact I decided the actual logical answer is “yes’.</i><p>As long as anti-circumvention laws are a thing, the real answer should be nothing but a very enthusiastic "no". I don't see how anything covered by anti-circumvention laws could in any way be compatible with the idea or spirit of what is supposed to be Open Web.<p><i>>The reason for recommending EME is that by doing so, we lead the industry who developed it in the first place to form a simple, easy to use way of putting encrypted content online, so that there will be interoperability between browsers. This makes it easier for web developers and also for users.</i><p>This is also a whole bunch of horse manure considering that the actual DRM part is externalized to proprietary black box extensions so in reality HTML DRM doesn't really do much to improve interopability. A browser vendor needs to basically bundle a black box extension with their browser to handle the DRM, and the DRM needs to approved by vendors like Netflix etc in order for you to actually view DRM'd content on their site. Basically this just entrenches the dominance of existing browsers over the market while making it even harder than before for anyone new to try to tackle the market since now you need to basically please Hollywood if you want to be able to play their content in your browser, all with the blessing of W3C.<p>Sure, these DRM solutions already exist and will continue to exist, and it doesn't help that two of the three big browser vendors are also DRM vendors themselves (Google & Microsoft), but the last thing we should do is give them official blessing for their practices. It's a huge spit in the face of the Open Web.<p>EDIT: Some more comments.<p><i>> If EME did not exist, vendors could just create new Javascript based versions.</i><p>This would be an infinitely more preferable solution to EME, because guess what - this would actually guarantee true interoperability! As long as your browser could run (modern) JS, it would be compatible with a JS-based content protection scheme. Things on eg. Linux would Just Work without having to use rely on Widewine DRM on a closed build of Chrome, for example. So presenting EME vs JS-based protection schemes as equivalent is ridiculous. The latter is vastly less bad than the former.<p><i>>And without using the web at all, it is so easy to invite ones viewers to switching to view the content on a proprietary app. And if the closed platforms prohibited DRM in apps, then the large content providers would simply distribute their own set-top boxes and game consoles as the only way to watch their stuff.</i><p>If content distributors wanted to try and ignore the web completely in the name of "protecting their content"... by all means, go ahead! Somehow I suspect they wouldn't resort to that, though - they wouldn't be so interested in HTML DRM if they didn't see the web as a valuable venue. Most likely they'd end up restricting web versions to lower quality options while trying to lure people to more closed enviroments with promises of higher quality, but the thing is that they're already doing exactly that anyway even with all the black box DRM they have today so it really wouldn't be all that different from that.<p><i>>An important issue here is how much the publisher gets to learn about the user.</i><p>This whole list is also ridiculous considering that proprietary black boxes are a way bigger unknown in terms of what they could be doing on the user system than any say, JS-based solution. And the "user tracking" the DRM supposedly couldn't do could be done separately in JS anyway, whether the whole content protection is based on JS or not, so this list is once again basically just a poorly thought distraction.<p><i>>Spread to other media</i><p>This section is way too short and basically handwaves the issue away. "Music probably won't go back to DRM and books, lol dunno, maybe they'd give up DRM even when we're explicitly endorsing DRM for the web?" Endorsing any kind of DRM in HTML standards has a very real danger of being a slippery slope. Hey, now we can black box DRM <video>. When can we do it to <audio>? Music and audio in general needs protection too! Hey, we got it for <audio>, now where's our DRM support for <img>? Images need to be protected too, they're copyrighted content after all! And what about text? Books and articles need protection too! <p> needs DRM! And suddenly the DOM in your developer tool is just a bunch of black boxes, and the Open Web is no more. In fact, developer tools in general should probably be banned, someone might use them for anti-circumvention purposes after all, and that would be illegal! The Right to Read[1] is <i>uncomfortably</i> real with the possibilities here.<p><i>>Despite these issues, users continue to buy DRM-protected content.</i><p>Well gee, it's not like legitimate users have much options in many cases. Video especially tends to be DRM-infested pretty much everywhere you go. In many cases piracy is literally your only option when it comes to getting content DRM-free, which is a crying shame. This is once again no reason whatsoever why we should just be okay with it and endorse DRM for what is supposed to be Open Web.<p><i>>The web has to be universal, to function at all. It has to be capable of holding crazy ideas of the moment, but also the well polished ideas of the century. It must be able to handle any language and culture. It must be able to include information of all types, and media of many genres. Included in that universality is that it must be able to support free stuff and for-pay stuff, as they are all part of this world. This means that it is good for the web to be able to include movies</i><p>Well, I completely agree with that...<p><i>>and so for that, it is better for HTML5 to have EME than to not have it.</i><p>...but this does not follow In fact, it goes pretty much directly against it.<p>[1] <a href="https://www.gnu.org/philosophy/right-to-read.html" rel="nofollow">https://www.gnu.org/philosophy/right-to-read.html</a>