If it's open source, I can just swoop in, inject some code and make a copy of the decrypted data stream for 'archival purposes'. Won't take a day for a PoC.

I can still do this with closed source DRM blobs, but it will take much longer. And there will probably be pointless anti-debugger tricks, system wide hooks that break countless other software, kernel drivers that BSoD your system..

That is precisely why this proposal is such a terrible idea. It writes into a standard that it is okay to produce software that is actively hostile to its user, while having absolutely no security gain whatsoever (because the concept is fundamentally broken: if the data is being decrypted on my system, I will get it).

But you can do that with any DRM - the unencrypted stream will always be in memory at some point.

Yes, that is my point. That is why any DRM plugin will be closed-source and probably filled with landmines and obfuscation: its the only sliver of a chance they have to make getting the unencrypted data hard.

Not if the decryption is handled by hardware that refuses to give an unencrypted video stream back to the CPU.

An extra hardware chip is a closed system. You control all the input that comes in. It is just a more annoying form of obfuscation at that point.

Nothing in the W3C's DRM spec provides for anything better than a closed hardware chip.