The idea is that currently most video on the web plays in either Flash or Silverlight, which are poorly supported plugins which offer a huge amount of extra functionality and – more importantly – attack surface.
This is really only about replacing a huge proprietary blob with a much smaller one.
This has exactly nothing to do with reducing the attack surface of a browser.
What this is about is letting people like Audible and Netflix encrypt their content in a special way that means that only browsers that support the DRM api can decrypt it; by including the closed source binary blobs provided by those vendors.
Don't want to do that? Sorry, our website doesn't work on your browser.
...but to the main point:
This will in fact catastrophically increase the attack surface of browsers, as they are forced to bundle unmoderated, unreviewed binary code blocks (Content Decryption Module, from the spec) that can do whatever they like into the browser code.
AFAIK, there is nothing in the current proposal about forcing browsers to bundle CDMs. The CDMs could be part of the OS, installed separately, or simply not there at all (in which case you have a browser that won't play DRM video, but is otherwise fully functional).
That's no different from the current situation with Flash and Silverlight. You're not forced to use them, but some content is only accessible if you do. If we can replace Flash with a CDM, the attack surface is decreased, because a CDM is less complex.
Without the EME standard, it seems highly unlikely that media companies would decide to distribute videos DRM-free. They would simply continue to build and use non-standard solutions. EME is just a standard API for what they'd be bound to do anyway.
It's irrelevant whether the CDM is part of the browser, part of the OS or an installed plugin like Java.
The browser must invoke the closed source, vendor provided CDM by pass a binary stream from the server.
Certainly, it's no worse than what we currently have, but current plugins have, shall we say, a rocky security history wouldn't you say? (>_> java)
Worse, every content provider is going to have their home written CDM, because they certainly aren't going to share. Once a CDM is compromised thats it, it's useless.
It's going to be a nightmare of install-all-the-plugins. Most likely major browsers will bundle the most popular one to reduce the burden on the user.
Look at the security track record of all plugins. Notice how few of the vulnerabilities are in the actual content decryption code as opposed to the code duplicating things the browser does natively? Also consider how sandboxes the CDM interface can be if it's just passing data through to decode.
What fantasy world are you living in where he/she said that non-DRM HTML 5 video was the status quo for paid content?
What was said was that it is there, and services are choosing not to use it, even accepting that using it would be suicide for their business. It's not the responsibility of http to preserve the business models of those companies rather than a free and open internet, though it's understandable that those businesses are fighting for it.
I don't have Flash or Silverlight installed on my system. Trust me when I say that approximately zero commercial video is available with these plugins.
Even half of the ad-supported content on YouTube isn't available.
As an implementor, until mozilla finished shipping native h.264 support I have to either use Flash as a fallback for IE8 and Firefox (mediaobject.js is great!) or encode all of my video twice and double my storage bill. Guess which one is more appealing?
This is really only about replacing a huge proprietary blob with a much smaller one.