3 ms·
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
by revelation 13y ago
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).
- debacle 13y agoBut you can do that with any DRM - the unencrypted stream will always be in memory at some point.
- revelation 13y agoYes, 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.
- nitrogen 13y agoNot if the decryption is handled by hardware that refuses to give an unencrypted video stream back to the CPU.
- revelation 13y agoAn 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.
- nitrogen 13y agoNothing in the W3C's DRM spec provides for anything better than a closed hardware chip.