The working group that is drafting the W3C's Encrypted Media Extension (EME) specification (aka DRM in HTML5) is baking in language that would allow the DMCA to be invoked despite denials that "EME [is] putting DRM in HTML".
The EME is a set of predefined javascript functions that invoke functions in Content Decryption Modules (CDM) and CDMs are containers for DRM functionality. It's simple and innocuous but how it's worded and what they refuse to define is where the danger lies.
First, the EME is hooked to the DMCA by using very specific legal language: "content protection". One of the people working on the specification freely admits that "it is well-known that the purpose of content protection is not to prevent all unauthorized access to the content (this is impossible)" but despite the fact that it cannot protect the content, the entire working group insists on this very specific language and has refused alternative wording. The reason of course is because "protected content" is the legal term that DRM implementers always use.
Second, the EME is hardware specific by refusing to make a specification for CDMs. By not defining how CDMs are implemented, this leaves it up to each browser author to invent their own. All existing implementations of the CDMs are done using non-portable binary plugins that execute directly on your computer. This means that if a website is using a CDM that isn't ported to your specific browser, OS and architecture, you cannot view the video on that page. So if your computer runs on PowerPC instead of x86 you are out of luck, every site using CDMs will be out of your reach. That's not all, despite having a 4K SmartTV, you can't watch Netflix in 4K because it uses PlayReady 3.0 and it was reveiled last year that PlayReady 3.0 is only for Windows 10 and requires hardware DRM. Specifically it uses an instruction set extension to use a hidden "security processor" which is only in the latest generation of Intel and AMD chips.
All proposed alternatives to the legal language and a legitimate alternative to hardware specific lock-in were rejected by those drafting the EME. After looking into their backgrounds, I found that the group is composed exclusively of Microsoft, Netflix and Google employees.
If you wish to express your concerns, you can still do so on the github issue pages:
Issue #159: Remove all "protection" language
Issue #166: EME specification needs to include a CDM specification
(Score: 2, Informative) by Anonymous Coward on Friday April 29 2016, @03:46PM
Well, the thing is that it's only a matter of time, probably months, before whatever new restrictions module that's shipping with Firefox 82 and Chrome 104 has an open source alternative. Content providers can't move in lock-step. They have to have backwards compatibility. The goal of "protecting content" and digital restrictions management is an utterly wonky goal.
That is an unfounded assumption for two reasons:
(1) "open source alternatives" are illegal under the DMCA. Technically they are not illegal to posses and use, but they are illegal to distribute. [wikipedia.org] You can write your own, but you can't give it to anyone. So in practice they are illegal.
(2) They do not need to be in lockstep. They certainly can require that users upgrade to the latest version. After all if you are streaming their video on the network you can also upgrade to the latest DRM software overr that same network. Chances are it will just happen automatically and invisibly the way chrome and firefox auto-upgrade today.
The guys doing this are very smart assholes. They know that DRM is not 100% effective. They don't care. They are happy to make it 95% effective and whether that effectiveness is accomplished through technology or laws is irrelevant to them.